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.

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.

  - 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

--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Reply via email to