You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2007/04/17 00:54:42 UTC
Require more context for URLArtifactProcessorExtension.read()
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by scabooz <sc...@gmail.com>.
This thread is getting deep (and long), but I want to inject some ideas
into this part of the discussion.
I'd like to propose a target use-case that might help drive us towards
a reasonable solution. Component1 in composite1 (cz1) invokes
component2 in composite2(cz2), so c2 is @remotable. Also,
c2 has @allowsPassByReference. Both cz1 and cz2 are deployed
into the same JVM. One of the variants could be whether or not
these two composites come from the same contribution. Given that
deployed composites get included into the domain, the composite
wrapper falls away from an SCA wiring perspective.
Now, the hard part, if we wanted to implement true passByRef, the
params/results of the c1->c2 invocation would have to be loaded
by the same classloader to avoid class casts.
While it is true that hosting environments will have their own
classloader schemes, achieving the spec semantics will be hard with
just any old CL scheme. Hosting environments may have to be
adapted to handle it.
BTW, I agree with start simple and build up. Just wanted to take a
moment to propose something to build up to.
There were other questions raised below, like the lack of import/export
for java package references in the SCA deployment design. I can tell
you that the spec group envisioned extensions for this purpose, but felt it
inappropriate to do so in a language neutral spec.
Dave
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, April 24, 2007 5:04 PM
Subject: Re: Require more context for URLArtifactProcessorExtension.read()
> More comments inline.
>
> Luciano Resende wrote:
>> Comments inline...
>>
>> On 4/24/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>>
>>> Luciano Resende wrote:
>>> >> 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....
>>> >
>>>
>>> I have started to put together a class that we can use as a key to
>>> resolve classes, I'll commit it soon and then if you want I leave the
>>> rest to you :)
>>>
>>> With respect to passing a classloader to the DefaultArtifactResolver,
>>> here's what I think: SimpleRuntimeImpl currently creates a single
>>> DefaultArtifactResolver, independent of any SCA Contribution. This works
>>> for now as SimpleRuntimeImpl only handles a single Contribution, but
>>> what we really need is:
>>> - one ArtifactResolver per Contribution
>>
>>
>> How are you going to resolve things external to the contribution then ?
>> Let's say on the case of import/exports ?
>>
>> - one ClassLoader per Contribution
>>
>>
>> +1
>>
>
> Good question, the short answer is: it depends... :)
>
> My first cut of this email was actually saying "or a ClassLoader per
> contribution graph when/if we support contribution dependencies at some
> point", but I removed that sentence before sending it for a number of
> reasons, including:
>
> - Imports/exports do not cover classes at the moment, they cover XML
> namespaces, if we want to cover imports of Java artifacts we'll have to
> introduce a new <import.java> for example, and clearly define what it
> means
>
> - Imports/exports do not point to contributions, they point to location
> URIs, which can take any form, can be resolved in a runtime specific way,
> and point to other contributions, or not :)
>
> - An obvious way to support Java imports and Contribution dependency
> graphs for Java artifacts would be to use OSGI, but then maintaining a
> graph of ClassLoaders ourselves would probably get in the way of OSGI, and
> it may be much simpler to let OSGI maintain the ClassLoader graph and have
> our runtime just point to the top bundle ClassLoader, or not :) I guess
> we'll have to figure this out when we look at this integration in details
> again.
>
> - Finally, I think that the hosting environment has a role to play to
> establish, select and maintain ClassLoaders. Different hosting
> environments will probably come with very different ClassLoader management
> schemes.
>
> So I think that there are enough unknowns here to not try to boil the
> ocean with our own homegrown ClassLoader hierarchy management scheme right
> now... and suggest to start simple with one ClassLoader per SCA
> Contribution. We can define the semantics of an <import.java> extension to
> the spec later, assuming that we even need that, and worry about how that
> maps to ClassLoaders in the various hosting environments then.
>
>> - and the ArtifactResolver can get the Contribution's ClassLoader passed
>>> to its constructor.
>>
>>
>> +1
>>
>> I'm not sure if having the PackageProcessor create the ClassLoader is
>>> the best solution as the hosting environment needs to have a say with
>>> respect to which ClassLoader is used for what, but I guess we can start
>>> with that approach at least now to make progress, and change later when
>>> we have a better idea of how this fits with the various hosting
>>> environments.
>>>
>>> --
>>> Jean-Sebastien
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Jean-Sebastien Delfino <js...@apache.org>.
More comments inline.
Luciano Resende wrote:
> Comments inline...
>
> On 4/24/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> Luciano Resende wrote:
>> >> 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....
>> >
>>
>> I have started to put together a class that we can use as a key to
>> resolve classes, I'll commit it soon and then if you want I leave the
>> rest to you :)
>>
>> With respect to passing a classloader to the DefaultArtifactResolver,
>> here's what I think: SimpleRuntimeImpl currently creates a single
>> DefaultArtifactResolver, independent of any SCA Contribution. This works
>> for now as SimpleRuntimeImpl only handles a single Contribution, but
>> what we really need is:
>> - one ArtifactResolver per Contribution
>
>
> How are you going to resolve things external to the contribution then ?
> Let's say on the case of import/exports ?
>
> - one ClassLoader per Contribution
>
>
> +1
>
Good question, the short answer is: it depends... :)
My first cut of this email was actually saying "or a ClassLoader per
contribution graph when/if we support contribution dependencies at some
point", but I removed that sentence before sending it for a number of
reasons, including:
- Imports/exports do not cover classes at the moment, they cover XML
namespaces, if we want to cover imports of Java artifacts we'll have to
introduce a new <import.java> for example, and clearly define what it means
- Imports/exports do not point to contributions, they point to location
URIs, which can take any form, can be resolved in a runtime specific
way, and point to other contributions, or not :)
- An obvious way to support Java imports and Contribution dependency
graphs for Java artifacts would be to use OSGI, but then maintaining a
graph of ClassLoaders ourselves would probably get in the way of OSGI,
and it may be much simpler to let OSGI maintain the ClassLoader graph
and have our runtime just point to the top bundle ClassLoader, or not :)
I guess we'll have to figure this out when we look at this integration
in details again.
- Finally, I think that the hosting environment has a role to play to
establish, select and maintain ClassLoaders. Different hosting
environments will probably come with very different ClassLoader
management schemes.
So I think that there are enough unknowns here to not try to boil the
ocean with our own homegrown ClassLoader hierarchy management scheme
right now... and suggest to start simple with one ClassLoader per SCA
Contribution. We can define the semantics of an <import.java> extension
to the spec later, assuming that we even need that, and worry about how
that maps to ClassLoaders in the various hosting environments then.
> - and the ArtifactResolver can get the Contribution's ClassLoader passed
>> to its constructor.
>
>
> +1
>
> I'm not sure if having the PackageProcessor create the ClassLoader is
>> the best solution as the hosting environment needs to have a say with
>> respect to which ClassLoader is used for what, but I guess we can start
>> with that approach at least now to make progress, and change later when
>> we have a better idea of how this fits with the various hosting
>> environments.
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Luciano Resende wrote:
>> 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 have committed under revision 533250 the base contribution URL and the
> artifact URI to the read method.
> I still have some concerns with the inputStream as today, inputStreams
> are
> created only if there is a particular processor for the artifactType
> and if
> the artifactProcessor needs to perform something with the artifact, by
> moving the creation of the stream to the contribution service level, a
> stream will need to be created for every artifact even if there is no
> artifactProcesor to handle the file.
>
> I'll investigate possible refactoring to make this more situable .
>
Luciano,
You probably don't need to create the input stream if there's no
URLArtifactProcessor to handle it. However, there is a potential issue
if a URLArtifactProcessor does not need the input stream because it's
going get the artifact contents in a different way, or if the
URLArtifactProcessor is only interested in artifacts matching a specific
name for example and is going to skip the other artifacts, in this case
we don't want to open all these input streams if they're not needed by
the URLArtifactProcessor.
That being said, the actual requirement for a stream was for
URLArtifactProcessor.write(...) as the URLArtifactProcessor wouldn't be
able to create an output stream from a URL. However, after more
thinking, I don't see a good use case for URLArtifactProcessor.write().
If somebody wants to write an artifact (a .composite file for example),
he can use the StAXArtifactProcessor.write(...) method.
So, I think that URLArtifactProcessor.write(...) is not necessary, and
we should just remove it from the URLArtifactProcessor interface.
URLArtifactProcessor.read(...) can stay as is, i.e. we do not pass a
stream to it, and the implementer of a URLArtifactProcessor has the
flexibility to create the stream from the URL the way he wants, and only
when he needs it.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Luciano Resende <lu...@gmail.com>.
>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 have committed under revision 533250 the base contribution URL and the
artifact URI to the read method.
I still have some concerns with the inputStream as today, inputStreams are
created only if there is a particular processor for the artifactType and if
the artifactProcessor needs to perform something with the artifact, by
moving the creation of the stream to the contribution service level, a
stream will need to be created for every artifact even if there is no
artifactProcesor to handle the file.
I'll investigate possible refactoring to make this more situable .
On 4/27/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Luciano Resende wrote:
> >
> >> >> 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 have committed a change to allow ArtifactResolver to be used to
> resolve classes.
>
> Here's how to use it to get a foo.Bar class:
> ClassReference ref = new ClassReference("foo.Bar");
> ClassReference resolved = resolver.resolve(ref);
> Class clazz = resolved.getJavaClass ();
>
> The DefaultArtifactResolver constructor now takes a ClassLoader.
>
> DefaultArtifactResolver and ClassReference use WeakReferences to
> ClassLoader and Class to avoid memory leaks.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Luciano Resende wrote:
>
>> >> 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 have committed a change to allow ArtifactResolver to be used to
resolve classes.
Here's how to use it to get a foo.Bar class:
ClassReference ref = new ClassReference("foo.Bar");
ClassReference resolved = resolver.resolve(ref);
Class clazz = resolved.getJavaClass();
The DefaultArtifactResolver constructor now takes a ClassLoader.
DefaultArtifactResolver and ClassReference use WeakReferences to
ClassLoader and Class to avoid memory leaks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Luciano Resende <lu...@gmail.com>.
Comments inline...
On 4/24/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Luciano Resende wrote:
> >> 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....
> >
>
> I have started to put together a class that we can use as a key to
> resolve classes, I'll commit it soon and then if you want I leave the
> rest to you :)
>
> With respect to passing a classloader to the DefaultArtifactResolver,
> here's what I think: SimpleRuntimeImpl currently creates a single
> DefaultArtifactResolver, independent of any SCA Contribution. This works
> for now as SimpleRuntimeImpl only handles a single Contribution, but
> what we really need is:
> - one ArtifactResolver per Contribution
How are you going to resolve things external to the contribution then ?
Let's say on the case of import/exports ?
- one ClassLoader per Contribution
+1
- and the ArtifactResolver can get the Contribution's ClassLoader passed
> to its constructor.
+1
I'm not sure if having the PackageProcessor create the ClassLoader is
> the best solution as the hosting environment needs to have a say with
> respect to which ClassLoader is used for what, but I guess we can start
> with that approach at least now to make progress, and change later when
> we have a better idea of how this fits with the various hosting
> environments.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Luciano Resende wrote:
>> 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....
>
I have started to put together a class that we can use as a key to
resolve classes, I'll commit it soon and then if you want I leave the
rest to you :)
With respect to passing a classloader to the DefaultArtifactResolver,
here's what I think: SimpleRuntimeImpl currently creates a single
DefaultArtifactResolver, independent of any SCA Contribution. This works
for now as SimpleRuntimeImpl only handles a single Contribution, but
what we really need is:
- one ArtifactResolver per Contribution
- one ClassLoader per Contribution
- and the ArtifactResolver can get the Contribution's ClassLoader passed
to its constructor.
I'm not sure if having the PackageProcessor create the ClassLoader is
the best solution as the hosting environment needs to have a say with
respect to which ClassLoader is used for what, but I guess we can start
with that approach at least now to make progress, and change later when
we have a better idea of how this fits with the various hosting
environments.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Luciano Resende <lu...@gmail.com>.
>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 <js...@apache.org> 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"
> >> <lu...@gmail.com>
> >> To: <tu...@ws.apache.org>
> >> 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 <en...@gmail.com> 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" <js...@apache.org>
> >>>> To: <tu...@ws.apache.org>
> >>>> 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: tuscany-dev-unsubscribe@ws.apache.org
> >>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>> >
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Luciano Resende
> >>> http://people.apache.org/~lresende
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> > 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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"
>> <lu...@gmail.com>
>> To: <tu...@ws.apache.org>
>> 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 <en...@gmail.com> 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" <js...@apache.org>
>>>> To: <tu...@ws.apache.org>
>>>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>> >
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Luciano Resende
>>> http://people.apache.org/~lresende
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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"
> <lu...@gmail.com>
> To: <tu...@ws.apache.org>
> 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 <en...@gmail.com> 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" <js...@apache.org>
>>> To: <tu...@ws.apache.org>
>>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
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.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Raymond Feng <en...@gmail.com>.
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" <lu...@gmail.com>
To: <tu...@ws.apache.org>
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 <en...@gmail.com> 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" <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> 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: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Luciano Resende <lu...@gmail.com>.
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 <en...@gmail.com> 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" <js...@apache.org>
> To: <tu...@ws.apache.org>
> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Raymond Feng <en...@gmail.com>.
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" <js...@apache.org>
To: <tu...@ws.apache.org>
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Require more context for URLArtifactProcessorExtension.read()
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org