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
