[JBoss JIRA] (WFLY-3438) Eliminate use of optional dependencies for LocalEJBReceiver
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3438?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated WFLY-3438:
--------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/6334
> Eliminate use of optional dependencies for LocalEJBReceiver
> -----------------------------------------------------------
>
> Key: WFLY-3438
> URL: https://issues.jboss.org/browse/WFLY-3438
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final, 9.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 9.0.0.CR1
>
>
> This issue was initially raised on stackoverflow (see below).
> When the EJB subsystem starts, it starts instances of LocalEJBReceiver which have optional dependencies on the Remoting Endpoint as well as the EJBRemoteConnectorService. I assume that these were marked as optional as remote invocations on EJBs is not required by the spec for the web profile.
> As stated in the forum post, the issue is that the LocalEJBReceiver gets started before its dependency EJBRemoteConnectorService and so the optional dependency does not get resolved correctly - effectively turning off the LocalEJBReceiver's ability to add cluster nodes to cluster contexts for the clusters it belongs to.
> This results in the exception
> .java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
> The solution described in the forum post works to ensure that the dependencies are established correctly, but we need to factor into this what the spec says about the web profile and the possibility that some components (e.g. the EJBRemoteConnector) may be optionally removed.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3438) Eliminate use of optional dependencies for LocalEJBReceiver
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3438?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-3438 at 6/3/14 6:34 PM:
-------------------------------------------------------------------
I've reviewed this approach and have decided to assume that the Remoting Endpoint (the so-called SYSTEM_ENDPOINT which is started up as part of the Remoting subsystem initialization) will always be present. Remoting is so fundamental, its hard to imagine the Remoting subsystem not being started in a configuration.
So the solution will be to check for the existence of the EJBRemoteConnectorService, represented by the element:
{noformat}
<subsystem xmlns="urn:jboss:domain:ejb3:2.0">
...
<remote connector-ref="..." thread-pool-name="..."/>
...
</subsystem>
{noformat}
and if it is present in the model, add in the two REQUIRED dependencies above; otherwise don't include them.
This setup would allow a sysadmin to disable the remote connector and so effectively "turn off" remote invovations on EJBs on the node in question..
was (Author: rachmato):
I've reviewed this approach and have decided to assume that the Remoting Endpoint (the so-called SYSTEM_ENDPOINT which is started up as part of the Remoting subsystem initialization) will always be present. Remoting is so fundamental, its hard to imagine the Remoting subsystem not being started in a configuration.
So the solution will be to check for the existence of the EJBRemoteConnectorService, represented by the element:
{noformat}
<subsystem xmlns="urn:jboss:domain:ejb3:2.0">
...
<remote connector-ref="..." thread-pool-name="..."/>
...
</subsystem>
{noformat}
and if it is present in the model, add in the two REQUIRED dependencies above; otherwise don't include them.
> Eliminate use of optional dependencies for LocalEJBReceiver
> -----------------------------------------------------------
>
> Key: WFLY-3438
> URL: https://issues.jboss.org/browse/WFLY-3438
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final, 9.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 9.0.0.CR1
>
>
> This issue was initially raised on stackoverflow (see below).
> When the EJB subsystem starts, it starts instances of LocalEJBReceiver which have optional dependencies on the Remoting Endpoint as well as the EJBRemoteConnectorService. I assume that these were marked as optional as remote invocations on EJBs is not required by the spec for the web profile.
> As stated in the forum post, the issue is that the LocalEJBReceiver gets started before its dependency EJBRemoteConnectorService and so the optional dependency does not get resolved correctly - effectively turning off the LocalEJBReceiver's ability to add cluster nodes to cluster contexts for the clusters it belongs to.
> This results in the exception
> .java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
> The solution described in the forum post works to ensure that the dependencies are established correctly, but we need to factor into this what the spec says about the web profile and the possibility that some components (e.g. the EJBRemoteConnector) may be optionally removed.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3438) Eliminate use of optional dependencies for LocalEJBReceiver
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3438?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-3438:
-------------------------------------------
I've reviewed this approach and have decided to assume that the Remoting Endpoint (the so-called SYSTEM_ENDPOINT which is started up as part of the Remoting subsystem initialization) will always be present. Remoting is so fundamental, its hard to imagine the Remoting subsystem not being started in a configuration.
So the solution will be to check for the existence of the EJBRemoteConnectorService, represented by the element:
{noformat}
<subsystem xmlns="urn:jboss:domain:ejb3:2.0">
...
<remote connector-ref="..." thread-pool-name="..."/>
...
</subsystem>
{noformat}
and if it is present in the model, add in the two REQUIRED dependencies above; otherwise don't include them.
> Eliminate use of optional dependencies for LocalEJBReceiver
> -----------------------------------------------------------
>
> Key: WFLY-3438
> URL: https://issues.jboss.org/browse/WFLY-3438
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final, 9.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 9.0.0.CR1
>
>
> This issue was initially raised on stackoverflow (see below).
> When the EJB subsystem starts, it starts instances of LocalEJBReceiver which have optional dependencies on the Remoting Endpoint as well as the EJBRemoteConnectorService. I assume that these were marked as optional as remote invocations on EJBs is not required by the spec for the web profile.
> As stated in the forum post, the issue is that the LocalEJBReceiver gets started before its dependency EJBRemoteConnectorService and so the optional dependency does not get resolved correctly - effectively turning off the LocalEJBReceiver's ability to add cluster nodes to cluster contexts for the clusters it belongs to.
> This results in the exception
> .java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
> The solution described in the forum post works to ensure that the dependencies are established correctly, but we need to factor into this what the spec says about the web profile and the possibility that some components (e.g. the EJBRemoteConnector) may be optionally removed.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3438) Eliminate use of optional dependencies for LocalEJBReceiver
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3438?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-3438 at 6/3/14 6:22 PM:
-------------------------------------------------------------------
If the Remoting Endpoint and the EJBRemoteConnectorService are indeed optional, and may be excluded from the server profile, a better way to handle this would be to check the state of the models for the Remoting and EJB subsystems at start up, see if the elements are present, and if they are both present, add them in as REQUIRED dependencies; otherwise leave them out. Also, if one of them is added in via the management interface, set the handler to force a reload so the check at start up may be performed anew.
The use cases where both are left out could correspond to a single node accepting HTTP based servlet requests which accessed a local stateful session bean or a cluster of such nodes.
was (Author: rachmato):
If the Remoting Endpoint and the EJBRemotingConnectorService are indeed optional, and may be excluded from the server profile, a better way to handle this would be to check the state of the models for the Remoting and EJB subsystems at start up, see if the elements are present, and if they are both present, add them in as REQUIRED dependencies; otherwise leave them out. Also, if one of them is added in via the management interface, set the handler to force a reload so the check at start up may be performed anew.
The use cases where both are left out could correspond to a single node accepting HTTP based servlet requests which accessed a local stateful session bean or a cluster of such nodes.
> Eliminate use of optional dependencies for LocalEJBReceiver
> -----------------------------------------------------------
>
> Key: WFLY-3438
> URL: https://issues.jboss.org/browse/WFLY-3438
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final, 9.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 9.0.0.CR1
>
>
> This issue was initially raised on stackoverflow (see below).
> When the EJB subsystem starts, it starts instances of LocalEJBReceiver which have optional dependencies on the Remoting Endpoint as well as the EJBRemoteConnectorService. I assume that these were marked as optional as remote invocations on EJBs is not required by the spec for the web profile.
> As stated in the forum post, the issue is that the LocalEJBReceiver gets started before its dependency EJBRemoteConnectorService and so the optional dependency does not get resolved correctly - effectively turning off the LocalEJBReceiver's ability to add cluster nodes to cluster contexts for the clusters it belongs to.
> This results in the exception
> .java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
> The solution described in the forum post works to ensure that the dependencies are established correctly, but we need to factor into this what the spec says about the web profile and the possibility that some components (e.g. the EJBRemoteConnector) may be optionally removed.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3438) Eliminate use of optional dependencies for LocalEJBReceiver
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3438?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated WFLY-3438:
--------------------------------------
Description:
This issue was initially raised on stackoverflow (see below).
When the EJB subsystem starts, it starts instances of LocalEJBReceiver which have optional dependencies on the Remoting Endpoint as well as the EJBRemoteConnectorService. I assume that these were marked as optional as remote invocations on EJBs is not required by the spec for the web profile.
As stated in the forum post, the issue is that the LocalEJBReceiver gets started before its dependency EJBRemoteConnectorService and so the optional dependency does not get resolved correctly - effectively turning off the LocalEJBReceiver's ability to add cluster nodes to cluster contexts for the clusters it belongs to.
This results in the exception
.java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
The solution described in the forum post works to ensure that the dependencies are established correctly, but we need to factor into this what the spec says about the web profile and the possibility that some components (e.g. the EJBRemoteConnector) may be optionally removed.
was:
This issue was initially raised on stackoverflow (see below).
When the EJB subsystem starts, it starts instances of LocalEJBReceiver which have optional dependencies on the Remoting Endpoint as well as the EJBRemotingConnectorService. I assume that these were marked as optional as remote invocations on EJBs is not required by the spec for the web profile.
As stated in the forum post, the issue is that the LocalEJBReceiver gets started before its dependency EJBRemotingConnectorService and so the dependency does not get resolved correctly - this effectively turns off the LocalEJBReceiver's ability to add cluster nodes to cluster contexts for the clusters it belongs to.
This results in the exception
.java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
The solution described in the forum post works to ensure that the dependencies are established correctly, but we need to factor into this what the spec says about the web profile.
> Eliminate use of optional dependencies for LocalEJBReceiver
> -----------------------------------------------------------
>
> Key: WFLY-3438
> URL: https://issues.jboss.org/browse/WFLY-3438
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final, 9.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 9.0.0.CR1
>
>
> This issue was initially raised on stackoverflow (see below).
> When the EJB subsystem starts, it starts instances of LocalEJBReceiver which have optional dependencies on the Remoting Endpoint as well as the EJBRemoteConnectorService. I assume that these were marked as optional as remote invocations on EJBs is not required by the spec for the web profile.
> As stated in the forum post, the issue is that the LocalEJBReceiver gets started before its dependency EJBRemoteConnectorService and so the optional dependency does not get resolved correctly - effectively turning off the LocalEJBReceiver's ability to add cluster nodes to cluster contexts for the clusters it belongs to.
> This results in the exception
> .java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
> The solution described in the forum post works to ensure that the dependencies are established correctly, but we need to factor into this what the spec says about the web profile and the possibility that some components (e.g. the EJBRemoteConnector) may be optionally removed.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3445) Allow custom protocol types in jgroups stack
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3445?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3445:
-------------------------------
Description:
Currently, protocols must reside within the org.jgroups.protocols package or a within a subpackage.
I should be able to define a protocol as:
<protocol type="org.foo.MyProtocol" module="my.module"/>
The module attribute should indicate the module in which to locate the protocol class and should default to "org.jgroups".
was:
I should be able to define a protocol as:
<protocol type="org.foo.MyProtocol" module="my.module"/>
The module attribute should indicate the module in which to locate the protocol class and should default to "org.jgroups".
> Allow custom protocol types in jgroups stack
> --------------------------------------------
>
> Key: WFLY-3445
> URL: https://issues.jboss.org/browse/WFLY-3445
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Alpha1
>
>
> Currently, protocols must reside within the org.jgroups.protocols package or a within a subpackage.
> I should be able to define a protocol as:
> <protocol type="org.foo.MyProtocol" module="my.module"/>
> The module attribute should indicate the module in which to locate the protocol class and should default to "org.jgroups".
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3445) Allow custom protocol types in jgroups stack
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3445?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3445:
-------------------------------
Description:
I should be able to define a protocol as:
<protocol type="org.foo.MyProtocol" module="my.module"/>
The module attribute should indicate the module in which to locate the protocol class and should default to "org.jgroups".
> Allow custom protocol types in jgroups stack
> --------------------------------------------
>
> Key: WFLY-3445
> URL: https://issues.jboss.org/browse/WFLY-3445
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Alpha1
>
>
> I should be able to define a protocol as:
> <protocol type="org.foo.MyProtocol" module="my.module"/>
> The module attribute should indicate the module in which to locate the protocol class and should default to "org.jgroups".
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3444) EjbTimerXmlPersister should check if timer.getNextExpiration() is null to avoid NPE
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3444?page=com.atlassian.jira.plugin.... ]
Scott Marlow reassigned WFLY-3444:
----------------------------------
Assignee: David Lloyd (was: Scott Marlow)
> EjbTimerXmlPersister should check if timer.getNextExpiration() is null to avoid NPE
> -----------------------------------------------------------------------------------
>
> Key: WFLY-3444
> URL: https://issues.jboss.org/browse/WFLY-3444
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Scott Marlow
> Assignee: David Lloyd
> Fix For: 9.0.0.Alpha1
>
>
> Seeing a NPE in org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister. that probably needs a null check:
> {quote}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeCalendarTimer(EjbTimerXmlPersister.java:136)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeContent(EjbTimerXmlPersister.java:89)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeContent(EjbTimerXmlPersister.java:43)
> at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88)
> at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.writeFile(FileTimerPersistence.java:440)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3444) EjbTimerXmlPersister should check if timer.getNextExpiration() is null to avoid NPE
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3444?page=com.atlassian.jira.plugin.... ]
Scott Marlow reassigned WFLY-3444:
----------------------------------
Assignee: Scott Marlow (was: David Lloyd)
> EjbTimerXmlPersister should check if timer.getNextExpiration() is null to avoid NPE
> -----------------------------------------------------------------------------------
>
> Key: WFLY-3444
> URL: https://issues.jboss.org/browse/WFLY-3444
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 9.0.0.Alpha1
>
>
> Seeing a NPE in org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister. that probably needs a null check:
> {quote}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeCalendarTimer(EjbTimerXmlPersister.java:136)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeContent(EjbTimerXmlPersister.java:89)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeContent(EjbTimerXmlPersister.java:43)
> at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88)
> at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.writeFile(FileTimerPersistence.java:440)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month