On Fri, Feb 27, 2009 at 1:01 PM, Vamsavardhana Reddy <[email protected]>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

Reply via email to