Hi,
I was refering to artifact URI instead of contribution URI. For example, if
a jar contribution is deployed, the URI of a class named a.b.MyClass in the
jar will be "a/b/MyClass.class".
ContributionContext is one way to pass more context to the processors. But I
don't think it will go through injection. It should be on the method
signature of the SPI.
Thanks,
Raymond
----- Original Message -----
From: "Luciano Resende" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, April 17, 2007 1:43 PM
Subject: Re: Require more context for URLArtifactProcessorExtension.read()
Hi Raymond
I'm not sure if the Contribution URI will really work for your
requirements, as of today, the URL that the artifactProcessor receives is
the actual artifact URL location, and it's not based on the Contribution
URI
and also can be normalized based on the contribution package type (e.g jar
will have a jar URL). Thinking on the second requirement, if we create a
contribution context with some basic contribution information
(e.gcontribution uri, contribution base location, normalized
contribution base
location, and the contribution classloader) and "inject" it on the
processor, then you would have the necessary information to perform the
necessary actions you need?
Once we agree on a solution, I can get it implemented.
Thoughts ?
On 4/17/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
I think you already got it right. I want to contribute a processor to
scan
the classes to figure out available generated SDO factory
interface/class.
During the "read" phase, the processor will capture the classname by a
naming pattern. The class will be loaded during "resolve" phase and the
factory will be registered with a HelperContext.
I see two requirements here:
1) read: Pass in the URI of the artifact which can be used to derive the
class name
2) resolve: Pass in a contribution classloader which can be used to
resolve
java classes
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, April 17, 2007 11:22 AM
Subject: Re: Require more context for
URLArtifactProcessorExtension.read()
> Raymond Feng wrote:
>> Hi,
>>
>> When I try to add a URLArtifactProcessorExtension to introspect java
>> classes, I found it impossible to get the class name as only the URL
>> of
>> the class file is passed to the read() method. To provide such
>> context,
I
>> suggest that we pass in the DeployedArtifact (which contains the URL)
>> instead of URL to the read() method.
>>
>> Do you agree or do you have a better way?
>>
>> Thanks,
>> Raymond
>>
>
> Could you give more context as well? :) and describe what you're trying
to
> do?
>
> Are you trying to derive a class name from the file name? Are you going
to
> load or read the class file and could you find the class name from its
> contents then?
>
> It's a little difficult to try to answer without more context, but in
> general I would prefer for ArtifactProcessors not to have to know the
> structure of the Contribution or the DeployedArtifacts that represent
it.
> If you need to know the base URL of the contribution and the path of
> the
> given Artifact inside it, then maybe we could pass these two parameters
to
> the read() method, it would be better than passing the whole
> DeployedArtifact and have the read() method dig into it.
>
> But again, before we do that, could you describe your use case? and
> then
> hopefully we can find a good solution for it. Thanks.
>
> --
> 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
http://people.apache.org/~lresende
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
