[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)
10 years
[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)
10 years
[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)
10 years
[JBoss JIRA] (DROOLS-667) Profile why day.index is so much slower than day.getIndex()
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-667?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-667:
-----------------------------------------
I think the difference is because of stateful or stateless. In TTP, it's used in a statefull context, with thousands of fireAllRules() calls on 1 KieBase. In the microbenchmark I saw earlier, it's used in just 1 fireAllRules().
> 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)
10 years
[JBoss JIRA] (WFLY-2509) Method invocation of a non serializable remote EJB
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-2509?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski closed WFLY-2509.
--------------------------------
> Method invocation of a non serializable remote EJB
> ---------------------------------------------------
>
> Key: WFLY-2509
> URL: https://issues.jboss.org/browse/WFLY-2509
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: omar al kababji
> Assignee: Tomasz Adamski
> Priority: Optional
>
> If you have a remote EJB that is not Serializable (i.e. does not implement the interface Serializable) you can lookup such class from a remote EJB client however when you execute a method you get an error as follows:
> java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling
> The enhancement is to give an error or warning message when the EJB is deployed notifying the developer that he is deploying a Remote EJB that is not implementing the Serializable interface.
> The same thing happens if you deploy an EJB marked with the annotation @Remote but with no @Stateless nor @Statefull annotations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-2509) Method invocation of a non serializable remote EJB
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-2509?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski resolved WFLY-2509.
----------------------------------
Resolution: Rejected
> Method invocation of a non serializable remote EJB
> ---------------------------------------------------
>
> Key: WFLY-2509
> URL: https://issues.jboss.org/browse/WFLY-2509
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: omar al kababji
> Assignee: Tomasz Adamski
> Priority: Optional
>
> If you have a remote EJB that is not Serializable (i.e. does not implement the interface Serializable) you can lookup such class from a remote EJB client however when you execute a method you get an error as follows:
> java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling
> The enhancement is to give an error or warning message when the EJB is deployed notifying the developer that he is deploying a Remote EJB that is not implementing the Serializable interface.
> The same thing happens if you deploy an EJB marked with the annotation @Remote but with no @Stateless nor @Statefull annotations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-2509) Method invocation of a non serializable remote EJB
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2509?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2509:
--------------------------------------
There is no requirement that EJB's or their remotes implement serialisable (I don't think any of the remote EJB's in our test suite do).
If you are having trouble with remote EJB invocation please ask in the forums first with more details.
> Method invocation of a non serializable remote EJB
> ---------------------------------------------------
>
> Key: WFLY-2509
> URL: https://issues.jboss.org/browse/WFLY-2509
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: omar al kababji
> Assignee: Tomasz Adamski
> Priority: Optional
>
> If you have a remote EJB that is not Serializable (i.e. does not implement the interface Serializable) you can lookup such class from a remote EJB client however when you execute a method you get an error as follows:
> java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling
> The enhancement is to give an error or warning message when the EJB is deployed notifying the developer that he is deploying a Remote EJB that is not implementing the Serializable interface.
> The same thing happens if you deploy an EJB marked with the annotation @Remote but with no @Stateless nor @Statefull annotations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4188) Client Mapping expressions are allowed but are not resolved if used
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4188?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-4188:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1175442
> Client Mapping expressions are allowed but are not resolved if used
> -------------------------------------------------------------------
>
> Key: WFLY-4188
> URL: https://issues.jboss.org/browse/WFLY-4188
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, ConfigAdmin
> Affects Versions: 8.2.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
>
> If socket binding with client-mapping is used to provide a valid client address for EJB invocation to the client the expressions are not resolved.
> Depend on the attribute the parsing failed direct during startup (port# is not numeric) or the expression is send to the client where the Exception is thrown at runtime.
> Notice for EJB invocation the problem is only visible if the application is clustered, otherwise the cluster view (where the client-mapping take effect) is not send to the client.
> Dec 17, 2014 2:53:43 PM org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager getEJBReceiver
> INFO: Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='redhat', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='${jboss.node.name}', destinationPort=8080}], resolvedDestination=[Destination address=${jboss.node.name}, destination port=8080]} in cluster ejb
> java.lang.RuntimeException: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 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)
> Caused by: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:102)
> at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 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)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
> ... 8 more
> Caused by: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
> at java.net.URI$Parser.fail(URI.java:2829)
> at java.net.URI$Parser.parseAuthority(URI.java:3167)
> at java.net.URI$Parser.parseHierarchical(URI.java:3078)
> at java.net.URI$Parser.parse(URI.java:3034)
> at java.net.URI.<init>(URI.java:680)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:100)
> at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
> ... 12 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4188) Client Mapping expressions are allowed but are not resolved if used
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-4188:
--------------------------------------
Summary: Client Mapping expressions are allowed but are not resolved if used
Key: WFLY-4188
URL: https://issues.jboss.org/browse/WFLY-4188
Project: WildFly
Issue Type: Bug
Components: Clustering, ConfigAdmin
Affects Versions: 8.2.0.Final
Reporter: Wolf-Dieter Fink
Assignee: Paul Ferraro
If socket binding with client-mapping is used to provide a valid client address for EJB invocation to the client the expressions are not resolved.
Depend on the attribute the parsing failed direct during startup (port# is not numeric) or the expression is send to the client where the Exception is thrown at runtime.
Notice for EJB invocation the problem is only visible if the application is clustered, otherwise the cluster view (where the client-mapping take effect) is not send to the client.
Dec 17, 2014 2:53:43 PM org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager getEJBReceiver
INFO: Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='redhat', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='${jboss.node.name}', destinationPort=8080}], resolvedDestination=[Destination address=${jboss.node.name}, destination port=8080]} in cluster ejb
java.lang.RuntimeException: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77)
at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405)
at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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)
Caused by: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:102)
at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405)
at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
... 8 more
Caused by: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.parseAuthority(URI.java:3167)
at java.net.URI$Parser.parseHierarchical(URI.java:3078)
at java.net.URI$Parser.parse(URI.java:3034)
at java.net.URI.<init>(URI.java:680)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:100)
at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
... 12 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years