4:52 p.m.
Folks,
starting from Jim's testcase for complex examples of EJB3 WS endpoints
deployments into WAR archives, here are some points to start discussion:
* DeploymentType vs EndpointType
Generally speaking, JSR109 v.1.3 allowing EJB3 WS endpoints into WAR
archives makes the design assumption behind
org.jboss.wsf.spi.deployment.Deployment.DeploymentType not valid
anymore. It's not possible to establish a deployment is either JAXWS_JSE
or JAXWS_EJB3, as it can have both pojo and ejb3 endpoints at the same
time. So while it still makes sense and is useful knowing a deployment
is from a WAR or JAR archive, the JSE vs EJB3 piece of information is
something related to each endpoint. So I propose we modify that
DeploymentType to have something like JAXWS_WAR and JAXWS_JAR and add a
new EndpointType enum in org.jboss.wsf.spi.deployment.Endpoint for JSE
and EJB3 endpoint types.
As a consequence, we'll need multiple fixes:
- ContainerMetaDataDeploymentAspect: the endpoint type needs to be
considered for properly attaching metadata
- EndpointHandlerDeploymentAspect: the endpoint type is to be used for
deciding which invocation handler to set in each endpoint
- EndpointAddressDeploymentAspect: this also needs to consider the
endpoint type for figuring out if a confidential/secure transport
address is required
- WebMetaDataCreatingDeploymentAspect: not sure, but this might also
require some tuning / fix
- ServletHelper: the current hook in place for calling the
InjectionHelper needs to consider the endpoint type
* Computation of context-root
[1] has the current algorithm. For the "mixed" situation where an EJB3
WS endpoint lives into a WAR deployment (with or without other POJO
endpoints), I assume we should have a different implicit context-root
(point 5 in [1]), being the same has the context-root for the webapp
associated to the WAR archive. So both POJO and EJB3 endpoints share the
context-root of the war.
* Where to look at descriptors (wsdl, xsd, jbossws-cxf.xml, ...)
Here I would say we first look at eventual requirements from the specs I
might forgetting here, otherwise the type of the archive drives the
position (i.e. WEB-INF/... for war archives, even if the endpoint is an
EJB3 one)
What do you think?
Jim, once everything is clear here, can you work on this?
Cheers
Alessio
[1]
http://community.jboss.org/wiki/JBossWS-FAQ#How_do_I_know_what_endpoint_a...
--
Alessio Soldano
Web Service Lead, JBoss
7:23 a.m.
Comments inlined:
Rio
On 08/29/2011 04:52 PM, Alessio Soldano wrote:
Folks,
starting from Jim's testcase for complex examples of EJB3 WS endpoints
deployments into WAR archives, here are some points to start discussion:
* DeploymentType vs EndpointType
Generally speaking, JSR109 v.1.3 allowing EJB3 WS endpoints into WAR
archives makes the design assumption behind
org.jboss.wsf.spi.deployment.Deployment.DeploymentType not valid
anymore. It's not possible to establish a deployment is either JAXWS_JSE
or JAXWS_EJB3, as it can have both pojo and ejb3 endpoints at the same
time. So while it still makes sense and is useful knowing a deployment
is from a WAR or JAR archive, the JSE vs EJB3 piece of information is
something related to each endpoint. So I propose we modify that
DeploymentType to have something like JAXWS_WAR and JAXWS_JAR and add a
new EndpointType enum in org.jboss.wsf.spi.deployment.Endpoint for JSE
and EJB3 endpoint types.
IIRC you Alessio said few days ago that users can mix both
JAXWS &
JAXRPC endpoints in one deployment.
Considering this information DeploymentType abstraction doesn't make
sense at all.
I'd say we won't have DeploymentType abstraction anymore.
We will just have EndpointType abstraction with the following values:
* JAXWS_POJO
* JAXWS_EJB3
* JAXRPC_POJO
* JAXRPC_EJB21
As a consequence, we'll need multiple fixes:
- ContainerMetaDataDeploymentAspect: the endpoint type needs to be
considered for properly attaching metadata
+1
- EndpointHandlerDeploymentAspect: the endpoint type is to be used
for
deciding which invocation handler to set in each endpoint
+1
- EndpointAddressDeploymentAspect: this also needs to consider the
endpoint type for figuring out if a confidential/secure transport
address is required
+1
- WebMetaDataCreatingDeploymentAspect: not sure, but this might also
require some tuning / fix
- ServletHelper: the current hook in place for calling the
InjectionHelper needs to consider the endpoint type
* Computation of context-root
[1] has the current algorithm. For the "mixed" situation where an EJB3
WS endpoint lives into a WAR deployment (with or without other POJO
endpoints), I assume we should have a different implicit context-root
(point 5 in [1]), being the same has the context-root for the webapp
associated to the WAR archive. So both POJO and EJB3 endpoints share the
context-root of the war.
* Where to look at descriptors (wsdl, xsd, jbossws-cxf.xml, ...)
Here I would say we first look at eventual requirements from the specs I
might forgetting here, otherwise the type of the archive drives the
position (i.e. WEB-INF/... for war archives, even if the endpoint is an
EJB3 one)
IMO both JSEArchiveMetaData & EJBArchiveMetaData will need to split
too.
They contain some information that are endpoint specific.
For example it should be possible to define context root per EJB endpoint
in same deployment. This is what TCK6 does and we're working it around
with some DD customization hacks. Probably as prove of concept we should
allow support for @WebContext on POJOs as well?
What do you think?
Jim, once everything is clear here, can you work on this?
Cheers
Alessio
[1]
http://community.jboss.org/wiki/JBossWS-FAQ#How_do_I_know_what_endpoint_a...
--
Richard Opalka
ropalka(a)redhat.com
JBoss, by Red Hat
Mobile: +420 731 186 942
11:01 a.m.
On 08/30/2011 07:23 AM, Richard Opalka wrote:
> * DeploymentType vs EndpointType
> [...]
IIRC you Alessio said few days ago that users can mix both JAXWS &
JAXRPC endpoints in one deployment.
Considering this information DeploymentType abstraction doesn't make
sense at all.
I'd say we won't have DeploymentType abstraction anymore.
We will just have EndpointType abstraction with the following values:
* JAXWS_POJO
* JAXWS_EJB3
* JAXRPC_POJO
* JAXRPC_EJB21
The jaxrpc side of the issue is still to analysed, anyway, I see your
point, we can simply derive the DeploymentType info (JAR or WAR) from
the new EndpointType, so the former can simply be removed.
> * Computation of context-root
> [1] has the current algorithm. For the "mixed" situation where an EJB3
> WS endpoint lives into a WAR deployment (with or without other POJO
> endpoints), I assume we should have a different implicit context-root
> (point 5 in [1]), being the same has the context-root for the webapp
> associated to the WAR archive. So both POJO and EJB3 endpoints share the
> context-root of the war.
>
> * Where to look at descriptors (wsdl, xsd, jbossws-cxf.xml, ...)
> Here I would say we first look at eventual requirements from the specs I
> might forgetting here, otherwise the type of the archive drives the
> position (i.e. WEB-INF/... for war archives, even if the endpoint is an
> EJB3 one)
IMO both JSEArchiveMetaData & EJBArchiveMetaData will need to split too.
They contain some information that are endpoint specific.
For example it should be possible to define context root per EJB endpoint
in same deployment. This is what TCK6 does and we're working it around
with some DD customization hacks. Probably as prove of concept we should
allow support for @WebContext on POJOs as well?
Yes, I now remember those tck tests. Here is my proposal on this topic:
- start by moving the contextRoot info from the Service to the Endpoint
in jbossws-spi to prepare the way
- defer the rest of the changes to another effort so for instance keep
the JSEArchiveMetaData and EJBArchiveMetaData as they currently are for now
In the next future we'll work on allowing different context-root for
endpoints in the same webapp: that also implies deep changes in the
container integration, as most probably multiple webapps need to be
started to be able to publish endpoints in different context-roots and I
can foresee multiple issues with that (classloading just to say one).
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
4:46 a.m.
My email filter moved this to a wrong folder and I missed this
discussion yesterday.
Please see me comments inline.
On 08/30/2011 05:01 PM, Alessio Soldano wrote:
On 08/30/2011 07:23 AM, Richard Opalka wrote:
>> * DeploymentType vs EndpointType
>> [...]
> IIRC you Alessio said few days ago that users can mix both JAXWS&
> JAXRPC endpoints in one deployment.
> Considering this information DeploymentType abstraction doesn't make
> sense at all.
> I'd say we won't have DeploymentType abstraction anymore.
> We will just have EndpointType abstraction with the following values:
> * JAXWS_POJO
> * JAXWS_EJB3
> * JAXRPC_POJO
> * JAXRPC_EJB21
The jaxrpc side of the issue is still to analysed, anyway, I see your
point, we can simply derive the DeploymentType info (JAR or WAR) from
the new EndpointType, so the former can simply be removed.
But we still need let
each endpoint easily know its
deploymentType(war,ear or jar) information and other
deployment context information(WarMetaData, EARMetaData or we wrapped
JSEArchiveMeteData, EJB EJBArchiveMetaData).
Then we can decide the address and context root when the ws endpoint is
actually published.
>> * Computation of context-root
>> [1] has the current algorithm. For the "mixed" situation where an EJB3
>> WS endpoint lives into a WAR deployment (with or without other POJO
>> endpoints), I assume we should have a different implicit context-root
>> (point 5 in [1]), being the same has the context-root for the webapp
>> associated to the WAR archive. So both POJO and EJB3 endpoints share the
>> context-root of the war.
>>
>> * Where to look at descriptors (wsdl, xsd, jbossws-cxf.xml, ...)
>> Here I would say we first look at eventual requirements from the specs I
>> might forgetting here, otherwise the type of the archive drives the
>> position (i.e. WEB-INF/... for war archives, even if the endpoint is an
>> EJB3 one)
> IMO both JSEArchiveMetaData& EJBArchiveMetaData will need to split too.
> They contain some information that are endpoint specific.
> For example it should be possible to define context root per EJB endpoint
> in same deployment. This is what TCK6 does and we're working it around
> with some DD customization hacks. Probably as prove of concept we should
> allow support for @WebContext on POJOs as well?
Yes, I now remember those tck tests. Here is my proposal on this topic:
- start by moving the contextRoot info from the Service to the Endpoint
in jbossws-spi to prepare the way
+1
- defer the rest of the changes to another effort so for instance
keep
the JSEArchiveMetaData and EJBArchiveMetaData as they currently are for now
In the next future we'll work on allowing different context-root for
endpoints in the same webapp: that also implies deep changes in the
container integration, as most probably multiple webapps need to be
started to be able to publish endpoints in different context-roots and I
can foresee multiple issues with that (classloading just to say one).
The
@WebContext annotated with EJB3Endpoint is supported outside war
file . We won't consider to support this case this time to keep thing
simple ?
JAXWS_POJO WS endpoints coexists with EJB3Endpoint in a war file and
there is jboss-web.xml to define the Context root with specific value.
and EJB3Endpoint annotated with @WebContext.
Alessio, can your new created dynamically publish endpoint function
help on this case ?
Thanks
Jim
8:01 a.m.
Hi Jim,
On 08/31/2011 04:46 AM, Jim Ma wrote:
>> I'd say we won't have DeploymentType abstraction
anymore.
>> We will just have EndpointType abstraction with the following values:
>> * JAXWS_POJO
>> * JAXWS_EJB3
>> * JAXRPC_POJO
>> * JAXRPC_EJB21
> The jaxrpc side of the issue is still to analysed, anyway, I see your
> point, we can simply derive the DeploymentType info (JAR or WAR) from
> the new EndpointType, so the former can simply be removed.
But we still need let each endpoint easily know its
deploymentType(war,ear or jar) information and other
deployment context information(WarMetaData, EARMetaData or we wrapped
JSEArchiveMeteData, EJB EJBArchiveMetaData).
Then we can decide the address and context root when the ws endpoint is
actually published.
I believe that the jar/war info can be derived from the EndpointType
once that's set, however if I'm proven otherwise, you can keep the
DeploymentType for this.
> In the next future we'll work on allowing different
context-root for
> endpoints in the same webapp: that also implies deep changes in the
> container integration, as most probably multiple webapps need to be
> started to be able to publish endpoints in different context-roots and I
> can foresee multiple issues with that (classloading just to say one).
The @WebContext annotated with EJB3Endpoint is supported outside war
file . We won't consider to support this case this time to keep thing
simple ?
Right, that can go in the future effort.
JAXWS_POJO WS endpoints coexists with EJB3Endpoint in a war file and
there is jboss-web.xml to define the Context root with specific value.
and EJB3Endpoint annotated with @WebContext.
Alessio, can your new created dynamically publish endpoint function
help on this case ?
I'm not sure about that; we'll better evaluate when working on this
additional effort; theoretically, the new publish endpoint function does
not add anything really relevant here, but might be convenient. We'll see.
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
8:36 a.m.
Okay. Alessio. Without the @WebContext support in nested EJB3Endpoint
will be easier to
fix . I'll get a quick fix for this issue and let you look at this
patch later.
Cheers,
Jim
On 08/31/2011 02:01 PM, Alessio Soldano wrote:
Hi Jim,
On 08/31/2011 04:46 AM, Jim Ma wrote:
>>> I'd say we won't have DeploymentType abstraction anymore.
>>> We will just have EndpointType abstraction with the following values:
>>> * JAXWS_POJO
>>> * JAXWS_EJB3
>>> * JAXRPC_POJO
>>> * JAXRPC_EJB21
>> The jaxrpc side of the issue is still to analysed, anyway, I see your
>> point, we can simply derive the DeploymentType info (JAR or WAR) from
>> the new EndpointType, so the former can simply be removed.
> But we still need let each endpoint easily know its
> deploymentType(war,ear or jar) information and other
> deployment context information(WarMetaData, EARMetaData or we wrapped
> JSEArchiveMeteData, EJB EJBArchiveMetaData).
> Then we can decide the address and context root when the ws endpoint is
> actually published.
I believe that the jar/war info can be derived from the EndpointType
once that's set, however if I'm proven otherwise, you can keep the
DeploymentType for this.
>> In the next future we'll work on allowing different context-root for
>> endpoints in the same webapp: that also implies deep changes in the
>> container integration, as most probably multiple webapps need to be
>> started to be able to publish endpoints in different context-roots and I
>> can foresee multiple issues with that (classloading just to say one).
> The @WebContext annotated with EJB3Endpoint is supported outside war
> file . We won't consider to support this case this time to keep thing
> simple ?
Right, that can go in the future effort.
> JAXWS_POJO WS endpoints coexists with EJB3Endpoint in a war file and
> there is jboss-web.xml to define the Context root with specific value.
> and EJB3Endpoint annotated with @WebContext.
>
> Alessio, can your new created dynamically publish endpoint function
> help on this case ?
I'm not sure about that; we'll better evaluate when working on this
additional effort; theoretically, the new publish endpoint function does
not add anything really relevant here, but might be convenient. We'll see.
Cheers
Alessio
4894
days inactive
4896
days old
5 comments
3 participants
participants (3)
-
Alessio Soldano -
Jim Ma -
Richard Opalka