[JBoss JIRA] (JASSIST-244) ProxyFactory will not invoke MethodHandler on method declared in parent classes.
by Elis Edlund (JIRA)
[ https://issues.jboss.org/browse/JASSIST-244?page=com.atlassian.jira.plugi... ]
Elis Edlund updated JASSIST-244:
--------------------------------
Attachment: IssueMethodsInParentShouldCallTheMethodHandler.java
small class to reproduce the problem.
> ProxyFactory will not invoke MethodHandler on method declared in parent classes.
> --------------------------------------------------------------------------------
>
> Key: JASSIST-244
> URL: https://issues.jboss.org/browse/JASSIST-244
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA, 3.19.0-GA
> Environment: Windows 7, Java 1.7 and 1.8
> Reporter: Elis Edlund
> Assignee: Shigeru Chiba
> Attachments: IssueMethodsInParentShouldCallTheMethodHandler.java
>
>
> ProxyFactory factory = new ProxyFactory();
> factory.setSuperclass(Extended.class);
> Extended enchantedObject = (Extended) factory.create(null, null, METHOD_HANDLER);
> Does not work as intended with version newer than 3.17.0-GA
> invoking methods on the created object will go through the METHOD_HANDLER long as the method does not belong to a parent class of 'Extended'. if the method is comes from a parent class of 'Extended' the METHOD_HANDLER will not be used at all (which it was in previous versions)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JASSIST-244) ProxyFactory will not invoke MethodHandler on method declared in parent classes.
by Elis Edlund (JIRA)
Elis Edlund created JASSIST-244:
-----------------------------------
Summary: ProxyFactory will not invoke MethodHandler on method declared in parent classes.
Key: JASSIST-244
URL: https://issues.jboss.org/browse/JASSIST-244
Project: Javassist
Issue Type: Bug
Affects Versions: 3.19.0-GA, 3.18.0-GA
Environment: Windows 7, Java 1.7 and 1.8
Reporter: Elis Edlund
Assignee: Shigeru Chiba
ProxyFactory factory = new ProxyFactory();
factory.setSuperclass(Extended.class);
Extended enchantedObject = (Extended) factory.create(null, null, METHOD_HANDLER);
Does not work as intended with version newer than 3.17.0-GA
invoking methods on the created object will go through the METHOD_HANDLER long as the method does not belong to a parent class of 'Extended'. if the method is comes from a parent class of 'Extended' the METHOD_HANDLER will not be used at all (which it was in previous versions)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ELY-159) Discovery of available algorithms for credential types
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-159?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-159:
--------------------------------------
Validation API also has a similar concern, i.e. the realm should support validating the most specific type and some form of translations should be possible.
> Discovery of available algorithms for credential types
> ------------------------------------------------------
>
> Key: ELY-159
> URL: https://issues.jboss.org/browse/ELY-159
> Project: WildFly Elytron
> Issue Type: Sub-task
> Components: API / SPI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha1
>
>
> The overall purpose of the getCredentialSupport calls is so that we can discover information about the supported credentials as authentication mechanisms are offered - the algorithm for the digest is just as important as knowing the general type.
> May just be a part of ELY-151 or may be something in addition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4385) Authentication is not propagated to EJB in the login request
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4385?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-4385:
----------------------------------------
Any chance of attaching a reproducer here? The behaviour sounds wrong but at this point it could also be a problem in your own deployment.
> Authentication is not propagated to EJB in the login request
> ------------------------------------------------------------
>
> Key: WFLY-4385
> URL: https://issues.jboss.org/browse/WFLY-4385
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Environment: MAC OSX YOSEMITE
> JAVA ORACLE 1.8
> WILDFLY 8.2.0.FINAL STANDALONE
> Reporter: Paulo Cesar Silva Reis
> Assignee: Darran Lofthouse
> Labels: authentication, ejb, http, login, roles, web
>
> I'm migrating from glassfish to wildfly and noticed few weird things.
> When you perform login through web container (request.login(user, pwd)), the principal is not propagated to EJB Container, only for web container.
> To test that, this is what I did:
> . BASIC AUTH
> . EJB receives HttpServletRequest with user data and perform login
> . Print request.getUserPrincipal() => ok, logged in
> . Print EJBContext.getCallerPrincipal() => anonymous
> This happens in the same request that user logged in. In the subsequent requests (using Set-Cookie response and cookie with JSESSIONID in request), the EJB is aware of the authentication.
> Is that the right behavior? 'Cause in glassfish is different, the principal is propagated immediately to EJB.
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4385) Authentication is not propagated to EJB in the login request
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4385?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-4385:
--------------------------------------
Assignee: Darran Lofthouse
> Authentication is not propagated to EJB in the login request
> ------------------------------------------------------------
>
> Key: WFLY-4385
> URL: https://issues.jboss.org/browse/WFLY-4385
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Environment: MAC OSX YOSEMITE
> JAVA ORACLE 1.8
> WILDFLY 8.2.0.FINAL STANDALONE
> Reporter: Paulo Cesar Silva Reis
> Assignee: Darran Lofthouse
> Labels: authentication, ejb, http, login, roles, web
>
> I'm migrating from glassfish to wildfly and noticed few weird things.
> When you perform login through web container (request.login(user, pwd)), the principal is not propagated to EJB Container, only for web container.
> To test that, this is what I did:
> . BASIC AUTH
> . EJB receives HttpServletRequest with user data and perform login
> . Print request.getUserPrincipal() => ok, logged in
> . Print EJBContext.getCallerPrincipal() => anonymous
> This happens in the same request that user logged in. In the subsequent requests (using Set-Cookie response and cookie with JSESSIONID in request), the EJB is aware of the authentication.
> Is that the right behavior? 'Cause in glassfish is different, the principal is propagated immediately to EJB.
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-3839) EjbClient: No cluster node manager found for node XY during server restart
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-3839?page=com.atlassian.jira.plugin.... ]
Tomas Hofman reassigned WFLY-3839:
----------------------------------
Assignee: Tomas Hofman (was: Richard Achmatowicz)
> EjbClient: No cluster node manager found for node XY during server restart
> ---------------------------------------------------------------------------
>
> Key: WFLY-3839
> URL: https://issues.jboss.org/browse/WFLY-3839
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 8.1.0.Final
> Reporter: Dominik Pospisil
> Assignee: Tomas Hofman
>
> Situation: 4-node cluster, one node is failed at a time, during the whole test, clients are accessing stateless clustered EJB3. The failure type in this particular case is simulating server crash: JVM is killed using kill -9.
> When the server was starting, being brought back, we saw this error:
> 16:05:29,966 ERROR [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-2-thread-17) Cannot create EJBReceiver since no cluster node manager found for node perf20 in cluster context for cluster ejb
> Here is the log output again with context, the server was starting:
> {noformat}
> 16:05:29,966 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> 16:05:29,966 ERROR [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-2-thread-17) Cannot create EJBReceiver since no cluster node manager found for node perf20 in cluster context for cluster ejb
> 16:05:29,974 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> 16:05:29,974 ERROR [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-2-thread-18) Cannot create EJBReceiver since no cluster node manager found for node perf20 in cluster context for cluster ejb
> 16:05:29,975 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> 16:05:29,975 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> {noformat}
> During the whole test, there were 4 server crashes and startups (1 for each node), but only 3 occurences of the above mentioned error. These cluster nodes are perf18, perf19, perf20, perf21, but this error was seen only for perf20 (two occurences) and perf18 (one occurence).
> I did not find anything suspicious in the server.log of perf20.
> Cache: REPL_ASYNC
> Versions: EAP 6.1.0.ER6, ejb-client 1.0.19.Final
> Link to hudson job:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-ejb-...
> Server log:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-ejb-...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4385) Authentication is not propagated to EJB in the login request
by Paulo Cesar Silva Reis (JIRA)
Paulo Cesar Silva Reis created WFLY-4385:
--------------------------------------------
Summary: Authentication is not propagated to EJB in the login request
Key: WFLY-4385
URL: https://issues.jboss.org/browse/WFLY-4385
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 8.2.0.Final
Environment: MAC OSX YOSEMITE
JAVA ORACLE 1.8
WILDFLY 8.2.0.FINAL STANDALONE
Reporter: Paulo Cesar Silva Reis
I'm migrating from glassfish to wildfly and noticed few weird things.
When you perform login through web container (request.login(user, pwd)), the principal is not propagated to EJB Container, only for web container.
To test that, this is what I did:
. BASIC AUTH
. EJB receives HttpServletRequest with user data and perform login
. Print request.getUserPrincipal() => ok, logged in
. Print EJBContext.getCallerPrincipal() => anonymous
This happens in the same request that user logged in. In the subsequent requests (using Set-Cookie response and cookie with JSESSIONID in request), the EJB is aware of the authentication.
Is that the right behavior? 'Cause in glassfish is different, the principal is propagated immediately to EJB.
Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ELY-159) Discovery of available algorithms for credential types
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-159?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-159:
--------------------------------------
Along similar lines as the original description here the realm needs to have access to some form of transformation utility for handling the transformation from one credential type + algorithm to another - i.e. the realm implementations should be able to be implemented with the bare minimum number of credential types supported - generally realms should only need to know about the types they use for storage.
As an example if a realm supports ClearPassword storage and retrieval the realm implementation should not now have the overhead of being able to convert to all credential types and it should also not have the overhead of having to be able to understand what can be translated to what. At the same time where we can a mechanism implementation should just be using it's most specific password type implementation and all this translation then happens at one central place.
> Discovery of available algorithms for credential types
> ------------------------------------------------------
>
> Key: ELY-159
> URL: https://issues.jboss.org/browse/ELY-159
> Project: WildFly Elytron
> Issue Type: Sub-task
> Components: API / SPI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha1
>
>
> The overall purpose of the getCredentialSupport calls is so that we can discover information about the supported credentials as authentication mechanisms are offered - the algorithm for the digest is just as important as knowing the general type.
> May just be a part of ELY-151 or may be something in addition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBJCA-1005) SemaphoreArrayListManagedConnectionPool should FIFO
by None None (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1005?page=com.atlassian.jira.plugin... ]
None None commented on JBJCA-1005:
----------------------------------
Hi,
could someone explain to me why this change has been made, please? I see a major problem with this because idle connections are hardly closed.
We updated from JBoss 4 to Wildfly 8.2. JBoss 4 had a LIFO strategy and Wildfly has a FIFO strategy now. Our db pool size is configured to work well with a high server load. On low to medium load only a small amount of db connections are needed. Unfortunately db pool connections are now used in a round robin manner. This means that very few connections can be closed due to reaching the idle time limit because they are used regularly.
Is there a way to get back the old behavior? Are there any different connection pool managers that utilize a LIFO strategy?
> SemaphoreArrayListManagedConnectionPool should FIFO
> ---------------------------------------------------
>
> Key: JBJCA-1005
> URL: https://issues.jboss.org/browse/JBJCA-1005
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.15.Final, 1.1.0.Beta4
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Priority: Critical
> Fix For: 1.0.16.Final, 1.1.0.Beta5
>
>
> Currently behaving in FILO manner
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4376) Incorrect callback handler used during authentication (SASL)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4376?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4376:
-----------------------------------------------
Tomas Hofman <thofman(a)redhat.com> changed the Status of [bug 996897|https://bugzilla.redhat.com/show_bug.cgi?id=996897] from ASSIGNED to NEW
> Incorrect callback handler used during authentication (SASL)
> -------------------------------------------------------------
>
> Key: WFLY-4376
> URL: https://issues.jboss.org/browse/WFLY-4376
> Project: WildFly
> Issue Type: Bug
> Reporter: Enrique González Martínez
> Assignee: Enrique González Martínez
>
> Cluster topology messages are not using the proper callbackhandler when the connection is being established.
> {code}
> 06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> 06:59:44,611 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87)
> ... 7 more
> {code}
> Before that, this log is produced:
> {code}
> DEBUG: Client authentication failed for mechanism DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months