[JBoss JIRA] (DROOLS-597) Dynamic salience does'nt work
by Yacine Jaber (JIRA)
[ https://issues.jboss.org/browse/DROOLS-597?page=com.atlassian.jira.plugin... ]
Yacine Jaber updated DROOLS-597:
--------------------------------
Steps to Reproduce:
Please see the attached a simple maven project that reproduce and explain this JIRA.
This project perform a test with some of persons which should be fired according to their age.
> Dynamic salience does'nt work
> -----------------------------
>
> Key: DROOLS-597
> URL: https://issues.jboss.org/browse/DROOLS-597
> Project: Drools
> Issue Type: Bug
> Environment: Eclipse/Windows 7 - 64 bits
> Reporter: Yacine Jaber
> Assignee: Mark Proctor
> Attachments: SalienceProject.7z, WodSalienceImpl.java
>
>
> I have implemented my own bean (Salience) that manage the dynamic salience for the rules.
> After building the drl file i overlaod the salience of the rules with my dynamic salience WodSalienceImpl(Attached file).
> However, the salience is not respected even if this bean was called (getValue) before the match creation.
> N.B: I used MVELSalience by writing the dynamic salience into the rules(MEVL expression). The result was the same.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (DROOLS-597) Dynamic salience does'nt work
by Yacine Jaber (JIRA)
[ https://issues.jboss.org/browse/DROOLS-597?page=com.atlassian.jira.plugin... ]
Yacine Jaber updated DROOLS-597:
--------------------------------
Attachment: SalienceProject.7z
Please see the attached a simple maven project that reproduce and explain this JIRA.
This project perform a test with some of persons which should be fired according to their age.
> Dynamic salience does'nt work
> -----------------------------
>
> Key: DROOLS-597
> URL: https://issues.jboss.org/browse/DROOLS-597
> Project: Drools
> Issue Type: Bug
> Environment: Eclipse/Windows 7 - 64 bits
> Reporter: Yacine Jaber
> Assignee: Mark Proctor
> Attachments: SalienceProject.7z, WodSalienceImpl.java
>
>
> I have implemented my own bean (Salience) that manage the dynamic salience for the rules.
> After building the drl file i overlaod the salience of the rules with my dynamic salience WodSalienceImpl(Attached file).
> However, the salience is not respected even if this bean was called (getValue) before the match creation.
> N.B: I used MVELSalience by writing the dynamic salience into the rules(MEVL expression). The result was the same.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (DROOLS-507) Cannot issue fireUntilHalt when using persisted session
by Dushman Elvitigala (JIRA)
[ https://issues.jboss.org/browse/DROOLS-507?page=com.atlassian.jira.plugin... ]
Dushman Elvitigala commented on DROOLS-507:
-------------------------------------------
Is there any update on this? i'm facing the same issue..
> Cannot issue fireUntilHalt when using persisted session
> -------------------------------------------------------
>
> Key: DROOLS-507
> URL: https://issues.jboss.org/browse/DROOLS-507
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.1.0.Beta3
> Environment: Mac OSX Maverick, Spring 4.0.1
> Reporter: Roger Lefebvre
> Assignee: Mark Proctor
>
> Generating the following exception when using runUntilHalt() with persistence.
> Exception in thread "SimpleAsyncTaskExecutor-1" java.lang.UnsupportedOperationException: Command session.fireUntilHalt(); cannot be issued on a persisted session at org.drools.persistence.SingleSessionCommandService$TransactionInterceptor.execute(SingleSessionCommandService.java:474) at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:353) at org.drools.core.command.impl.CommandBasedStatefulKnowledgeSession.fireUntilHalt(CommandBasedStatefulKnowledgeSession.java:272) at com.s.c.m.CallHandler$RunEngine.run(CallHandler.java:115) at java.lang.Thread.run(Thread.java:722)
> Persistence and KieSession defined in Spring as follows:
> <!-- provides KnowledgeStoreService implementation -->
> <kie:kstore id="kstore"/>
> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
> <property name="driverClassName" value="com.mysql.jdbc.Driver" />
> <property name="url" value="jdbc:mysql://localhost:3306/ruleEngine" />
> <property name="username" value="xxxxxx" /> <property name="password" value="yyyyyyyy" />
> </bean>
> <bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
> <property name="dataSource" ref="dataSource"/>
> <property name="persistenceUnitName" value="org.drools.persistence.jpa.local"/>
> </bean>
> <bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager">
> <property name="entityManagerFactory" ref="emf"/>
> </bean>
> <kie:kmodule id="callManagerModule">
> <kie:kbase name="commandKBase" packages="rules.command" eventProcessingMode="stream">
> <kie:ksession name="commandEngine" type="stateful"></kie:ksession>
> </kie:kbase>
> <kie:kbase name="campaignKBase" packages="rules.campaign.*" eventProcessingMode="stream" equalsBehavior="equality">
> <kie:ksession name="campaignEngine" type="stateful" >
> <kie:consoleLogger/>
> <kie:configuration>
> <kie:jpa-persistence>
> <kie:transaction-manager ref="txManager"/>
> <kie:entity-manager-factory ref="emf"/>
> </kie:jpa-persistence>
> </kie:configuration>
> </kie:ksession>
> </kie:kbase>
> </kie:kmodule>
> <bean id="taskExecutor" class="org.springframework.core.task.SimpleAsyncTaskExecutor">
> <property name="daemon" value="true"/>
> </bean>
> <bean id="campaignHandler" class="com.s.c.m.CallHandler" init-method="init">
> <constructor-arg type="org.springframework.core.task.TaskExecutor" ref="taskExecutor"/>
> </bean>
> I invoke fireUntilHalt method as follows:
>
> private TaskExecutor taskExecutor;
> public CampaignCallHandler(TaskExecutor taskExecutor) {
> this.taskExecutor = taskExecutor; }
> public void init() { taskExecutor.execute(new RunEngine()); }
> class RunEngine implements Runnable {
> @Override public void run() { campaignEngine.fireUntilHalt(); } }
> NOTE: This occurs on a new system where nothing has been persisted to the database. In other words, there isn't a session available to be loaded. I have yet to have success reloading a session - that is a separate issue that I believe DROOLS-422 partially identifies.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-1167) AS7/EAP6 @Stateless/mappedName behaviour could be made consistent with AS5/EAP5
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1167?page=com.atlassian.jira.plugin.... ]
Stuart Douglas closed WFLY-1167.
--------------------------------
Resolution: Rejected
If we do this now it would just break compatibility for existing EAP6/Wildfly users.
> AS7/EAP6 @Stateless/mappedName behaviour could be made consistent with AS5/EAP5
> -------------------------------------------------------------------------------
>
> Key: WFLY-1167
> URL: https://issues.jboss.org/browse/WFLY-1167
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Environment: Windows7
> Reporter: Baptiste MATHUS
> Labels: regression
>
> Though I agree mappedName was never meant to be standard, as reminded in the link below, at least it was something done within JBoss AS, and I wonder if something better for *JBoss* users&customers couldn't be made to help them.
> How difficult would it be for example to bind SLSB to the given mappedName (in addition to the standard portable jndi naming, sure)?
> I admit we've certainly been using it the wrong way in our shop, but that's how it is now, and today this change is currently being one of the biggest PITA for us to migrate between EAP5 and EAP6...
> By the way, even a special patch or workaround that could make that possible would be perfect.
> WDYT?
> Thanks!
> (Note: I already read carefully the following thread: http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002246.html I searched the jiras without finding one about that subject, so I eventually decided to create this entry for potential reference).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-3221) flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3221?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3221:
------------------------------------
Assignee: Stuart Douglas (was: Darran Lofthouse)
> flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials
> -------------------------------------------------------------------------------------
>
> Key: WFLY-3221
> URL: https://issues.jboss.org/browse/WFLY-3221
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.0.0.Final
> Reporter: Jorge Marmolejo
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 9.0.0.Alpha1
>
>
> The attribute flushOnSessionInvalidation does not flush the user credentials when the session is invalidated or when it times out. If the password or roles change for the user, the only way to get the new changes is by restarting the server.
> I tried removing "cache-type=default" from the standalone-full.xml and it works, but for every action made on the site, the login method in the authentication module is called.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-2524) logging-profile works for a servlet, but doesn't for a JSP
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2524?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2524:
-----------------------------------------------
James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1031448|https://bugzilla.redhat.com/show_bug.cgi?id=1031448] from ASSIGNED to POST
> logging-profile works for a servlet, but doesn't for a JSP
> ----------------------------------------------------------
>
> Key: WFLY-2524
> URL: https://issues.jboss.org/browse/WFLY-2524
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 8.0.0.Beta1
> Reporter: Osamu Nagano
> Assignee: James Perkins
> Attachments: logone.zip
>
>
> Suppose the following logging-profile has been set in logging subsystem, and a web app has a proper entry in its MANIFEST.MF ({{Logging-Profile: logone}}). Then all messages via "com.example.logone" logger should go into a file, logone.log. It does so with a logger got in a servlet, but it doesn't work a logger got in a JSP.
> {code}
> <logging-profiles>
> <logging-profile name="logone">
> <file-handler name="logone">
> <level name="INFO"/>
> <file relative-to="jboss.server.log.dir" path="logone.log"/>
> </file-handler>
> <logger category="com.example.logone">
> <level name="INFO"/>
> </logger>
> <root-logger>
> <level name="INFO"/>
> <handlers>
> <handler name="logone"/>
> </handlers>
> </root-logger>
> </logging-profile>
> </logging-profiles>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-3820) Unable to invoke @PreDestroy annotated methods on org.jboss.as.jsf.injection.JSFInjectionProvider
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3820?page=com.atlassian.jira.plugin.... ]
Farah Juma resolved WFLY-3820.
------------------------------
Fix Version/s: 9.0.0.Alpha1
Resolution: Done
Thanks for the patch, [~the_alchemist]!
> Unable to invoke @PreDestroy annotated methods on org.jboss.as.jsf.injection.JSFInjectionProvider
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-3820
> URL: https://issues.jboss.org/browse/WFLY-3820
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.1.0.Final
> Reporter: Karl Pietrzak
> Assignee: Farah Juma
> Priority: Minor
> Fix For: 9.0.0.Alpha1
>
>
> {noformat}
> 12:21:52,402 SEVERE [javax.faces] (Mojarra-WebResourceMonitor-1-thread-1) Unable to invoke @PreDestroy annotated methods on org.jboss.as.jsf.injection.JSFInjectionProvider@ebc02f7.: java.lang.NullPointerException
> at org.jboss.as.jsf.injection.JSFInjectionProvider.invokePreDestroy(JSFInjectionProvider.java:49) [wildfly-jsf-injection-8.1.0.Final.jar:8.1.0.Final]
> at javax.faces.FactoryFinder.releaseFactories(FactoryFinder.java:442) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at com.sun.faces.config.ConfigManager.releaseFactories(ConfigManager.java:809) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:446) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.config.ConfigureListener.reload(ConfigureListener.java:568) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.config.ConfigureListener.access$600(ConfigureListener.java:121) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor.run(ConfigureListener.java:1039) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_67]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) [rt.jar:1.7.0_67]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_67]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
> {noformat}
> {noformat}
> 12:21:52,403 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) com.sun.faces.config.ConfigurationException: Factory 'javax.faces.application.ApplicationFactory' was not configured properly.
> 12:21:52,403 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:330)
> 12:21:52,403 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:236)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:435)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at com.sun.faces.config.ConfigureListener.reload(ConfigureListener.java:568)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at com.sun.faces.config.ConfigureListener.access$600(ConfigureListener.java:121)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor.run(ConfigureListener.java:1039)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 12:21:52,404 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at java.lang.Thread.run(Thread.java:745)
> 12:21:52,405 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) Caused by: javax.faces.FacesException: org.jboss.as.jsf.injection.weld.WeldApplicationFactory
> 12:21:52,405 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:710)
> 12:21:52,405 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:572)
> 12:21:52,405 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at javax.faces.FactoryFinder.access$500(FactoryFinder.java:140)
> 12:21:52,405 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1120)
> 12:21:52,405 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:379)
> 12:21:52,405 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:328)
> 12:21:52,405 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) ... 12 more
> 12:21:52,405 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) Caused by: com.sun.faces.spi.InjectionProviderException: java.lang.NullPointerException
> 12:21:52,406 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at org.jboss.as.jsf.injection.JSFInjectionProvider.invokePostConstruct(JSFInjectionProvider.java:63)
> 12:21:52,406 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:696)
> 12:21:52,406 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) ... 17 more
> 12:21:52,406 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) Caused by: java.lang.NullPointerException
> 12:21:52,406 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) at org.jboss.as.jsf.injection.JSFInjectionProvider.invokePostConstruct(JSFInjectionProvider.java:61)
> 12:21:52,406 ERROR [stderr] (Mojarra-WebResourceMonitor-1-thread-1) ... 18 more
> 12:21:52,406 INFO [javax.enterprise.resource.webcontainer.jsf.config] (Mojarra-WebResourceMonitor-1-thread-1) Reload complete.
> {noformat}
> Sometimes I get this error on reload. Difficult to reproduce, but I think it has to do with the {{instanceManager}} being null in the {{JSFInjectionProvider.java}}. I'll submit a pull request to check for null.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (WFLY-3845) Share the same jsessionid in different context root
by Sandeep Samdaria (JIRA)
[ https://issues.jboss.org/browse/WFLY-3845?page=com.atlassian.jira.plugin.... ]
Sandeep Samdaria commented on WFLY-3845:
----------------------------------------
By "share", I mean that the JSESSIONID doesn't change when I switch my context in the browser. For e.g. When I visit localhost/abc , I would get JSESSIONID="ABC123" and when I visit localhost/xyz, I would get the same JSESSIONID i.e. "ABC123". In jboss-eap-6.2 this is the behavior, but in wildfly.8.1.0 when I visit localhost/xyz I get a different JSESSIONID "ZYX987" and when I revisit localhost/abc the previous session is lost and I get a new id.
> Share the same jsessionid in different context root
> ----------------------------------------------------
>
> Key: WFLY-3845
> URL: https://issues.jboss.org/browse/WFLY-3845
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 12.04
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Wildfly 8.1.0.Final
> Reporter: Sandeep Samdaria
> Assignee: Stuart Douglas
>
> I have two applications which need a Single Sign On. User once logged into an application should not need login again to another application.
> To achieve that I was storing the session id in the cookie. The other application used to retrieve the session and verify the user.
> Now, the problem that I am facing, after upgrading to wildfly, is that the each application is producing different jsessionid. I have also tried the workaround mentioned in https://issues.jboss.org/browse/WFLY-3617, but in vain.
> I have deployed the same wars in jboss-eap-6.2 and that worked for me.
> I have copied the two war over here https://www.dropbox.com/sh/cq5p373wasn5svj/AACyZaBMBCGaNMaBU8zbW82Za?dl=0
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months