On Tue, Mar 24, 2009 at 10:14 PM, ant elder <[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 > > > > > > > > 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
