[JBoss JIRA] (WFLY-1296) LdapExtLoginModule fails with follow referral
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-1296:
----------------------------------
Summary: LdapExtLoginModule fails with follow referral
Key: WFLY-1296
URL: https://issues.jboss.org/browse/WFLY-1296
Project: WildFly
Issue Type: Bug
Components: Security
Environment: Probably not relevant, but Win 7 64, tried on jdk 6 and 7 64-bit.
Reporter: Ondrej Lukas
Assignee: Peter Skopek
We connect to AD with LdapExtLoginModule. It so happens that AD keeps references to some external trees (such as "DomainDnsZones" and "ForestDnsZones") in the root of the LDAP tree. So when you configure LdapExtLoginModule to search any root, it will hit these referrals.
This normally fails with a standard
{code}
javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
{code}
. This is not the whole story, though. If you enable the module option
{code}<module-option name="throwValidateError" value="true"/>{code}
, you get a more complete stack trace:
{code}
09:18:14,724 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-2) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:270) [picketbox-4.0.7.Final.jar:4.0.7.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [rt.jar:1.7.0]
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0]
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0]
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0]
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0]
at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0]
at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19) [classes:]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
Caused by: javax.naming.PartialResultException [Root exception is javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,...; remaining name 'dc=global,dc=scd,dc=company,dc=com']
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:242) [rt.jar:1.7.0]
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189) [rt.jar:1.7.0]
at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534) [picketbox-4.0.7.Final.jar:4.0.7.Final]
at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445) [picketbox-4.0.7.Final.jar:4.0.7.Final]
at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312) [picketbox-4.0.7.Final.jar:4.0.7.Final]
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267) [picketbox-4.0.7.Final.jar:4.0.7.Final]
... 29 more
Caused by: javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,...; remaining name 'dc=global,dc=scd,dc=company,dc=com'
at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:141) [rt.jar:1.7.0]
at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150) [rt.jar:1.7.0]
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357) [rt.jar:1.7.0]
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226) [rt.jar:1.7.0]
... 34 more
{code}
When debugging this error, I concluded that the culprit is that ObjectFactoryBuilder doesn't resolve the reference correctly. getObjectInstance returns the reference instead of resolving it at the following location:
{code}
at org.jboss.as.naming.context.ObjectFactoryBuilder.getObjectInstance(ObjectFactoryBuilder.java:87)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:111)
at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357)
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226)
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189)
at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534)
at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445)
at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
at java.security.AccessController.doPrivileged(AccessController.java:-1)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
at java.lang.Thread.run(Thread.java:722)
{code}
The relevant bit of code is:
{code}
public Object getObjectInstance(final Object ref, final Name name, final Context nameCtx, final Hashtable<?, ?> environment) throws Exception {
final ClassLoader classLoader = SecurityActions.getContextClassLoader();
if(classLoader == null) {
return ref;
}
{code}
So this bit of code doesn't resolve the ref it the context classloader is null. Instead of aborting, it returns the ref unresolved. LdapReferralContext gets very confused when NamingManager doesn't resolve the reference, and throws the aforementioned NotContextException.
When debugging where the context classloader is set to null I found the following location:
{code}
http--127.0.0.1-8080-2@12911 daemon, prio=5, in group 'main', status: 'RUNNING'
at java.lang.Thread.setContextClassLoader(Thread.java:1480)
at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:59)
at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:56)
at java.security.AccessController.doPrivileged(AccessController.java:-1)
at org.jboss.security.auth.spi.SecurityActions.setContextClassLoader(SecurityActions.java:55)
at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:435)
at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
at java.security.AccessController.doPrivileged(AccessController.java:-1)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
at java.lang.Thread.run(Thread.java:722)
{code}
Unfortunately I haven't been able to find the source code for this location. But it is clear that LdapExtLoginModule does set the context classloader to null in validatePassword. I haven't come up with any way of avoiding this.
While trying to circumvent this bug I tried to avoid following the AD referral. This doesn't seem to be possible, though. When setting "java.naming.referral" to "ignore", you would expect that the login would succeed. But as documented at http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html , some LDAP implementations might still throw a PartialResultException. This is indeed what I get:
{code}
Caused by: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=global,dc=scd,dc=company,dc=com'
{code}
Spring points this out at http://static.springsource.org/spring-ldap/site/apidocs/org/springframewo... and has a way of supressing these exceptions: "ignorePartialResultException".
With JBoss lacking this, I am stuck between a rock and a hard place. I cannot enable referrals due to the null context class loader bug, and I cannot disable them due to the PartialResultException bug.
So I would call this one a blocker. Any suggestions are greatly appreciated, as we are stuck upgrading to AS 7. This is a regression, by the way, since "follow" used to work on AS 5.1.0.GA which we are upgrading from.
The only way of avoiding this problem that I've found is to narrow the tree which you search through in AD in such a way that you avoid hitting the referrals at all. There are a couple of related bugs and forum posts (see for instance https://issues.jboss.org/browse/AS7-2085), but I don't think any of them really nailed the problem down. It's pretty tricky since you don't even get a relevant stacktrace unless you enable "throwValidateError".
Thanks
--
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
13 years, 2 months
[JBoss JIRA] (WFLY-1297) Possible race when restoring persistent bundles
by Thomas Diesler (JIRA)
Thomas Diesler created WFLY-1297:
------------------------------------
Summary: Possible race when restoring persistent bundles
Key: WFLY-1297
URL: https://issues.jboss.org/browse/WFLY-1297
Project: WildFly
Issue Type: Bug
Components: OSGi
Reporter: Thomas Diesler
Assignee: Thomas Diesler
There is a possible race when restoring persistent bundles. The FrameworkActivateProcessor may want to activate the framework before FrameworkBootstrapService.start() completes.
{code}
[0m [31m14:33:49,853 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."de.xxx.yyy.data.services.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."de.xxx.yyy.data.services.jar".PARSE: JBAS018733: Failed to process phase PARSE of deployment "de.xxx.yyy.data.services.jar"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
Caused by: java.lang.NullPointerException
at org.jboss.as.osgi.service.FrameworkActivator.activate(FrameworkActivator.java:76)
at org.jboss.as.osgi.deployment.FrameworkActivateProcessor.deploy(FrameworkActivateProcessor.java:72)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
{code}
--
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
13 years, 2 months
[JBoss JIRA] (WFLY-227) Move Webservices client-config management into an MSC service
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-227?page=com.atlassian.jira.plugin.s... ]
Paul Robinson resolved WFLY-227.
--------------------------------
Resolution: Done
> Move Webservices client-config management into an MSC service
> -------------------------------------------------------------
>
> Key: WFLY-227
> URL: https://issues.jboss.org/browse/WFLY-227
> Project: WildFly
> Issue Type: Enhancement
> Components: Web Services
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 8.0.0.Alpha1
>
>
> Currently the client configuration is managed in 'add' and 'remove' step handlers. This causes two problems:
> 1) Other services can not depend on this configuration being ready.
> 2) Injection can't be used to obtain the ServerConfig.
> The solution is to have the add and remove step handlers start and stop a service (respectively). This service is dependent on the CONFIG_SERVICE and has the ServerConfig injected. Other services that need the ClientConfig can depend on this service.
--
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
13 years, 2 months
[JBoss JIRA] (DROOLS-103) NPE in PackageBuilderContext for mvel related code
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-103?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-103:
------------------------------------------
Fix Version/s: 6.0.0.CR1
(was: 6.0.0.Beta2)
> NPE in PackageBuilderContext for mvel related code
> --------------------------------------------------
>
> Key: DROOLS-103
> URL: https://issues.jboss.org/browse/DROOLS-103
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Fix For: 6.0.0.CR1
>
>
> On jenkins drools often craches on this line in PackageBuildContext:
> {code}
> this.typesafe = ((MVELDialect) dialectRegistry.getDialect( "mvel" )).isStrictMode();
> {code}
> This happens in the optaplanner and optaplanner-runTurtleTests jobs.
> Locally I haven't seen it yet.
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/Drools%20jBPM/view/...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/Drools%20jBPM/view/...
> {code}
> java.lang.NullPointerException
> at org.drools.compiler.rule.builder.PackageBuildContext.init(PackageBuildContext.java:101)
> at org.drools.compiler.rule.builder.RuleBuildContext.<init>(RuleBuildContext.java:78)
> at org.drools.compiler.compiler.PackageBuilder.addRule(PackageBuilder.java:3028)
> at org.drools.compiler.compiler.PackageBuilder.compileRules(PackageBuilder.java:948)
> at org.drools.compiler.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:854)
> at org.drools.compiler.compiler.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:233)
> at org.drools.compiler.compiler.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:88)
> at org.drools.compiler.compiler.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:76)
> at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:140)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:39)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieModule(KieBuilderImpl.java:207)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:160)
> at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildKieBase(ScoreDirectorFactoryConfig.java:305)
> at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildDroolsScoreDirectorFactory(ScoreDirectorFactoryConfig.java:273)
> at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:180)
> at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:168)
> at org.optaplanner.core.config.solver.SolverConfig.buildSolver(SolverConfig.java:144)
> at org.optaplanner.core.config.solver.XmlSolverFactory.buildSolver(XmlSolverFactory.java:104)
> at org.optaplanner.examples.common.app.SolverPerformanceTest.solve(SolverPerformanceTest.java:86)
> at org.optaplanner.examples.common.app.SolverPerformanceTest.runSpeedTest(SolverPerformanceTest.java:71)
> at org.optaplanner.examples.examination.app.ExaminationPerformanceTest.solveComp_set5FastAssert(ExaminationPerformanceTest.java:52)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
> {code}
--
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
13 years, 2 months
[JBoss JIRA] (DROOLS-88) Support generics in declared types' fields
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-88?page=com.atlassian.jira.plugin.... ]
Michael Biarnes Kiefer updated DROOLS-88:
-----------------------------------------
Fix Version/s: 6.0.0.CR1
(was: 6.0.0.Beta2)
> Support generics in declared types' fields
> ------------------------------------------
>
> Key: DROOLS-88
> URL: https://issues.jboss.org/browse/DROOLS-88
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Davide Sottara
> Assignee: Davide Sottara
> Priority: Minor
> Fix For: 5.5.1.Final, 6.0.0.CR1
>
>
> It should be possible to write:
> declare Foo
> list : List<String>
> end
> While not supported in rules using the mvel dialect, it makes declared types much more readable, and adds some type-safety to java rules.
> Notice that this ticket is NOT related to the possibility of declaring generic classes, such as Foo<T>.
--
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
13 years, 2 months
[JBoss JIRA] (JASSIST-196) Dont use ==, instead use .equals() for strings
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-196?page=com.atlassian.jira.plugi... ]
Shigeru Chiba resolved JASSIST-196.
-----------------------------------
Fix Version/s: 3.17.1-GA
Resolution: Rejected
The use of == is not a bug but specification.
Please see the javadoc of that method javassist.compiler.AccessorMaker#getMethodAccessor.
> Dont use ==, instead use .equals() for strings
> ----------------------------------------------
>
> Key: JASSIST-196
> URL: https://issues.jboss.org/browse/JASSIST-196
> Project: Javassist
> Issue Type: Quality Risk
> Affects Versions: 3.17.1-GA
> Reporter: oliver z
> Assignee: Shigeru Chiba
> Fix For: 3.17.1-GA
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> I just used a code quality tool to scan my application which uses javassist.
> It is complaining about a few "==" instead of .equals().
> Occurance at least in: AccessorMaker.java:127
> Would be nice if this could be fixed because as its a very little change.
> Thanks!
--
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
13 years, 2 months
[JBoss JIRA] (WFLY-962) Unable to combine Resource Archive (RAR) <dependencies> and <exclusions> directives in jboss-deployment-structure.xml without <exclusions> being ignored
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-962?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas reassigned WFLY-962:
-----------------------------------
Assignee: Stuart Douglas (was: David Lloyd)
> Unable to combine Resource Archive (RAR) <dependencies> and <exclusions> directives in jboss-deployment-structure.xml without <exclusions> being ignored
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-962
> URL: https://issues.jboss.org/browse/WFLY-962
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Environment: Linux (CentOS 6.3), JDK 1.6.0_37
> Reporter: Matthew White
> Assignee: Stuart Douglas
> Attachments: jbossas-bugexample.zip
>
>
> I have an EAR file where for a WAR sub-deployment I want to declare a startup dependency on another Resource Archive (RAR) deployment (in my application's case, the WebSphere MQ RAR - but I have recreated this with other Resource Archives) and also have a module exclusion (in this case, on the org.apache.log4j module so that my application can use internally defined Log4J configuration).
> The jboss-deployment-structure.xml for the EAR looks like this :-
> {code:xml}
> <jboss-deployment-structure>
> <sub-deployment name="application.war">
> <dependencies>
> <module name="deployment.wmq.jmsra.rar" />
> </dependencies>
> <exclusions>
> <module name="org.apache.log4j" />
> </exclusions>
> </sub-deployment>
> </jboss-deployment-structure>
> {code}
> When I startup the EAR, the <dependencies> directive for the sub-deployment takes effect - the WAR is not started until the WebSphere MQ RAR is available. However, my <exclusions> directive is ignored and the application Log4J configuration is not used.
> If I restructure the jboss-deployment-structure.xml and remove the <dependencies> directive from the sub-deployment :-
> {code:xml}
> <jboss-deployment-structure>
> <sub-deployment name="application.war">
> <exclusions>
> <module name="org.apache.log4j" />
> </exclusions>
> </sub-deployment>
> </jboss-deployment-structure>
> {code}
> The <exclusions> directive is interpreted correctly and the application Log4J configuration is used.
> Also, if I go the other way and remove the <exclusions> directive and put the the <dependencies> directive back :-
> {code:xml}
> <jboss-deployment-structure>
> <sub-deployment name="application.war">
> <dependencies>
> <module name="deployment.wmq.jmsra.rar" />
> </dependencies>
> </sub-deployment>
> </jboss-deployment-structure>
> {code}
> The <dependencies> continues to be interpreted correctly and the WAR does not start until the dependency is available.
> It would just seem that I can't combine the two directives and have them both be interpreted correctly. I have tried changing the order of defining them in the file but that (unsurprisingly) didn't make a lot of difference.
> I have also tried this with the dependency being any other type of deployment - EAR, WAR, JAR, etc - and in those cases everything works correctly. It seems to only be an issue if the dependency is a Resource Archive.
> I've also given it a go on a recent 7.2.0 Nightly (3 Jan 2013) and it is also exhibiting the same behaviour.
> I have attached a sample application to replicate this behaviour. It uses the Apache Jackrabbit RAR (since the WebSphere MQ one is not distributable) as the Resource Archive dependency and creates 2 EAR files that are trying to use log4j to log to a file - one with just the <exclusions> directive and one with both the <dependencies> and <exclusions> directives. See the README file in the zip for more details.
--
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
13 years, 2 months