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]
