[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 edited comment on JASSIST-244 at 2/25/15 8:23 AM:
--------------------------------------------------------------
Noticed that the access scope of the Base class matters.
If its changed to public it will actually work. but private and "package private" and protected it does not still.
Anyhow I'm in a position were I can't change the Base class anyway so it's not a workaround for me.
was (Author: elis.edlund):
Noticed that the access scope of the Base class matters.
If its changed to public it will actually work. but private and "package private" and protected it does not still.
Anyhow I'm in a position were I can't change the class anyway so it's not a workaround for me.
> 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)
8 years
[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 commented on JASSIST-244:
-------------------------------------
Noticed that the access scope of the Base class matters.
If its changed to public it will actually work. but private and "package private" and protected it does not still.
Anyhow I'm in a position where I can't change the class so its not a workaround for me.
> 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)
8 years
[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 edited comment on JASSIST-244 at 2/25/15 8:22 AM:
--------------------------------------------------------------
Noticed that the access scope of the Base class matters.
If its changed to public it will actually work. but private and "package private" and protected it does not still.
Anyhow I'm in a position were I can't change the class anyway so it's not a workaround for me.
was (Author: elis.edlund):
Noticed that the access scope of the Base class matters.
If its changed to public it will actually work. but private and "package private" and protected it does not still.
Anyhow I'm in a position where I can't change the class so its not a workaround for me.
> 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)
8 years
[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)
8 years
[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)
8 years
[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)
8 years
[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)
8 years
[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)
8 years
[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)
8 years