Jean-Sebastien wrote :
Why can't whole contents of the WAR be part of the contribution?
Currently this is how things are done. Is there any requirement to filter the contents of WEB-INF\lib, or dependency libraries should also be processed by the contribution ? Well, overall, looks like people are ok with the current behavior described, if that is the case I will leave things the way they are today, and won't even introduce the war/web-folder package processors. On 5/18/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Please see my comments below. Thanks, Raymond ----- Original Message ----- From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, May 18, 2007 6:43 PM Subject: Re: Proposed changes to PackageProcessor to handle artifact URI consistently > Some comments and questions inline. > > Luciano Resende wrote: >> After reviewing the changes to properly find the contribution root in web >> applications, I noticed that these changes introduced a side effect, and >> now >> artifact URIs are being produced differently based on how your >> contribution >> is packaged : jar or folder (artifact uris will be like >> calculator/CalculatorClient.class) and in web applications artifact URIs >> will be like ( e.g WEB-INF/classes/calculator/calculatorClient.class >> instead of calculator/calculatorClient.class). My guess is that this >> would >> be a problem in scenarios like trying to find the class names to properly >> introspect them as requested in [1], so I was thinking about a way to fix >> this. > > Do we have this problem? We had this discussion in [1] but at the time we > had not thought about WARs and archive structures that do not place their > classes at the root... I don't think that trying to guess class names from > the path of their class files is reliable in general. I guess the issue > that you're bringing up with WARs is a good example of the problems that > we could run into if we were doing that... but I don't think we do at the > moment. > > I'm not sure about what you're suggesting, Stripping the WEB-INF/classes/ > could be confusing and also cause collisions with resources outside of > WEB-INF/classes... Why can't we just keep the correct URI > WEB-INF/classes/calculator/calculatorClient.class? > I think we need to keep the artifact URIs as-is to maintain the hierarchy defined by the SCA spec. The java classpath and java class name are special for java classloading. I think the PackageProcessor probably needs to figure out the URLs (or URIs) for the classpath and then the real class name can be calculated from the classpath entries. For example, the WAR processor will tell WEB-INF/classes and WEB-INF/lib/a.jar, WEB-INF/b.jar are the classpath entries, then artifact processor that are only interested in java classes should only look into the children under the classpath entries. >> >> I have made a local prototype, and below is a description of the proposed >> changes : >> >> - create a warContributionProcessor and WebFolderContributionProcessor >> that would know how to properly process the web application package, >> excluding unnecessary artifacts and producing correct artifact URIs >> consistently. >> > > Why would we exclude anything? Why can't whole contents of the WAR be part > of the contribution? I understand that Java classes are under > WEB-INF/classes, but WSDL or XSD files for example don't have to. Actually > usually you'll want to place some of your WSDL files under Web content > folder to publish them on your Web server. > >> - change the signature PackageProcessor.getArtifacts to return a list >> of >> DeployedArtifacts. Originally, this method was returning a list of URIs, >> and >> the URIs were being used later on in ContributionServicesImpl to create >> the >> right artifact location URL, so, if the package processor fixup the >> artifact >> URI, it would break how artifact locations were being generated, so I >> took >> the same idea where we create unprocessed Composites, and created >> unprocessed DeployedArtifacts with the proper artifact URI and >> LocationURL, >> and these artifacts would then be processed by the contribution service >> that >> would populate and resolve the artifact model. These changes also >> simplify >> the packageProcessor interface, and don't require a look up to find the >> right package processor for each artifact to properly create the >> artifactURL >> later on when the contribution service try to create the artifact (as >> different packages would generate different location URL like jar would >> be >> jar:file.jar!/artifact.xxx). Note that the packageProcessors receive the >> contribution model factory so contribution model objects can be created >> consistently. >> >> Please let me know your thoughts, or if you have a better and simpler >> idea >> to consistently solve this problem. >> >> [1] http://www.mail-archive.com/[email protected]/msg16716.html >> > > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
