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 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]
