[JBoss JIRA] (DROOLS-477) KieScanner is not working as expected
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-477?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-477:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1096128|https://bugzilla.redhat.com/show_bug.cgi?id=1096128] from ON_QA to ASSIGNED
> KieScanner is not working as expected
> -------------------------------------
>
> Key: DROOLS-477
> URL: https://issues.jboss.org/browse/DROOLS-477
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Windows 7
> Reporter: Alexander Pykhtin
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta4
>
> Attachments: drools_jar.zip, drools_sample.zip
>
>
> KieScanner is not dynamically updates the rules in a sample application.
> drools_sample is a parent project, drools_jar is its dependency that is expected to be dynamically updated.
> Here is the sample code:
> Scanner scanner = new Scanner(System.in);
> try {
> KieServices ks = KieServices.Factory.get();
> ReleaseId releaseId = ks.newReleaseId( "com.study", "drools_sample", "0.0.1-SNAPSHOT" );
> KieContainer kContainer = ks.newKieContainer( releaseId );
> KieSession kSession = null;
> KieScanner kScanner = ks.newKieScanner( kContainer );
> boolean repeat = true;
> // go !
> while(repeat)
> {
> kSession = kContainer.newKieSession("ksession-rules_jar");
> Message message = new Message();
> message.setMessage("Hello World");
> message.setStatus(Message.HELLO);
> DynamicFactType dft = new DynamicFactType();
> kSession.insert(message);
> kSession.insert(dft);
> kSession.fireAllRules();
> kSession.dispose();
> String inp = scanner.nextLine();
> if(inp.length() > 0)
> repeat = false;
> else
> {
> kScanner.scanNow();
> }
> }
> } catch (Throwable t) {
> t.printStackTrace();
> }
> scanner.close();
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (SECURITY-844) LdapExLoginModule allow instance variables to remain 'null'
by Bartosz Baranowski (JIRA)
Bartosz Baranowski created SECURITY-844:
-------------------------------------------
Summary: LdapExLoginModule allow instance variables to remain 'null'
Key: SECURITY-844
URL: https://issues.jboss.org/browse/SECURITY-844
Project: PicketBox
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: PicketBox
Reporter: Bartosz Baranowski
Assignee: Stefan Guilhen
Affected version: PicketBox_4_0_19.SP8
Example: roleFilter may not be set.
Result:
{code}
12:40:02,129 DEBUG [org.jboss.security] (http-/10.36.6.166:8080-1) PBOX000206: Login failure: javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:284) [picketbox-4.0.19.SP8-redhat-1.jar:4.0.19.SP8-redhat-1]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_51]
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_51]
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_51]
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_51]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_51]
at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_51]
at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.19.SP8-redhat-1.jar:4.0.19.SP8-redhat-1]
at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.19.SP8-redhat-1.jar:4.0.19.SP8-redhat-1]
at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.19.SP8-redhat-1.jar:4.0.19.SP8-redhat-1]
at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.19.SP8-redhat-1.jar:4.0.19.SP8-redhat-1]
at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:216) [jboss-as-web-7.4.0.Final-redhat-SNAPSHOT.jar:7.4.0.Final-redhat-SNAPSHOT]
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:404) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-SNAPSHOT.jar:7.4.0.Final-redhat-SNAPSHOT]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.5.Final-redhat-1.jar:7.4.5.Final-redhat-1]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.lang.NullPointerException
at com.sun.jndi.toolkit.dir.SearchFilter.format(SearchFilter.java:585) [rt.jar:1.7.0_51]
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1784) [rt.jar:1.7.0_51]
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:412) [rt.jar:1.7.0_51]
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:394) [rt.jar:1.7.0_51]
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376) [rt.jar:1.7.0_51]
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286) [rt.jar:1.7.0_51]
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286) [rt.jar:1.7.0_51]
at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:647) [picketbox-4.0.19.SP8-redhat-1.jar:4.0.19.SP8-redhat-1]
at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:482) [picketbox-4.0.19.SP8-redhat-1.jar:4.0.19.SP8-redhat-1]
at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:343) [picketbox-4.0.19.SP8-redhat-1.jar:4.0.19.SP8-redhat-1]
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:281) [picketbox-4.0.19.SP8-redhat-1.jar:4.0.19.SP8-redhat-1]
... 27 more
{code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (WFLY-3211) java:app resources can not be shared between ejb and appclient modules
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3211?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-3211:
---------------------------------------
I'm not sure if the app client default config should include JMS, i.e. be a match for the "full" profile, I think it should go along the standard web profile of the Java EE platform.
> java:app resources can not be shared between ejb and appclient modules
> ----------------------------------------------------------------------
>
> Key: WFLY-3211
> URL: https://issues.jboss.org/browse/WFLY-3211
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Eduardo Martins
>
> use case:
> 1 ear composed of:
> 1 appclient module that defines 2 JMS queues (one in java:app, the other in java:global)
> 1 ejb modules with 2 MDBs (one listening to the java:app queue and the other to the java:global queue)
> When the ear is deployed:
> 1. the ejb module is deployed, the MDBs are created and wait for the creations of their respective queues (defined in the appclient module)
> 2. the appclient module is deployed, its 2 queues are deployed
> 3. the appclient main is run
> When the appclient uses the java:global queue, it looks it up, sends the message and the corresponding MDB receives it fine.
> When the appclient uses the java:app queue, it looks it up, sends the message but the corresponding MDB never receives it
> => the MDB was never deployed because it did not see the java:app queue deployed from the appclient module.
> Note that if I move the destination definitions to the ejb module, the MDBs are correctly activated but the appclient module is no longer deployed with errors:
> {noformat}
> [APPCLIENT-out] {"JBAS014771: Services with missing/unavailable dependencies" => [
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInGlobal is missing [jboss.naming.context.java.global.jms.queu
> e.queue1]",
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInApp is missing [jboss.naming.context.java.app.simple-jms-app
> client-test.jms.queue.queue2]"
> [APPCLIENT-out] ]}
> {noformat}
> Steps to reproduce:
> 1. fetch git branch https://github.com/jmesnil/wildfly/tree/jms_appclient
> 2. build WildFly
> 3. run ./integration-tests.sh -Dts.basic -Dtest=org.jboss.as.test.integration.ee.appclient.jms.basic.SimpleJMSApplicationClientTestCase -DnoWebProfile
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (WFLY-3460) Async servlet: HttpServletResponse.sendError() throws UT000048 if error page set
by Darren Jones (JIRA)
Darren Jones created WFLY-3460:
----------------------------------
Summary: Async servlet: HttpServletResponse.sendError() throws UT000048 if error page set
Key: WFLY-3460
URL: https://issues.jboss.org/browse/WFLY-3460
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.1.0.Final
Environment: Windows 7 Professional, Java 7u55
Reporter: Darren Jones
Assignee: Stuart Douglas
If an async servlet calls sendError(...) when an <error-page> is added to the web.xml, the exception below occurs. If the <error-page> is removed (not possible for me), the servlet works just fine.
Exception in thread "default task-29" java.lang.IllegalStateException: UT000048: No request is currently active
at io.undertow.servlet.handlers.ServletRequestContext.requireCurrent(ServletRequestContext.java:63)
at io.undertow.servlet.spec.SecurityActions.requireCurrentServletRequestContext(SecurityActions.java:86)
at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:324)
at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:311)
at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:128)
at TestAsyncServlet$1.run(TestAsyncServlet.java:25)
at io.undertow.servlet.spec.AsyncContextImpl$4.run(AsyncContextImpl.java:309)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (WFLY-3211) java:app resources can not be shared between ejb and appclient modules
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3211?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-3211:
---------------------------------------
The issue is shown with messaging subsystem on the app client config too, it's a really HornetQ looking for a deployment scoped bind, but that is only visible if using the correct NamespaceContextSelector
> java:app resources can not be shared between ejb and appclient modules
> ----------------------------------------------------------------------
>
> Key: WFLY-3211
> URL: https://issues.jboss.org/browse/WFLY-3211
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Eduardo Martins
>
> use case:
> 1 ear composed of:
> 1 appclient module that defines 2 JMS queues (one in java:app, the other in java:global)
> 1 ejb modules with 2 MDBs (one listening to the java:app queue and the other to the java:global queue)
> When the ear is deployed:
> 1. the ejb module is deployed, the MDBs are created and wait for the creations of their respective queues (defined in the appclient module)
> 2. the appclient module is deployed, its 2 queues are deployed
> 3. the appclient main is run
> When the appclient uses the java:global queue, it looks it up, sends the message and the corresponding MDB receives it fine.
> When the appclient uses the java:app queue, it looks it up, sends the message but the corresponding MDB never receives it
> => the MDB was never deployed because it did not see the java:app queue deployed from the appclient module.
> Note that if I move the destination definitions to the ejb module, the MDBs are correctly activated but the appclient module is no longer deployed with errors:
> {noformat}
> [APPCLIENT-out] {"JBAS014771: Services with missing/unavailable dependencies" => [
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInGlobal is missing [jboss.naming.context.java.global.jms.queu
> e.queue1]",
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInApp is missing [jboss.naming.context.java.app.simple-jms-app
> client-test.jms.queue.queue2]"
> [APPCLIENT-out] ]}
> {noformat}
> Steps to reproduce:
> 1. fetch git branch https://github.com/jmesnil/wildfly/tree/jms_appclient
> 2. build WildFly
> 3. run ./integration-tests.sh -Dts.basic -Dtest=org.jboss.as.test.integration.ee.appclient.jms.basic.SimpleJMSApplicationClientTestCase -DnoWebProfile
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (WFLY-3211) java:app resources can not be shared between ejb and appclient modules
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3211?page=com.atlassian.jira.plugin.... ]
Eduardo Martins edited comment on WFLY-3211 at 6/6/14 6:40 AM:
---------------------------------------------------------------
The issue is shown with messaging subsystem on the app client config too, it's really HornetQ looking for a deployment scoped bind, but that is only visible if using the correct NamespaceContextSelector
was (Author: emmartins):
The issue is shown with messaging subsystem on the app client config too, it's a really HornetQ looking for a deployment scoped bind, but that is only visible if using the correct NamespaceContextSelector
> java:app resources can not be shared between ejb and appclient modules
> ----------------------------------------------------------------------
>
> Key: WFLY-3211
> URL: https://issues.jboss.org/browse/WFLY-3211
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Eduardo Martins
>
> use case:
> 1 ear composed of:
> 1 appclient module that defines 2 JMS queues (one in java:app, the other in java:global)
> 1 ejb modules with 2 MDBs (one listening to the java:app queue and the other to the java:global queue)
> When the ear is deployed:
> 1. the ejb module is deployed, the MDBs are created and wait for the creations of their respective queues (defined in the appclient module)
> 2. the appclient module is deployed, its 2 queues are deployed
> 3. the appclient main is run
> When the appclient uses the java:global queue, it looks it up, sends the message and the corresponding MDB receives it fine.
> When the appclient uses the java:app queue, it looks it up, sends the message but the corresponding MDB never receives it
> => the MDB was never deployed because it did not see the java:app queue deployed from the appclient module.
> Note that if I move the destination definitions to the ejb module, the MDBs are correctly activated but the appclient module is no longer deployed with errors:
> {noformat}
> [APPCLIENT-out] {"JBAS014771: Services with missing/unavailable dependencies" => [
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInGlobal is missing [jboss.naming.context.java.global.jms.queu
> e.queue1]",
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInApp is missing [jboss.naming.context.java.app.simple-jms-app
> client-test.jms.queue.queue2]"
> [APPCLIENT-out] ]}
> {noformat}
> Steps to reproduce:
> 1. fetch git branch https://github.com/jmesnil/wildfly/tree/jms_appclient
> 2. build WildFly
> 3. run ./integration-tests.sh -Dts.basic -Dtest=org.jboss.as.test.integration.ee.appclient.jms.basic.SimpleJMSApplicationClientTestCase -DnoWebProfile
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (DROOLS-207) Transitive dependencies are not in sync with EAP: scannotation and xmlschema-core
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-207?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer closed DROOLS-207.
-----------------------------------------
> Transitive dependencies are not in sync with EAP: scannotation and xmlschema-core
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-207
> URL: https://issues.jboss.org/browse/DROOLS-207
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Minor
>
> > EAP 6.1 --> kie-wb.war
> > ---------------------------------------------------------
> > EAP has scannotation-1.0.2-redhat-2.jar --> kie-wb has 1.0.3
> > EAP has xmlschema-core-2.0.2-redhat-2.jar --> kie-wb has 2.0.3
> In theory this should not be able to happen.
> A dependency:tree on kie-wb show this:
> {code}
> [INFO] org.kie:kie-wb-webapp:war:6.1.0-SNAPSHOT
> ...
> [INFO] +- org.jbpm:jbpm-designer-backend:jar:6.1.0-SNAPSHOT:compile
> ...
> [INFO] | +- org.jbpm:jbpm-workitems:jar:6.1.0-SNAPSHOT:compile (version managed from 6.1.0-SNAPSHOT)
> ...
> [INFO] | | \- org.apache.ws.xmlschema:xmlschema-core:jar:2.0.3:compile
> {code}
> and also
> {code}
> [INFO] org.kie:kie-wb-distribution-wars:pom:6.1.0-SNAPSHOT
> ...
> [INFO] +- org.jboss.resteasy:resteasy-jaxrs:jar:2.3.6.Final:compile
> [INFO] | +- org.scannotation:scannotation:jar:1.0.3:compile
> {code}
> Investigate if any of those artifacts aren't messing with the transitive dependency version by overwriting their version. It's also possible that the bug is on the side of EAP (if they overwrite one of their transitive dependencies with a lower version).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months