I was thinking that Class loading would be the responsibility of the ArtifactResolver. So, we wouldn't need a ClassLoader, we would call ArtifactResolver.resolve() to get the Class, like for all other artifacts resolved in an SCA contribution.
I think that the packageProcessor should be the one creating the necessary contribution classLoader, but how does the resolver will get a reference to it ? I can have it done if you haven't started it yet.... On 4/24/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote: > Raymond Feng wrote: >> 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] >> >> > > A few thoughts: > - You need the URI of an artifact inside the SCA contribution. > - I indicated before that I needed input/outputStreams as well. > - I think it's useful to have the URL of the contribution to have a > base URL to load artifacts (for example for WSDLs and XSDs if they do > <import ... location="/aFile.xsd or /aFile.wsdl">). > > So I suggest read/write(URL contributionURL, String artifactURI, > Input/OutputStream input/outputStream). In most cases you just use the > input/outputStream, sometimes you need to know the contributionURL, > and if you want to know the artifact URL you do new > URL(contributionURL, artifactURI). > > I was thinking that Class loading would be the responsibility of the > ArtifactResolver. So, we wouldn't need a ClassLoader, we would call > ArtifactResolver.resolve() to get the Class, like for all other > artifacts resolved in an SCA contribution. > Nobody has commented on this yet, so if there's I'm going to add a little bit of code to the DefaultArtifactResolver to resolve classes in the scope of a contribution. I'll probably make a small change to the Java interface and Java implementation ArtifactProcessors as well to use the ArtifactResolver to resolve the relevant classes. These changes should be ready later today, probably at the end of the day. -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Luciano Resende http://people.apache.org/~lresende
