[JBoss JIRA] (JGRP-1793) MergeTest does not close channels correctly
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1793?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1793:
---------------------------
Fix Version/s: 3.5
Oh, wow ! Thanks for catching this one !
> MergeTest does not close channels correctly
> -------------------------------------------
>
> Key: JGRP-1793
> URL: https://issues.jboss.org/browse/JGRP-1793
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13, 3.3.5, 3.4.2
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 3.2.13, 3.5
>
>
> A typo in the test case results in channels for MergeTest to remain open long after the test has finished:
> {noformat}
> [nrla@lenovo bin]$ ./probe.sh
> -- send probe on /224.0.75.75:7500
> #1 (171 bytes):
> local_addr=D [09993e52-3d74-47b9-152e-2d9703e55734]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:33877
> version=3.2.13.Final
> #2 (165 bytes):
> local_addr=A [30c2b3d8-72b0-0e66-ee49-c5414e117048]
> cluster=MergeTest.testMerging2Members
> view=[B|11] [B, A]
> physical_addr=127.0.0.1:52335
> version=3.2.13.Final
> #3 (171 bytes):
> local_addr=B [d281af3b-9bbc-a556-d654-b2b423fec81b]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:49313
> version=3.2.13.Final
> #4 (171 bytes):
> local_addr=A [93ca13b4-cde3-4fa4-b971-dffd23cdf5fe]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:33183
> version=3.2.13.Final
> #5 (165 bytes):
> local_addr=B [0ed3765f-3ae1-707d-06b5-ba7c8eaed8fc]
> cluster=MergeTest.testMerging2Members
> view=[B|11] [B, A]
> physical_addr=127.0.0.1:38458
> version=3.2.13.Final
> {noformat}
> When these tests are run seqentially, their channels should never be open simultaneously.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (JGRP-1793) MergeTest does not close channels correctly
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1793?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1793:
-------------------------------------------
Bela, which versions should this apply to?
> MergeTest does not close channels correctly
> -------------------------------------------
>
> Key: JGRP-1793
> URL: https://issues.jboss.org/browse/JGRP-1793
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13, 3.3.5, 3.4.2
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 3.2.13, 3.5
>
>
> A typo in the test case results in channels for MergeTest to remain open long after the test has finished:
> {noformat}
> [nrla@lenovo bin]$ ./probe.sh
> -- send probe on /224.0.75.75:7500
> #1 (171 bytes):
> local_addr=D [09993e52-3d74-47b9-152e-2d9703e55734]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:33877
> version=3.2.13.Final
> #2 (165 bytes):
> local_addr=A [30c2b3d8-72b0-0e66-ee49-c5414e117048]
> cluster=MergeTest.testMerging2Members
> view=[B|11] [B, A]
> physical_addr=127.0.0.1:52335
> version=3.2.13.Final
> #3 (171 bytes):
> local_addr=B [d281af3b-9bbc-a556-d654-b2b423fec81b]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:49313
> version=3.2.13.Final
> #4 (171 bytes):
> local_addr=A [93ca13b4-cde3-4fa4-b971-dffd23cdf5fe]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:33183
> version=3.2.13.Final
> #5 (165 bytes):
> local_addr=B [0ed3765f-3ae1-707d-06b5-ba7c8eaed8fc]
> cluster=MergeTest.testMerging2Members
> view=[B|11] [B, A]
> physical_addr=127.0.0.1:38458
> version=3.2.13.Final
> {noformat}
> When these tests are run seqentially, their channels should never be open simultaneously.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (JGRP-1793) MergeTest does not close channels correctly
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1793?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz reassigned JGRP-1793:
-----------------------------------------
Assignee: Richard Achmatowicz (was: Bela Ban)
> MergeTest does not close channels correctly
> -------------------------------------------
>
> Key: JGRP-1793
> URL: https://issues.jboss.org/browse/JGRP-1793
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13, 3.3.5, 3.4.2
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 3.2.13
>
>
> A typo in the test case results in channels for MergeTest to remain open long after the test has finished:
> {noformat}
> [nrla@lenovo bin]$ ./probe.sh
> -- send probe on /224.0.75.75:7500
> #1 (171 bytes):
> local_addr=D [09993e52-3d74-47b9-152e-2d9703e55734]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:33877
> version=3.2.13.Final
> #2 (165 bytes):
> local_addr=A [30c2b3d8-72b0-0e66-ee49-c5414e117048]
> cluster=MergeTest.testMerging2Members
> view=[B|11] [B, A]
> physical_addr=127.0.0.1:52335
> version=3.2.13.Final
> #3 (171 bytes):
> local_addr=B [d281af3b-9bbc-a556-d654-b2b423fec81b]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:49313
> version=3.2.13.Final
> #4 (171 bytes):
> local_addr=A [93ca13b4-cde3-4fa4-b971-dffd23cdf5fe]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:33183
> version=3.2.13.Final
> #5 (165 bytes):
> local_addr=B [0ed3765f-3ae1-707d-06b5-ba7c8eaed8fc]
> cluster=MergeTest.testMerging2Members
> view=[B|11] [B, A]
> physical_addr=127.0.0.1:38458
> version=3.2.13.Final
> {noformat}
> When these tests are run seqentially, their channels should never be open simultaneously.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (JGRP-1793) MergeTest does not close channels correctly
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1793?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1793:
-------------------------------------------
Problem is here in MergeTest.java:
{noformat}
private static void close(JChannel[] channels) {
if(channels == null) return;
for(int i=channels.length -1; i <= 0; i--) {
JChannel ch=channels[i];
Util.close(ch);
}
}
{noformat}
should be
{noformat}
private static void close(JChannel[] channels) {
if(channels == null) return;
for(int i=channels.length -1; i >= 0; i--) { // changed this line
JChannel ch=channels[i];
Util.close(ch);
}
}
{noformat}
> MergeTest does not close channels correctly
> -------------------------------------------
>
> Key: JGRP-1793
> URL: https://issues.jboss.org/browse/JGRP-1793
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13, 3.3.5, 3.4.2
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.2.13
>
>
> A typo in the test case results in channels for MergeTest to remain open long after the test has finished:
> {noformat}
> [nrla@lenovo bin]$ ./probe.sh
> -- send probe on /224.0.75.75:7500
> #1 (171 bytes):
> local_addr=D [09993e52-3d74-47b9-152e-2d9703e55734]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:33877
> version=3.2.13.Final
> #2 (165 bytes):
> local_addr=A [30c2b3d8-72b0-0e66-ee49-c5414e117048]
> cluster=MergeTest.testMerging2Members
> view=[B|11] [B, A]
> physical_addr=127.0.0.1:52335
> version=3.2.13.Final
> #3 (171 bytes):
> local_addr=B [d281af3b-9bbc-a556-d654-b2b423fec81b]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:49313
> version=3.2.13.Final
> #4 (171 bytes):
> local_addr=A [93ca13b4-cde3-4fa4-b971-dffd23cdf5fe]
> cluster=MergeTest.testMerging4Members
> view=[A|11] [A, B, C, D]
> physical_addr=127.0.0.1:33183
> version=3.2.13.Final
> #5 (165 bytes):
> local_addr=B [0ed3765f-3ae1-707d-06b5-ba7c8eaed8fc]
> cluster=MergeTest.testMerging2Members
> view=[B|11] [B, A]
> physical_addr=127.0.0.1:38458
> version=3.2.13.Final
> {noformat}
> When these tests are run seqentially, their channels should never be open simultaneously.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (JGRP-1793) MergeTest does not close channels correctly
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created JGRP-1793:
-----------------------------------------
Summary: MergeTest does not close channels correctly
Key: JGRP-1793
URL: https://issues.jboss.org/browse/JGRP-1793
Project: JGroups
Issue Type: Bug
Affects Versions: 3.4.2, 3.3.5, 3.2.13
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Priority: Minor
Fix For: 3.2.13
A typo in the test case results in channels for MergeTest to remain open long after the test has finished:
{noformat}
[nrla@lenovo bin]$ ./probe.sh
-- send probe on /224.0.75.75:7500
#1 (171 bytes):
local_addr=D [09993e52-3d74-47b9-152e-2d9703e55734]
cluster=MergeTest.testMerging4Members
view=[A|11] [A, B, C, D]
physical_addr=127.0.0.1:33877
version=3.2.13.Final
#2 (165 bytes):
local_addr=A [30c2b3d8-72b0-0e66-ee49-c5414e117048]
cluster=MergeTest.testMerging2Members
view=[B|11] [B, A]
physical_addr=127.0.0.1:52335
version=3.2.13.Final
#3 (171 bytes):
local_addr=B [d281af3b-9bbc-a556-d654-b2b423fec81b]
cluster=MergeTest.testMerging4Members
view=[A|11] [A, B, C, D]
physical_addr=127.0.0.1:49313
version=3.2.13.Final
#4 (171 bytes):
local_addr=A [93ca13b4-cde3-4fa4-b971-dffd23cdf5fe]
cluster=MergeTest.testMerging4Members
view=[A|11] [A, B, C, D]
physical_addr=127.0.0.1:33183
version=3.2.13.Final
#5 (165 bytes):
local_addr=B [0ed3765f-3ae1-707d-06b5-ba7c8eaed8fc]
cluster=MergeTest.testMerging2Members
view=[B|11] [B, A]
physical_addr=127.0.0.1:38458
version=3.2.13.Final
{noformat}
When these tests are run seqentially, their channels should never be open simultaneously.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (DROOLS-364) ClasspathKieProject fails vfs: path for jar deployments and exploded ear
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-364:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1058254|https://bugzilla.redhat.com/show_bug.cgi?id=1058254] from ON_QA to ASSIGNED
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
> Key: DROOLS-364
> URL: https://issues.jboss.org/browse/DROOLS-364
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Environment: JBoss AS 7.1.1
> Reporter: Nicolas-Xavier Vanderlinden
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta1
>
> Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log
>
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> null
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (AS7-141) Deployment fails with empty classpath manifest
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-141?page=com.atlassian.jira.plugin.sy... ]
Brian Stansberry commented on AS7-141:
--------------------------------------
Hi Peter,
What you are reporting sounds like a very different issue. Is your ear zipped? That log message occurs when the deployment scanner reads the archive and doesn't find the expected signature bytes that should be present in a proper zip file.[1]
The scanner has no idea what a MANIFEST.MF even is; it sees the zip as a bunch of bytes, opaque other than the various zip format metadata bytes dispersed throughout.
I suspect that changing the MANIFEST.MF had the side effect of correcting whatever the issue was with the zip file.
I recommend you check the original zip to see if it is in some way faulty. Perhaps some tool like InfoZip can help[2]. (I'm not an expert on such tooling.) If you have an EAP subscription, you can also open a case on the Customer Support Portal.
[1] For the actual scan algorithm see https://github.com/wildfly/wildfly/blob/master/deployment-scanner/src/mai...
[2] http://en.wikipedia.org/wiki/Infozip
> Deployment fails with empty classpath manifest
> ----------------------------------------------
>
> Key: AS7-141
> URL: https://issues.jboss.org/browse/AS7-141
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.0.0.Alpha1
> Reporter: Max Rydahl Andersen
> Assignee: Stuart Douglas
> Fix For: 7.0.0.Beta1
>
> Attachments: jbossas7-deploy-example.war
>
>
> If you war has a MANIFEST.MF with empty classpath you get an error even though empty Class-Path: is present (and afaik valid).
> This is btw. how Eclipse defaults to create a war with no jar dependencies thus it would fail for a lot of folks ;)
> 11:53:53,682 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Starting deployment of "jbossas7-deploy-example.war"
> 11:53:53,706 WARN [org.jboss.vfs] (MSC service thread 1-1) VFS was unable to set the URLStreamHandlerFactory. This will have unpredictable results
> 11:53:53,731 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001:Failed to start service jboss.deployment.unit."jbossas7-deploy-example.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jbossas7-deploy-example.war".PARSE: Failed to process phase PARSE of deployment "jbossas7-deploy-example.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:109)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1367)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
> at java.lang.Thread.run(Thread.java:680) [:1.6.0_22]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Class Path entry in "/content/jbossas7-deploy-example.war" not found.
> at org.jboss.as.server.deployment.module.ManifestClassPathProcessor.deploy(ManifestClassPathProcessor.java:123)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:103)
> ... 4 more
> I'm attaching a simple war showing this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot find custom ldap socket factory
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration updated SECURITY-784:
---------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1052644, https://bugzilla.redhat.com/show_bug.cgi?id=1068665 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1052644)
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
> Key: SECURITY-784
> URL: https://issues.jboss.org/browse/SECURITY-784
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
> Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the "java.naming.ldap.factory.socket" property in as an
> module-option:
> <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
> at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk. Unfortunately, that did not work. I also added the socket
> factory jar to the jre/lib/ext directory. That didn't work either.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2993) Core: jboss.sh fails to start with org.picketbox module not found
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2993?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2993:
-----------------------------------
Yeah, this was added late in release cycle https://github.com/wildfly/wildfly/commit/64ab2ed
I missed it because of this, proper fix is getting rid of this dependency.
> Core: jboss.sh fails to start with org.picketbox module not found
> -----------------------------------------------------------------
>
> Key: WFLY-2993
> URL: https://issues.jboss.org/browse/WFLY-2993
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.CR1
>
>
> Note that the issue occurs only when using the WildFly 8 *core distribution*, the regular distribution is fine.
> {noformat}
> wildfly-core-8.0.0.Final$ ./bin/jboss-cli.sh -c
> org.jboss.modules.ModuleNotFoundException: org.picketbox:main
> at org.jboss.modules.Module.addPaths(Module.java:1030)
> at org.jboss.modules.Module.link(Module.java:1386)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1414)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:242)
> at org.jboss.modules.Main.main(Main.java:385)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months