[JBoss JIRA] (WFLY-3068) could fail more gracefully when wrong Java version used
by dpocock (JIRA)
[ https://issues.jboss.org/browse/WFLY-3068?page=com.atlassian.jira.plugin.... ]
dpocock updated WFLY-3068:
--------------------------
Description:
If I try to start Wildfly with Java 6 (which is no longer support of course) it just fails with a stack:
09:51:00,536 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
09:51:00,543 WARN [org.jboss.modules] (main) Failed to define class org.jboss.as.jmx.PluggableMBeanServerBuilder in Module "org.jboss.as.jmx:main" from local module loader @36b60b93 (finder: local module finder @69b1fbf4 ()): java.lang.UnsupportedClassVersionError: org/jboss/as/jmx/PluggableMBeanServerBuilder : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_26]
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_26]
at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_26]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:423) [rt.jar:1.6.0_26]
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465) [rt.jar:1.6.0_26]
at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511) [rt.jar:1.6.0_26]
at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298) [rt.jar:1.6.0_26]
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213) [rt.jar:1.6.0_26]
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174) [rt.jar:1.6.0_26]
at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302) [rt.jar:1.6.0_26]
at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504) [rt.jar:1.6.0_26]
at org.jboss.modules.Main.main(Main.java:449) [jboss-modules.jar:1.3.0.Final]
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/jboss/as/jmx/PluggableMBeanServerBuilder : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
at org.jboss.modules.Module.loadModuleClass(Module.java:548)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118)
at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:423)
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465)
at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511)
at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174)
at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302)
at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504)
at org.jboss.modules.Main.main(Main.java:449)
It would be more friendly if it checked the Java version in the main() function and stopped gracefully. The stack trace is not hard to understand but may not be obvious to everybody.
Priority: Minor (was: Major)
Affects Version/s: 8.0.0.Final
Environment: Java version < 7
Component/s: Server
> could fail more gracefully when wrong Java version used
> -------------------------------------------------------
>
> Key: WFLY-3068
> URL: https://issues.jboss.org/browse/WFLY-3068
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.Final
> Environment: Java version < 7
> Reporter: dpocock
> Priority: Minor
>
> If I try to start Wildfly with Java 6 (which is no longer support of course) it just fails with a stack:
> 09:51:00,536 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 09:51:00,543 WARN [org.jboss.modules] (main) Failed to define class org.jboss.as.jmx.PluggableMBeanServerBuilder in Module "org.jboss.as.jmx:main" from local module loader @36b60b93 (finder: local module finder @69b1fbf4 ()): java.lang.UnsupportedClassVersionError: org/jboss/as/jmx/PluggableMBeanServerBuilder : Unsupported major.minor version 51.0
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_26]
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_26]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_26]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
> at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:423) [rt.jar:1.6.0_26]
> at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465) [rt.jar:1.6.0_26]
> at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511) [rt.jar:1.6.0_26]
> at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298) [rt.jar:1.6.0_26]
> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213) [rt.jar:1.6.0_26]
> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174) [rt.jar:1.6.0_26]
> at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302) [rt.jar:1.6.0_26]
> at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504) [rt.jar:1.6.0_26]
> at org.jboss.modules.Main.main(Main.java:449) [jboss-modules.jar:1.3.0.Final]
> Exception in thread "main" java.lang.UnsupportedClassVersionError: org/jboss/as/jmx/PluggableMBeanServerBuilder : Unsupported major.minor version 51.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
> at org.jboss.modules.Module.loadModuleClass(Module.java:548)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118)
> at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:423)
> at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465)
> at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511)
> at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298)
> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213)
> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174)
> at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302)
> at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504)
> at org.jboss.modules.Main.main(Main.java:449)
> It would be more friendly if it checked the Java version in the main() function and stopped gracefully. The stack trace is not hard to understand but may not be obvious to everybody.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-2319) LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2319:
-----------------------------------------------
Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1060275|https://bugzilla.redhat.com/show_bug.cgi?id=1060275] from ON_QA to VERIFIED
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2319
> URL: https://issues.jboss.org/browse/WFLY-2319
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Beta1
> Reporter: Darran Lofthouse
> Assignee: Eduardo Martins
> Fix For: 8.0.0.Final
>
> Attachments: LdapSearching.tgz
>
>
> The following code: -
> {code}
> Hashtable env = new Hashtable();
> env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
> env.put("java.naming.security.authentication", "simple");
> env.put("java.naming.provider.url", "ldap://localhost:10389");
> env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
> env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
> SearchControls ctl = null;
> String attrArr[] = new String[1];
> attrArr[0] = "sn";
> ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
> String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
> String filter = "(uid=UserOne)";
> NamingEnumeration nenum = null;
> DirContext ictx = null;
> ictx = new InitialDirContext(env);
> nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
> protected Context getURLOrDefaultInitCtx(String name)
> throws NamingException {
> if (NamingManager.hasInitialContextFactoryBuilder()) {
> return getDefaultInitCtx();
> }
> String scheme = getURLScheme(name);
> if (scheme != null) {
> Context ctx = NamingManager.getURLContext(scheme, myProps);
> if (ctx != null) {
> return ctx;
> }
> }
> return getDefaultInitCtx();
> }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-2319) LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2319:
-----------------------------------------------
Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1014911|https://bugzilla.redhat.com/show_bug.cgi?id=1014911] from ON_QA to VERIFIED
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2319
> URL: https://issues.jboss.org/browse/WFLY-2319
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Beta1
> Reporter: Darran Lofthouse
> Assignee: Eduardo Martins
> Fix For: 8.0.0.Final
>
> Attachments: LdapSearching.tgz
>
>
> The following code: -
> {code}
> Hashtable env = new Hashtable();
> env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
> env.put("java.naming.security.authentication", "simple");
> env.put("java.naming.provider.url", "ldap://localhost:10389");
> env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
> env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
> SearchControls ctl = null;
> String attrArr[] = new String[1];
> attrArr[0] = "sn";
> ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
> String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
> String filter = "(uid=UserOne)";
> NamingEnumeration nenum = null;
> DirContext ictx = null;
> ictx = new InitialDirContext(env);
> nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
> protected Context getURLOrDefaultInitCtx(String name)
> throws NamingException {
> if (NamingManager.hasInitialContextFactoryBuilder()) {
> return getDefaultInitCtx();
> }
> String scheme = getURLScheme(name);
> if (scheme != null) {
> Context ctx = NamingManager.getURLContext(scheme, myProps);
> if (ctx != null) {
> return ctx;
> }
> }
> return getDefaultInitCtx();
> }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
by Chris Roberts (JIRA)
[ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.... ]
Chris Roberts commented on WFLY-2959:
-------------------------------------
I think the downgrade to 2.2.3 is not ideal.
jackson-datatype-hibernate4:2.2.3 (used to work around lazy init exceptions easily with Jackson) does not support hibernate 4.3 as far as I can see only hibernate4.1.
jackson-datatype-hibernate4:2.3+ does but depends on jackson 2.3.0.
Jackson 2.3.2 is supposed to have put these APIs back as deprecated, but so far I've had no success upgrading my wildfly module version of jackson-jaxrs with the new 2.3.2 modules.
Here is a link to the relevant issue on the Jackson side which is supposed to solve the issue (but doesn't seem to work for me):
https://github.com/FasterXML/jackson-jaxrs-providers/issues/41
It would seem ideal that RestEasy support Jackson 2.3+ but I'm not sure how far away that is, or the deprecated APIs on the Jackson side are working.
> Downgrade Jackson dependency
> ----------------------------
>
> Key: WFLY-2959
> URL: https://issues.jboss.org/browse/WFLY-2959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: REST
> Affects Versions: 8.0.0.Final
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 8.0.1.Final
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64...] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-2920) StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2920:
-----------------------------------------------
Osamu Nagano <onagano(a)redhat.com> changed the Status of [bug 1072747|https://bugzilla.redhat.com/show_bug.cgi?id=1072747] from NEW to POST
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-2920
> URL: https://issues.jboss.org/browse/WFLY-2920
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: IIOP
> Affects Versions: 8.0.0.Final
> Reporter: Osamu Nagano
> Assignee: Stefan Guilhen
> Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}. Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
> java.lang.Thread.State: RUNNABLE
> at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
> at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
> at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
> at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
> at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
> at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
> at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
> at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
> at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
> at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> ...
> at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
> at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
> at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
> at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
> Locked ownable synchronizers:
> - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost. The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}. It is reproducible by manually controlling a thread context switch using a debugger.
--
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
11 years, 7 months
[JBoss JIRA] (JGRP-1805) OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1805:
---------------------------
Fix Version/s: 3.5
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
> Key: JGRP-1805
> URL: https://issues.jboss.org/browse/JGRP-1805
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
> [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
> [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
> [testng] -------------------------------------------------------------------
> [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
> [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
> [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
> [testng] -------------------------------------------------------------------
> [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A
> [testng] 184961 [DEBUG] GMS: - election results: {A=1}
> [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
> [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
> [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
> [testng]
> [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
> [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
> [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
> [testng]
> [testng]
> [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
> [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
> [testng] -------------------------------------------------------------------
> [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A
> [testng] 185064 [DEBUG] GMS: - election results: {A=2}
> [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
> [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
> [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
> [testng]
> [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
> [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
> [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
> [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
> [testng]
> [testng]
> [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
> [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
> [testng] -------------------------------------------------------------------
> [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A
> [testng] 185164 [DEBUG] GMS: - election results: {A=3}
> [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
> [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
> [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
> [testng]
> [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
> [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
> [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
> [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
> [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
> [testng]
> [testng]
> [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
> [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
> [testng]
> [testng] ==== Injecting view [A|4] [A, C, B] into A, B and C ====
> [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
> [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
> [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
> [testng]
> [testng] ==== Injecting view [B|4] [B, A, C, D] into D ====
> [testng]
> [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
> [testng] A: [A|4] [A, C, B]
> [testng] B: [A|4] [A, C, B]
> [testng] C: [A|4] [A, C, B]
> [testng] D: [B|4] [B, A, C, D]
> [testng]
> [testng] ==== Injecting a merge event into A, B, C and D====
> [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
> [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
> [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
> [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
> [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
> [testng]
> [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
> [testng]
> [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
> [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
> [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
> [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
> [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
> [testng] A: [A|5] [A, B, C] (coord=true)
> [testng] B: [A|5] [A, B, C] (coord=false)
> [testng] C: [A|5] [A, B, C] (coord=false)
> [testng] D: [B|4] [B, A, C, D] (coord=false)
> [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
> [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
> Whenever this test fails, I see that the queues are suspended on the initial merge attempt.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-2920) StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2920:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1064644, https://bugzilla.redhat.com/show_bug.cgi?id=1065196, https://bugzilla.redhat.com/show_bug.cgi?id=1072747 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1064644, https://bugzilla.redhat.com/show_bug.cgi?id=1065196)
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-2920
> URL: https://issues.jboss.org/browse/WFLY-2920
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: IIOP
> Affects Versions: 8.0.0.Final
> Reporter: Osamu Nagano
> Assignee: Stefan Guilhen
> Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}. Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
> java.lang.Thread.State: RUNNABLE
> at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
> at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
> at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
> at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
> at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
> at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
> at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
> at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
> at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
> at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> ...
> at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
> at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
> at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
> at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
> Locked ownable synchronizers:
> - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost. The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}. It is reproducible by manually controlling a thread context switch using a debugger.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3067) Annotations from .ear/lib are not visible to DUPs when processing subdeployments
by Kyle Lape (JIRA)
Kyle Lape created WFLY-3067:
-------------------------------
Summary: Annotations from .ear/lib are not visible to DUPs when processing subdeployments
Key: WFLY-3067
URL: https://issues.jboss.org/browse/WFLY-3067
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Class Loading
Affects Versions: 8.0.0.Final
Reporter: Kyle Lape
Assignee: David Lloyd
Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
{noformat}
UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
{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
11 years, 8 months