[JBoss JIRA] (DROOLS-667) Profile why day.index is so much slower than day.getIndex()
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-667?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-667:
------------------------------------
Sorry Geoffrey, I think there's a misunderstanding.
I wrote that I cannot reproduce any relevant performance difference on my machine using the TTP not my microbenchmark.
> Profile why day.index is so much slower than day.getIndex()
> -----------------------------------------------------------
>
> Key: DROOLS-667
> URL: https://issues.jboss.org/browse/DROOLS-667
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR3
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> day.index is 3 times slower than day.getIndex() (and it's gets more as the dataset grows)
> As discussed with Mario. Rough benchmark speeds here:
> https://gist.github.com/ge0ffrey/7662856f357dbec7f7ec
> Reproduce recipe
> - git clone optaplanner
> - Run TravelingTournamentApp, load dataset bra24, solve it for about 30 seconds.
> - Open travelingTournamentScoreRules.drl. Replace all occurrences of "day.getIndex()" with "day.index".
> - Run TravelingTournamentApp again, load dataset bra24, solve it for about 30 seconds again.
> - Compare the last log message of both runs: look for average calculate count per second (x). Higher is faster. For bra24, day.getIndex() is 3 times faster than day.index.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Rafael Benevides (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Rafael Benevides commented on WFLY-4171:
----------------------------------------
I'll start this Jira Tomorrow (Friday) or Monday - I have another issue on DS to finish today before its release on weekend - and I believe that it will take one or two days to conclude it. So until the end of 23th I can have this done.
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (DROOLS-476) NPE when MVEL parses arithmetic expression
by r1 b2 (JIRA)
[ https://issues.jboss.org/browse/DROOLS-476?page=com.atlassian.jira.plugin... ]
r1 b2 commented on DROOLS-476:
------------------------------
Hi, this bug is still present, any change it gets resolved soon ?
> NPE when MVEL parses arithmetic expression
> ------------------------------------------
>
> Key: DROOLS-476
> URL: https://issues.jboss.org/browse/DROOLS-476
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Environment: sun JDK 1.6;
> Drools 5.5.0Final
> Reporter: Hassler Jean-Christian
> Assignee: Mark Proctor
> Labels: mvel, parsing
>
> When user write computations with MVEL, mvel throw the error {color:red}[Error: not a statement, or badly formed structure] {color}at parsing time.
> If you add parenthesis, parsing is OK.
> The issue can be reproduced directly with the lastest MVEL version.
> As you can see in the test below, same expression with parenthesis is OK. Debugging into mvel engine shows that there some nullPointerException in the bad case.
> This issue was reproduced with the MVEL version embedded inside Drools 5.5.0Final and also with MVEL version 2.1.9.Final.
> {code:java}
> public class MvelTest {
> public void test(){
>
> String expressionThatDoesNotWork = "5 + 1/10 * (VAR - 5)"; // !!! mvel cannot parse this expression
> String expressionThatWorks = "5 + (1/10) * (VAR - 5)"; //with additionnal parenthesis it's OK
>
> Serializable parsingResultOK = MVEL.compileExpression(expressionThatWorks); //this works seamlessly
> System.out.println(parsingResultOK); //=> (Literal<5> + (Literal<0.1> * (VAR - Literal<5>)))
>
> Serializable failedResult = MVEL.compileExpression(expressionThatDoesNotWork); // !!! this throws NullPointerException in MVEL engine
>
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4185) Using annotated servlet listeners from modules
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-4185?page=com.atlassian.jira.plugin.... ]
Pedro Igor commented on WFLY-4185:
----------------------------------
Using latest build from upstream/6.x.
> Using annotated servlet listeners from modules
> ----------------------------------------------
>
> Key: WFLY-4185
> URL: https://issues.jboss.org/browse/WFLY-4185
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
>
> PicketLink provides support for Http Security. Basically, it consists of an API to define security policies to the paths or resources of an application and a security filter (servlet filter) that is responsible to enforce those policies for every single request.
> The security filter is installed from a specific ServletContextListener (org.picketlink.http.internal.PicketLinkServletContextListener) that checks if the application has defined any security policy in order to decide if the filter must be installed or not.
> PicketLink also defines a ServletRequestListener (org.picketlink.http.internal.HttpServletRequestListener) that is used to produce a decorated HttpServletRequest instance. This decorated instance provides full integration between PL and the HttpServletRequest security methods plus some other goodies for PL users such as URL rewriting, etc.
> Both listeners (servletcontext and request) are CDI beans with injection points and/or producer methods.
> When using PL from modules, the producer method of org.picketlink.http.internal.HttpServletRequestListener#produce is not being recognized. And that makes impossible to use PL from modules.
> The same code works if you use PL jars inside the deployment.
> Another interesting behavior is that EAP and WildFly are behaving differently. In EAP (latest build), the ServletContextListener is only recognized as a CDI bean if you define it in the web.xml. While in WildFly this is not necessary.
> Also, in EAP the producer method of HttpServletRequestListener is properly recognized and everything works fine.
> I've created a branch [1] to test this issue. The test case is {code}org.wildfly.test.integration.security.picketlink.core.http.ServletListenerFromModuleTestCase{code}.
> [1] https://github.com/pedroigor/wildfly/tree/WFLY-4185
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-2518) arquillian - domain container - exception when connecting to existing domain without any servers
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2518?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2518:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1175268|https://bugzilla.redhat.com/show_bug.cgi?id=1175268] from POST to MODIFIED
> arquillian - domain container - exception when connecting to existing domain without any servers
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-2518
> URL: https://issues.jboss.org/browse/WFLY-2518
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Martin Simka
> Assignee: Martin Simka
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> {noformat}
> (E) ManagerProcessing
> (O) LoadableExtensionLoader.load
> (E) ServiceLoader
> (E) ManagerStarted
> (O) ConfigurationRegistrar.loadConfiguration
> (E) ArquillianDescriptor
> (O) ContainerRegistryCreator.createRegistry
> (E) ContainerRegistry
> (O) ProtocolRegistryCreator.createRegistry
> (E) ProtocolRegistry
> (E) BeforeSuite
> (I) TestContextHandler.createSuiteContext
> (O) ContainerEventController.execute
> (E) ContainerMultiControlEvent
> (O) ContainerLifecycleController.setupContainers
> (E) SetupContainer
> (I) ContainerDeploymentContextHandler.createContainerContext
> (O) ContainerLifecycleController.setupContainer
> (E) BeforeSetup
> (E) Container
> (E) AfterSetup
> (O) ClientContainerControllerCreator.createClientSideContainerController
> (E) ContainerController
> (O) ClientDeployerCreator.createClientSideDeployer
> (E) Deployer
> (E) ContainerMultiControlEvent
> (O) ContainerLifecycleController.startSuiteContainers
> (E) StartContainer
> (I) ContainerDeploymentContextHandler.createContainerContext
> (O) ContainerLifecycleController.startContainer
> (E) BeforeStart
> (E) ManagementClient
> (E) ArchiveDeployer
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> java.lang.IllegalArgumentException: null
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:124)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1194)
> at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:116)
> at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:126)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 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 org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 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 org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 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 org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 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 org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 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 org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 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 org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Rodney Russ (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Rodney Russ commented on WFLY-4171:
-----------------------------------
[~rafabene], do you have any idea on when this can be done? We're trying to plan for our next release and as noted above, JBDS-3275 is dependent on this.
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFCORE-254) logging-profiles doesn't work with Apache Common Logging
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-254?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFCORE-254:
------------------------------------
Yeah we definitely will have to discontinue usage of that project. Rather than fork it though, we might as well just create a direct jcl-jboss-logmanager bridge instead and cut out the middleman. It can use similar caching strategies to the slf4j-jboss-logmanager project.
> logging-profiles doesn't work with Apache Common Logging
> --------------------------------------------------------
>
> Key: WFCORE-254
> URL: https://issues.jboss.org/browse/WFCORE-254
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Anders Welen
> Assignee: James Perkins
> Priority: Minor
> Attachments: 87905.tar
>
>
> The logging for one logging-profile ends up in another logging-profile from time to time. It's not sporadic as all logging will end up in the wrong place when things go wrong.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFCORE-254) logging-profiles doesn't work with Apache Common Logging
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-254?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFCORE-254:
--------------------------------------
The issue is again with jcl-over-slf4j. At this point we might need to fork it.
jcl-over-slf4j uses a static instance and a map to find the logger. Because of this a logger with the same name will return the first logger created no matter which log context it was created on.
For a workaround you should be able exclude org.apache.commons.logging with a jboss-deployment-structure.xml and include a jcl-over-slfj4 library in each WAR deployment.
Note this issue will only appear if loggers with the same name are desired on deployments that use a new log context. For example per-deployment logging that uses commons-logging or logging-profiles that use commons-logging.
> logging-profiles doesn't work with Apache Common Logging
> --------------------------------------------------------
>
> Key: WFCORE-254
> URL: https://issues.jboss.org/browse/WFCORE-254
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Anders Welen
> Assignee: James Perkins
> Priority: Minor
> Attachments: 87905.tar
>
>
> The logging for one logging-profile ends up in another logging-profile from time to time. It's not sporadic as all logging will end up in the wrong place when things go wrong.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4185) Using annotated servlet listeners from modules
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4185?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4185:
--------------------------------------
Which version of EAP?
> Using annotated servlet listeners from modules
> ----------------------------------------------
>
> Key: WFLY-4185
> URL: https://issues.jboss.org/browse/WFLY-4185
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
>
> PicketLink provides support for Http Security. Basically, it consists of an API to define security policies to the paths or resources of an application and a security filter (servlet filter) that is responsible to enforce those policies for every single request.
> The security filter is installed from a specific ServletContextListener (org.picketlink.http.internal.PicketLinkServletContextListener) that checks if the application has defined any security policy in order to decide if the filter must be installed or not.
> PicketLink also defines a ServletRequestListener (org.picketlink.http.internal.HttpServletRequestListener) that is used to produce a decorated HttpServletRequest instance. This decorated instance provides full integration between PL and the HttpServletRequest security methods plus some other goodies for PL users such as URL rewriting, etc.
> Both listeners (servletcontext and request) are CDI beans with injection points and/or producer methods.
> When using PL from modules, the producer method of org.picketlink.http.internal.HttpServletRequestListener#produce is not being recognized. And that makes impossible to use PL from modules.
> The same code works if you use PL jars inside the deployment.
> Another interesting behavior is that EAP and WildFly are behaving differently. In EAP (latest build), the ServletContextListener is only recognized as a CDI bean if you define it in the web.xml. While in WildFly this is not necessary.
> Also, in EAP the producer method of HttpServletRequestListener is properly recognized and everything works fine.
> I've created a branch [1] to test this issue. The test case is {code}org.wildfly.test.integration.security.picketlink.core.http.ServletListenerFromModuleTestCase{code}.
> [1] https://github.com/pedroigor/wildfly/tree/WFLY-4185
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months