On Fri, Feb 27, 2009 at 9:18 PM, Simon Laws <[email protected]>wrote:
> > > 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. 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
