You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Vamsavardhana Reddy <c1...@gmail.com> on 2009/02/27 14:01:53 UTC
SCA Java EE: WAR contribution processing
The way a regular SCA contribution jar is processed is that first a
PackageProcessor constructs a list of URLs to the artifacts inside the jar,
then a URLArtifactProcessor processes the individual URLs in the list and
associates a Tuscany model object with the URL. In case of a WAR file,
there will be a single componentType which corresponds to the whole WAR as
an artifact and the entire WAR file needs to be processed at once (for e.g.,
we are using openejb) to compute the Servlets, EJB references etc. This
componentType can not be associated with any single artifact that is inside
the WAR file. Also, an SCA-enhanced WAR file will contain SCA artifacts
which may be processed in a similar manner as those contained in a regular
SCA contribution.
The approach I have in mind is the following:
The PackageProcessor for a WAR file will construct the list of URLs to the
artifacts inside the WAR file in addition to the WAR file itself being an
entry in that list. (In case of jar files, the PackageProcessor creates a
list of URLs to artifacts in the jar only.) For example, if the WAR file
my-web-app.war contains web.xml, web.composite, index.jsp etc., the
constructed URLs list will contain "my-web-app.war", "WEB-INF/web.xml",
"WEB-INF/web.composite", "index.jsp" etc. Individual implementations can
plugin WAR artifact processor to return the remote EJB references, the
Servlet, Filter, Listener and JSF POJO classes that need to be processed for
SCA annotations. Then the componentType derived from the WAR can be merged
with the componentType derived from SCA annotation processing in web
artifacts (i.e., the Servlet, Filter, Listener and JSF POJO classes) and the
SCA artifacts in the WAR.
Any comments, suggestions?
++Vamsi
Re: SCA Java EE: WAR contribution processing
Posted by ant elder <an...@apache.org>.
On Tue, Mar 24, 2009 at 5:52 PM, Vamsavardhana Reddy
<c1...@gmail.com> wrote:
>
>
> On Tue, Mar 24, 2009 at 10:14 PM, ant elder <an...@gmail.com> wrote:
>>
>> On Fri, Feb 27, 2009 at 1:01 PM, Vamsavardhana Reddy
>> <c1...@gmail.com> wrote:
>> > The way a regular SCA contribution jar is processed is that first a
>> > PackageProcessor constructs a list of URLs to the artifacts inside the
>> > jar,
>> > then a URLArtifactProcessor processes the individual URLs in the list
>> > and
>> > associates a Tuscany model object with the URL. In case of a WAR file,
>> > there will be a single componentType which corresponds to the whole WAR
>> > as
>> > an artifact and the entire WAR file needs to be processed at once (for
>> > e.g.,
>> > we are using openejb) to compute the Servlets, EJB references etc. This
>> > componentType can not be associated with any single artifact that is
>> > inside
>> > the WAR file. Also, an SCA-enhanced WAR file will contain SCA artifacts
>> > which may be processed in a similar manner as those contained in a
>> > regular
>> > SCA contribution.
>> >
>> > The approach I have in mind is the following:
>> > The PackageProcessor for a WAR file will construct the list of URLs to
>> > the
>> > artifacts inside the WAR file in addition to the WAR file itself being
>> > an
>> > entry in that list. (In case of jar files, the PackageProcessor creates
>> > a
>> > list of URLs to artifacts in the jar only.) For example, if the WAR
>> > file
>> > my-web-app.war contains web.xml, web.composite, index.jsp etc., the
>> > constructed URLs list will contain "my-web-app.war", "WEB-INF/web.xml",
>> > "WEB-INF/web.composite", "index.jsp" etc. Individual implementations can
>> > plugin WAR artifact processor to return the remote EJB references, the
>> > Servlet, Filter, Listener and JSF POJO classes that need to be processed
>> > for
>> > SCA annotations. Then the componentType derived from the WAR can be
>> > merged
>> > with the componentType derived from SCA annotation processing in web
>> > artifacts (i.e., the Servlet, Filter, Listener and JSF POJO classes) and
>> > the
>> > SCA artifacts in the WAR.
>> >
>> > Any comments, suggestions?
>> >
>> > ++Vamsi
>> >
>> >
>> >
>>
>> I've just being trying to use a webapp sample in 1.x and found when
>> using implementation.web it now requires lots of new dependencies like
>> emf and openejb even for simple webapps that don't use any ejb. Could
>> these dependencies be made optional or moved to an optional module
>> that you don't have to include if you don't need ejb introspection?
>
> If you are noticing these dependencies in your Eclipse workspace, you may
> have to do eclipse:clean and eclipse:eclipse to create the project files.
>
Ok yes updating to that latest code today those dependencies don't get
included now, thanks.
Using implementation-web doesn't automatically include the
cointribution-jee-impl module, what is that module for and when would
it need to be included?
...ant
Re: SCA Java EE: WAR contribution processing
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
On Tue, Mar 24, 2009 at 10:14 PM, ant elder <an...@gmail.com> wrote:
> On Fri, Feb 27, 2009 at 1:01 PM, Vamsavardhana Reddy
> <c1...@gmail.com> wrote:
> > The way a regular SCA contribution jar is processed is that first a
> > PackageProcessor constructs a list of URLs to the artifacts inside the
> jar,
> > then a URLArtifactProcessor processes the individual URLs in the list and
> > associates a Tuscany model object with the URL. In case of a WAR file,
> > there will be a single componentType which corresponds to the whole WAR
> as
> > an artifact and the entire WAR file needs to be processed at once (for
> e.g.,
> > we are using openejb) to compute the Servlets, EJB references etc. This
> > componentType can not be associated with any single artifact that is
> inside
> > the WAR file. Also, an SCA-enhanced WAR file will contain SCA artifacts
> > which may be processed in a similar manner as those contained in a
> regular
> > SCA contribution.
> >
> > The approach I have in mind is the following:
> > The PackageProcessor for a WAR file will construct the list of URLs to
> the
> > artifacts inside the WAR file in addition to the WAR file itself being an
> > entry in that list. (In case of jar files, the PackageProcessor creates
> a
> > list of URLs to artifacts in the jar only.) For example, if the WAR file
> > my-web-app.war contains web.xml, web.composite, index.jsp etc., the
> > constructed URLs list will contain "my-web-app.war", "WEB-INF/web.xml",
> > "WEB-INF/web.composite", "index.jsp" etc. Individual implementations can
> > plugin WAR artifact processor to return the remote EJB references, the
> > Servlet, Filter, Listener and JSF POJO classes that need to be processed
> for
> > SCA annotations. Then the componentType derived from the WAR can be
> merged
> > with the componentType derived from SCA annotation processing in web
> > artifacts (i.e., the Servlet, Filter, Listener and JSF POJO classes) and
> the
> > SCA artifacts in the WAR.
> >
> > Any comments, suggestions?
> >
> > ++Vamsi
> >
> >
> >
>
> I've just being trying to use a webapp sample in 1.x and found when
> using implementation.web it now requires lots of new dependencies like
> emf and openejb even for simple webapps that don't use any ejb. Could
> these dependencies be made optional or moved to an optional module
> that you don't have to include if you don't need ejb introspection?
If you are noticing these dependencies in your Eclipse workspace, you may
have to do eclipse:clean and eclipse:eclipse to create the project files.
>
>
> ...ant
>
--
Vamsi
Re: SCA Java EE: WAR contribution processing
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
On Tue, Mar 24, 2009 at 10:14 PM, ant elder <an...@gmail.com> wrote:
> On Fri, Feb 27, 2009 at 1:01 PM, Vamsavardhana Reddy
> <c1...@gmail.com> wrote:
> > The way a regular SCA contribution jar is processed is that first a
> > PackageProcessor constructs a list of URLs to the artifacts inside the
> jar,
> > then a URLArtifactProcessor processes the individual URLs in the list and
> > associates a Tuscany model object with the URL. In case of a WAR file,
> > there will be a single componentType which corresponds to the whole WAR
> as
> > an artifact and the entire WAR file needs to be processed at once (for
> e.g.,
> > we are using openejb) to compute the Servlets, EJB references etc. This
> > componentType can not be associated with any single artifact that is
> inside
> > the WAR file. Also, an SCA-enhanced WAR file will contain SCA artifacts
> > which may be processed in a similar manner as those contained in a
> regular
> > SCA contribution.
> >
> > The approach I have in mind is the following:
> > The PackageProcessor for a WAR file will construct the list of URLs to
> the
> > artifacts inside the WAR file in addition to the WAR file itself being an
> > entry in that list. (In case of jar files, the PackageProcessor creates
> a
> > list of URLs to artifacts in the jar only.) For example, if the WAR file
> > my-web-app.war contains web.xml, web.composite, index.jsp etc., the
> > constructed URLs list will contain "my-web-app.war", "WEB-INF/web.xml",
> > "WEB-INF/web.composite", "index.jsp" etc. Individual implementations can
> > plugin WAR artifact processor to return the remote EJB references, the
> > Servlet, Filter, Listener and JSF POJO classes that need to be processed
> for
> > SCA annotations. Then the componentType derived from the WAR can be
> merged
> > with the componentType derived from SCA annotation processing in web
> > artifacts (i.e., the Servlet, Filter, Listener and JSF POJO classes) and
> the
> > SCA artifacts in the WAR.
> >
> > Any comments, suggestions?
> >
> > ++Vamsi
> >
> >
> >
>
> I've just being trying to use a webapp sample in 1.x and found when
> using implementation.web it now requires lots of new dependencies like
> emf and openejb even for simple webapps that don't use any ejb. Could
> these dependencies be made optional or moved to an optional module
> that you don't have to include if you don't need ejb introspection?
Earlier, the openejb dependency was in module\contribution-jee. Those
dependencies have been removed when the extension point is created for Java
EE processing and now the openejb dependency is only in
module\contribution-jee-impl. module\implementation-web depends only on
module\contribution-jee. I am wondering how the openejb dependencies are
creeping into implementation-web.
>
> ...ant
>
--
Vamsi
Re: SCA Java EE: WAR contribution processing
Posted by ant elder <an...@gmail.com>.
On Fri, Feb 27, 2009 at 1:01 PM, Vamsavardhana Reddy
<c1...@gmail.com> wrote:
> The way a regular SCA contribution jar is processed is that first a
> PackageProcessor constructs a list of URLs to the artifacts inside the jar,
> then a URLArtifactProcessor processes the individual URLs in the list and
> associates a Tuscany model object with the URL. In case of a WAR file,
> there will be a single componentType which corresponds to the whole WAR as
> an artifact and the entire WAR file needs to be processed at once (for e.g.,
> we are using openejb) to compute the Servlets, EJB references etc. This
> componentType can not be associated with any single artifact that is inside
> the WAR file. Also, an SCA-enhanced WAR file will contain SCA artifacts
> which may be processed in a similar manner as those contained in a regular
> SCA contribution.
>
> The approach I have in mind is the following:
> The PackageProcessor for a WAR file will construct the list of URLs to the
> artifacts inside the WAR file in addition to the WAR file itself being an
> entry in that list. (In case of jar files, the PackageProcessor creates a
> list of URLs to artifacts in the jar only.) For example, if the WAR file
> my-web-app.war contains web.xml, web.composite, index.jsp etc., the
> constructed URLs list will contain "my-web-app.war", "WEB-INF/web.xml",
> "WEB-INF/web.composite", "index.jsp" etc. Individual implementations can
> plugin WAR artifact processor to return the remote EJB references, the
> Servlet, Filter, Listener and JSF POJO classes that need to be processed for
> SCA annotations. Then the componentType derived from the WAR can be merged
> with the componentType derived from SCA annotation processing in web
> artifacts (i.e., the Servlet, Filter, Listener and JSF POJO classes) and the
> SCA artifacts in the WAR.
>
> Any comments, suggestions?
>
> ++Vamsi
>
>
>
I've just being trying to use a webapp sample in 1.x and found when
using implementation.web it now requires lots of new dependencies like
emf and openejb even for simple webapps that don't use any ejb. Could
these dependencies be made optional or moved to an optional module
that you don't have to include if you don't need ejb introspection?
...ant
Re: SCA Java EE: WAR contribution processing
Posted by Simon Laws <si...@googlemail.com>.
Hi Vamsi
I updated the JEE wiki page [1] with a number of different deployment
scenarios. I'm not entirely convinced they are all useful, or even
valid, but I'm just thinking about the various combinations of
enhanced and un-enhanced ears, wars and jars you can have.
Regards
Simon
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Java+EE+Integration
Re: SCA Java EE: WAR contribution processing
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
On Fri, Feb 27, 2009 at 9:18 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Fri, Feb 27, 2009 at 1:01 PM, Vamsavardhana Reddy <c1...@gmail.com>wrote:
>
>> The way a regular SCA contribution jar is processed is that first a
>> PackageProcessor constructs a list of URLs to the artifacts inside the jar,
>> then a URLArtifactProcessor processes the individual URLs in the list and
>> associates a Tuscany model object with the URL. In case of a WAR file,
>> there will be a single componentType which corresponds to the whole WAR as
>> an artifact and the entire WAR file needs to be processed at once (for e.g.,
>> we are using openejb) to compute the Servlets, EJB references etc. This
>> componentType can not be associated with any single artifact that is inside
>> the WAR file. Also, an SCA-enhanced WAR file will contain SCA artifacts
>> which may be processed in a similar manner as those contained in a regular
>> SCA contribution.
>>
>> The approach I have in mind is the following:
>> The PackageProcessor for a WAR file will construct the list of URLs to the
>> artifacts inside the WAR file in addition to the WAR file itself being an
>> entry in that list. (In case of jar files, the PackageProcessor creates a
>> list of URLs to artifacts in the jar only.) For example, if the WAR file
>> my-web-app.war contains web.xml, web.composite, index.jsp etc., the
>> constructed URLs list will contain "my-web-app.war", "WEB-INF/web.xml",
>> "WEB-INF/web.composite", "index.jsp" etc. Individual implementations can
>> plugin WAR artifact processor to return the remote EJB references, the
>> Servlet, Filter, Listener and JSF POJO classes that need to be processed for
>> SCA annotations. Then the componentType derived from the WAR can be merged
>> with the componentType derived from SCA annotation processing in web
>> artifacts (i.e., the Servlet, Filter, Listener and JSF POJO classes) and the
>> SCA artifacts in the WAR.
>>
>> Any comments, suggestions?
>>
>> ++Vamsi
>>
>>
>>
> Hi Vamsi
>
> I want to make sure I understand your scenarios. Image the following
> directory structure....
>
> mydir /
> A mySCAContribution
> myComposite1.composite
> implementation.ejb ejb-link=""
> implementation.web web-uri=""
> implementation.ear archive=""
> MyComponent1Impl.class
>
> B myWebAppSCAEnhanced.war
> index.html
> my.jsp
> WEB-INF/
> web.xml
> web.composite
> implementation.web web-uri=""
>
> C myEJBSCAEnchanced.jar
> myBean.class
> META-INF/
> ejb-jar.composite
> implementation.ejb ejb-link=""
>
> D MyEnterpriseAppSCAEnhanced.ear
> myWebApp1.war
> myEJB1.jar
> META-INF/
> application.composite
> implementation.ejb ejb-link=""
> implementation.web web-uri=""
> implementation.ear archive=""
>
> E myWebAppNonSCAEnhanced.war/
> my.jsp
>
> F myEJBNonSCAEnchanced.jar
> myBean.class
>
> G MyEnterpriseAppNonSCAEnhanced.ear
> myWebApp1.war
> myEJB1.jar
>
>
> When you say..
>
> "In case of a WAR file, there will be a single componentType which
> corresponds to the whole WAR as an artifact and the entire WAR file needs to
> be processed at once (for e.g., we are using openejb) to compute the
> Servlets, EJB references etc. This componentType can not be associated with
> any single artifact that is inside the WAR file."
>
> I think you are talking about directory (B) above where the WAR file is a
> contribution. Hence all of the artifacts within must be identified
> independently. Also the composite file within the WAR could use
> implementation.web and this is the other case where you have to establish
> the component type based on the WAR as a whole.
>
> It's not clear to me, given the support we have, if directory (A) which
> references a separate web application, e.g. directory (E) using
> web-uri="../myWebbAppNonSCAEnhanced.was", does anything sensible.
implementation.web is to be used only inside Java EE contributions. In this
case, (A) will have to use implementation.jee.
>
>
> Anyhow I see you point. That certainly, in the first case, we have to treat
> a WAR as both a contribution and a contribution artifact. In the directory
> (B) case I follow your logic that we can trap the fact that the war
> contributon could also be treated as an artifact in it's own right. So I
> think you are on the right track.
>
> Does the JEE spec allow for the scenario where the implementation.web that
> is in directory (A) refers to the web app in directory (B) which is SCA
> enhanced itself? In this case we would have to again do contribution style
> processing on the references webapp. Is the implication here that directory
> (B) must itself have been added as a contribution for this processing to
> complete? TO ask the question another way. If you add a JEE archive with SCA
> enhancement to Geronimo via the SCA plugin does it assume that it's a
> contribution?
The JEE spec does not explicitly say that implementation.web and
implementation.ejb are to be used only in Java EE contributions. The plugin
does not currently process a Java EE archive as an SCA contribution. It is
creating a temporary jar which contains specific SCA artifacts from the
original archive and which will be used as a contribution to deploy the SCA
components that model the Java EE components.
>
> I'd like to see a list like this that identifies which of these
> combinations are valid and what is the expected outcome. This is
> suffuciently complex that it is not immediately obvious and so I think being
> explicit will help. Maybe you already have these set up as test cases?
> Anyhow I'm happy to help with this if you are keen.
Thanks Simon. I will create a list of the valid combinations.
>
> Regards
>
> Simon
>
--
Vamsi
Re: SCA Java EE: WAR contribution processing
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Feb 27, 2009 at 1:01 PM, Vamsavardhana Reddy <c1...@gmail.com>wrote:
> The way a regular SCA contribution jar is processed is that first a
> PackageProcessor constructs a list of URLs to the artifacts inside the jar,
> then a URLArtifactProcessor processes the individual URLs in the list and
> associates a Tuscany model object with the URL. In case of a WAR file,
> there will be a single componentType which corresponds to the whole WAR as
> an artifact and the entire WAR file needs to be processed at once (for e.g.,
> we are using openejb) to compute the Servlets, EJB references etc. This
> componentType can not be associated with any single artifact that is inside
> the WAR file. Also, an SCA-enhanced WAR file will contain SCA artifacts
> which may be processed in a similar manner as those contained in a regular
> SCA contribution.
>
> The approach I have in mind is the following:
> The PackageProcessor for a WAR file will construct the list of URLs to the
> artifacts inside the WAR file in addition to the WAR file itself being an
> entry in that list. (In case of jar files, the PackageProcessor creates a
> list of URLs to artifacts in the jar only.) For example, if the WAR file
> my-web-app.war contains web.xml, web.composite, index.jsp etc., the
> constructed URLs list will contain "my-web-app.war", "WEB-INF/web.xml",
> "WEB-INF/web.composite", "index.jsp" etc. Individual implementations can
> plugin WAR artifact processor to return the remote EJB references, the
> Servlet, Filter, Listener and JSF POJO classes that need to be processed for
> SCA annotations. Then the componentType derived from the WAR can be merged
> with the componentType derived from SCA annotation processing in web
> artifacts (i.e., the Servlet, Filter, Listener and JSF POJO classes) and the
> SCA artifacts in the WAR.
>
> Any comments, suggestions?
>
> ++Vamsi
>
>
>
Hi Vamsi
I want to make sure I understand your scenarios. Image the following
directory structure....
mydir /
A mySCAContribution
myComposite1.composite
implementation.ejb ejb-link=""
implementation.web web-uri=""
implementation.ear archive=""
MyComponent1Impl.class
B myWebAppSCAEnhanced.war
index.html
my.jsp
WEB-INF/
web.xml
web.composite
implementation.web web-uri=""
C myEJBSCAEnchanced.jar
myBean.class
META-INF/
ejb-jar.composite
implementation.ejb ejb-link=""
D MyEnterpriseAppSCAEnhanced.ear
myWebApp1.war
myEJB1.jar
META-INF/
application.composite
implementation.ejb ejb-link=""
implementation.web web-uri=""
implementation.ear archive=""
E myWebAppNonSCAEnhanced.war/
my.jsp
F myEJBNonSCAEnchanced.jar
myBean.class
G MyEnterpriseAppNonSCAEnhanced.ear
myWebApp1.war
myEJB1.jar
When you say..
"In case of a WAR file, there will be a single componentType which
corresponds to the whole WAR as an artifact and the entire WAR file needs to
be processed at once (for e.g., we are using openejb) to compute the
Servlets, EJB references etc. This componentType can not be associated with
any single artifact that is inside the WAR file."
I think you are talking about directory (B) above where the WAR file is a
contribution. Hence all of the artifacts within must be identified
independently. Also the composite file within the WAR could use
implementation.web and this is the other case where you have to establish
the component type based on the WAR as a whole.
It's not clear to me, given the support we have, if directory (A) which
references a separate web application, e.g. directory (E) using
web-uri="../myWebbAppNonSCAEnhanced.was", does anything sensible.
Anyhow I see you point. That certainly, in the first case, we have to treat
a WAR as both a contribution and a contribution artifact. In the directory
(B) case I follow your logic that we can trap the fact that the war
contributon could also be treated as an artifact in it's own right. So I
think you are on the right track.
Does the JEE spec allow for the scenario where the implementation.web that
is in directory (A) refers to the web app in directory (B) which is SCA
enhanced itself? In this case we would have to again do contribution style
processing on the references webapp. Is the implication here that directory
(B) must itself have been added as a contribution for this processing to
complete? TO ask the question another way. If you add a JEE archive with SCA
enhancement to Geronimo via the SCA plugin does it assume that it's a
contribution?
I'd like to see a list like this that identifies which of these combinations
are valid and what is the expected outcome. This is suffuciently complex
that it is not immediately obvious and so I think being explicit will help.
Maybe you already have these set up as test cases? Anyhow I'm happy to help
with this if you are keen.
Regards
Simon