You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2008/03/10 10:40:56 UTC
About StAXArtifactProcessor
Hi,
I recently faced a situation where I wished to passed some context from one
StAXArtifact Processor to others down the chain. More specifically, to get
the 'targetNamespace' of the definitions.xml file apply to PoliyIntent and
PolicySet names, I wished to pass the 'targetNamespace' value from the
Definitions Processor (which is where it is read) down to the PolicyIntent
and PolicySet processors. I could not figure out a way to do this. Am I
missing something here or would it make sense to add an argument named
'context' to the read methods of our StAXProcessor ? I guess there could be
other situations when we might need some information from parent element to
be passed down.
Thoughts ?
Thanks
- Venkat
Re: Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor
Posted by scabooz <sc...@gmail.com>.
Hi guys,
I'm not an XML expert but I think if you wanted that qualified intent
to be in a separate namespace you'd do it like this:
<definitions targetNamespace="http://www.apache.org/tuscany" ..>
<intent name="managedTransaction.global">
<description>
Used to indicate that a component implementation requires a
managed global transaction.
</description>
</intent>
</definitions>
You cannot put the QName into intent/@name.
I don't understand why anyone would want to put qualifiers in a
namespace different than the parent intent.
A recent decision in the OASIS Policy spec has made separate
namespaces impossible so I don't think you should spend much time
worrying about it.
Dave
----- Original Message -----
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Thursday, March 20, 2008 8:43 AM
Subject: Re: Qualifiable Policy intents - QNames or NCNames? was: About
StAXArtifactProcessor
> Hi Sebastien,
>
> Here is a snippet from
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy-transaction/src/main/resources/org/apache/tuscany/sca/policy/transaction/definitions.xml
>
> ----------------- definitions.xml ---------------------
>
> <definitions xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="
> http://www.osoa.org/xmlns/sca/1.0"
> xmlns:sca="http://www.osoa.org/xmlns/sca/1.0" xmlns:tuscany="
> http://tuscany.apache.org/xmlns/sca/1.0">
>
> <intent name="managedTransaction" constrains="implementation">
> <description>Used to indicate the transaction environment desired
> by
> a component implementation.</description>
> </intent>
>
> <intent name="managedTransaction.global">
> <description>
> Used to indicate that a component implementation requires a
> managed global transaction.
> </description>
> </intent>
>
> <intent name="managedTransaction.local">
> <description>
> Used to indicate that a component implementation requires a
> managed local transaction.
> </description>
> </intent>
>
> ..............
>
> -------------------------------------------------------------------------------------------
>
> Over here, the intents "managedTransaction.global" and "
> managedTransaction.local" are qualified intents with "managedTransaction"
> being the qualifiable intent. Since we have decided that the 'name'
> attribute of an 'intent' element is going to be NCName we end up forcing
> the
> qualifiable intent to also belong to the targetnamespace. If it belonged
> to
> namespace other than the target, then we'd have to deal with how we can
> represent this for example we could resort to ...
>
> <intent name="tuscany:managedTransaction.global">
> <description>
> Used to indicate that a component implementation requires a
> managed global transaction.
> </description>
> </intent>
>
> where we could say that managedTransaction is an intent defined under the
> namespace that the prefix 'tuscany' points to. But if we did this, the
> 'name' attribute must be read a QName which ends us in a contradiction.
>
> Thanks
>
> - Venkat
>
>
>
> On Thu, Mar 20, 2008 at 2:14 AM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Venkata Krishnan wrote:
>> > Hi Sebastien,
>> >
>> > Thanks. Please find my comments inline. Not much though :)
>> >
>> > On Tue, Mar 18, 2008 at 3:46 AM, Jean-Sebastien Delfino <
>> > jsdelfino@apache.org> wrote:
>> >
>> >> Venkata Krishnan wrote:
>> >>>> 2) Unless I'm missing something, I don't think that you need to set
>> the
>> >>>> targetNamespace of QualifiedIntent.qualifiableIntents, as it looks
>> like
>> >>>> it's already read as a QName from the XML stream (and this QName
>> >>>> does
>> >>>> not have to be in the current targetNamespace).
>> >>>
>> >>> First, I think that the Qualifiable intent needs to be in the current
>> >>> namespace since I I am not sure and the specs does not mention
>> >>> either,
>> >> on
>> >>> how we could represent a qualified intent whose qualifiable intent
>> >> belongs
>> >>> to a different namespace. So going with the assumption, in this
>> context
>> >> the
>> >>> qualifiable intent needs to be assigned the targetnamspace. Only then
>> >> would
>> >>> it be correctly resolved during the resolution phase.
>> >>>
>> >> Then I don't understand this code:
>> >> PolicyIntentProcessor:74
>> >> qualifiableIntent.setName(getQNameValue(reader,
>> >> policyIntentName.substring(0, qualifierIndex)));
>> >>
>> >> which reads a QName from the XMLStreamReader.
>> >>
>> >> Either (a) the qualifiableIntent is always in the target namespace,
>> >> and
>> >> then it's name is defined as an NCName and we shouldn't be trying to
>> >> read it as a QName, or (b) the qualifiable intent name is actually
>> >> defined as a QName and then it can belong to another namespace.
>> >>
>> >> If I understand it correctly, the policy-xsd defines these names as
>> >> QNames, leading me to believe that (b) is the correct option.
>> >
>> >
>> > Given the context of disussion in this thread (a) seems to be what it
>> should
>> > be. When cleaning up I missed out this line and I will fix it
>> > rightaway
>> > :(. But it ends up working because the name is reset with the
>> > targetnamespace later. Why I say (a) is because we'd then have
>> consistency
>> > with all intent names being NCNames. Ofcourse, this means that the
>> > qualifiable intents should also be from the same namespace.
>> >
>> > If we allowed intent names to be QNames then (b) would apply and we
>> > have
>> the
>> > freedom of having qualifiable intents belonging to a different
>> > namespace
>> > than the targetnamespace. But that will get us back to the bunch of
>> issues
>> > that has been discussed in
>> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28653.html.
>> >
>> > I guess it can't be that qualified intents alone have names that are
>> QNames
>> > and the rest will be NCNames.
>> >
>> > Thanks
>> >
>> > - Venkat
>> >
>>
>> I'm still not sure I understand, I am assuming that when we read XML
>> declarations:
>>
>> - declarations of type <xyz name="anNCName"> get turned into a QName
>> with ns = targetNamespace, localPart = anNCName
>>
>> - declarations of type <xyz refToAnotherElement="QName"> just get the
>> QName as-is, and do not assume that it belongs to the document's
>> targetNamespace.
>>
>> But I'm probably missing something as it also seems to make sense to
>> restrict intent qualifiers to be in the same namespace as their
>> (qualifiable) parent intent.
>>
>> A concrete example would help, could you please post a definitions.xml
>> snippet example here containing a qualifiable intent and qualifiers to
>> help understand what makes more sense? an NCName or QName?
>>
>> 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: Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien,
Here is a snippet from
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy-transaction/src/main/resources/org/apache/tuscany/sca/policy/transaction/definitions.xml
----------------- definitions.xml ---------------------
<definitions xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="
http://www.osoa.org/xmlns/sca/1.0"
xmlns:sca="http://www.osoa.org/xmlns/sca/1.0" xmlns:tuscany="
http://tuscany.apache.org/xmlns/sca/1.0">
<intent name="managedTransaction" constrains="implementation">
<description>Used to indicate the transaction environment desired by
a component implementation.</description>
</intent>
<intent name="managedTransaction.global">
<description>
Used to indicate that a component implementation requires a
managed global transaction.
</description>
</intent>
<intent name="managedTransaction.local">
<description>
Used to indicate that a component implementation requires a
managed local transaction.
</description>
</intent>
..............
-------------------------------------------------------------------------------------------
Over here, the intents "managedTransaction.global" and "
managedTransaction.local" are qualified intents with "managedTransaction"
being the qualifiable intent. Since we have decided that the 'name'
attribute of an 'intent' element is going to be NCName we end up forcing the
qualifiable intent to also belong to the targetnamespace. If it belonged to
namespace other than the target, then we'd have to deal with how we can
represent this for example we could resort to ...
<intent name="tuscany:managedTransaction.global">
<description>
Used to indicate that a component implementation requires a
managed global transaction.
</description>
</intent>
where we could say that managedTransaction is an intent defined under the
namespace that the prefix 'tuscany' points to. But if we did this, the
'name' attribute must be read a QName which ends us in a contradiction.
Thanks
- Venkat
On Thu, Mar 20, 2008 at 2:14 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Venkata Krishnan wrote:
> > Hi Sebastien,
> >
> > Thanks. Please find my comments inline. Not much though :)
> >
> > On Tue, Mar 18, 2008 at 3:46 AM, Jean-Sebastien Delfino <
> > jsdelfino@apache.org> wrote:
> >
> >> Venkata Krishnan wrote:
> >>>> 2) Unless I'm missing something, I don't think that you need to set
> the
> >>>> targetNamespace of QualifiedIntent.qualifiableIntents, as it looks
> like
> >>>> it's already read as a QName from the XML stream (and this QName does
> >>>> not have to be in the current targetNamespace).
> >>>
> >>> First, I think that the Qualifiable intent needs to be in the current
> >>> namespace since I I am not sure and the specs does not mention either,
> >> on
> >>> how we could represent a qualified intent whose qualifiable intent
> >> belongs
> >>> to a different namespace. So going with the assumption, in this
> context
> >> the
> >>> qualifiable intent needs to be assigned the targetnamspace. Only then
> >> would
> >>> it be correctly resolved during the resolution phase.
> >>>
> >> Then I don't understand this code:
> >> PolicyIntentProcessor:74
> >> qualifiableIntent.setName(getQNameValue(reader,
> >> policyIntentName.substring(0, qualifierIndex)));
> >>
> >> which reads a QName from the XMLStreamReader.
> >>
> >> Either (a) the qualifiableIntent is always in the target namespace, and
> >> then it's name is defined as an NCName and we shouldn't be trying to
> >> read it as a QName, or (b) the qualifiable intent name is actually
> >> defined as a QName and then it can belong to another namespace.
> >>
> >> If I understand it correctly, the policy-xsd defines these names as
> >> QNames, leading me to believe that (b) is the correct option.
> >
> >
> > Given the context of disussion in this thread (a) seems to be what it
> should
> > be. When cleaning up I missed out this line and I will fix it rightaway
> > :(. But it ends up working because the name is reset with the
> > targetnamespace later. Why I say (a) is because we'd then have
> consistency
> > with all intent names being NCNames. Ofcourse, this means that the
> > qualifiable intents should also be from the same namespace.
> >
> > If we allowed intent names to be QNames then (b) would apply and we have
> the
> > freedom of having qualifiable intents belonging to a different namespace
> > than the targetnamespace. But that will get us back to the bunch of
> issues
> > that has been discussed in
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28653.html.
> >
> > I guess it can't be that qualified intents alone have names that are
> QNames
> > and the rest will be NCNames.
> >
> > Thanks
> >
> > - Venkat
> >
>
> I'm still not sure I understand, I am assuming that when we read XML
> declarations:
>
> - declarations of type <xyz name="anNCName"> get turned into a QName
> with ns = targetNamespace, localPart = anNCName
>
> - declarations of type <xyz refToAnotherElement="QName"> just get the
> QName as-is, and do not assume that it belongs to the document's
> targetNamespace.
>
> But I'm probably missing something as it also seems to make sense to
> restrict intent qualifiers to be in the same namespace as their
> (qualifiable) parent intent.
>
> A concrete example would help, could you please post a definitions.xml
> snippet example here containing a qualifiable intent and qualifiers to
> help understand what makes more sense? an NCName or QName?
>
> Thanks!
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Hi Sebastien,
>
> Thanks. Please find my comments inline. Not much though :)
>
> On Tue, Mar 18, 2008 at 3:46 AM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Venkata Krishnan wrote:
>>>> 2) Unless I'm missing something, I don't think that you need to set the
>>>> targetNamespace of QualifiedIntent.qualifiableIntents, as it looks like
>>>> it's already read as a QName from the XML stream (and this QName does
>>>> not have to be in the current targetNamespace).
>>>
>>> First, I think that the Qualifiable intent needs to be in the current
>>> namespace since I I am not sure and the specs does not mention either,
>> on
>>> how we could represent a qualified intent whose qualifiable intent
>> belongs
>>> to a different namespace. So going with the assumption, in this context
>> the
>>> qualifiable intent needs to be assigned the targetnamspace. Only then
>> would
>>> it be correctly resolved during the resolution phase.
>>>
>> Then I don't understand this code:
>> PolicyIntentProcessor:74
>> qualifiableIntent.setName(getQNameValue(reader,
>> policyIntentName.substring(0, qualifierIndex)));
>>
>> which reads a QName from the XMLStreamReader.
>>
>> Either (a) the qualifiableIntent is always in the target namespace, and
>> then it's name is defined as an NCName and we shouldn't be trying to
>> read it as a QName, or (b) the qualifiable intent name is actually
>> defined as a QName and then it can belong to another namespace.
>>
>> If I understand it correctly, the policy-xsd defines these names as
>> QNames, leading me to believe that (b) is the correct option.
>
>
> Given the context of disussion in this thread (a) seems to be what it should
> be. When cleaning up I missed out this line and I will fix it rightaway
> :(. But it ends up working because the name is reset with the
> targetnamespace later. Why I say (a) is because we'd then have consistency
> with all intent names being NCNames. Ofcourse, this means that the
> qualifiable intents should also be from the same namespace.
>
> If we allowed intent names to be QNames then (b) would apply and we have the
> freedom of having qualifiable intents belonging to a different namespace
> than the targetnamespace. But that will get us back to the bunch of issues
> that has been discussed in
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28653.html.
>
> I guess it can't be that qualified intents alone have names that are QNames
> and the rest will be NCNames.
>
> Thanks
>
> - Venkat
>
I'm still not sure I understand, I am assuming that when we read XML
declarations:
- declarations of type <xyz name="anNCName"> get turned into a QName
with ns = targetNamespace, localPart = anNCName
- declarations of type <xyz refToAnotherElement="QName"> just get the
QName as-is, and do not assume that it belongs to the document's
targetNamespace.
But I'm probably missing something as it also seems to make sense to
restrict intent qualifiers to be in the same namespace as their
(qualifiable) parent intent.
A concrete example would help, could you please post a definitions.xml
snippet example here containing a qualifiable intent and qualifiers to
help understand what makes more sense? an NCName or QName?
Thanks!
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: About StAXArtifactProcessor
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien,
Thanks. Please find my comments inline. Not much though :)
On Tue, Mar 18, 2008 at 3:46 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Venkata Krishnan wrote:
> >> 2) Unless I'm missing something, I don't think that you need to set the
> >> targetNamespace of QualifiedIntent.qualifiableIntents, as it looks like
> >> it's already read as a QName from the XML stream (and this QName does
> >> not have to be in the current targetNamespace).
> >
> >
> > First, I think that the Qualifiable intent needs to be in the current
> > namespace since I I am not sure and the specs does not mention either,
> on
> > how we could represent a qualified intent whose qualifiable intent
> belongs
> > to a different namespace. So going with the assumption, in this context
> the
> > qualifiable intent needs to be assigned the targetnamspace. Only then
> would
> > it be correctly resolved during the resolution phase.
> >
>
> Then I don't understand this code:
> PolicyIntentProcessor:74
> qualifiableIntent.setName(getQNameValue(reader,
> policyIntentName.substring(0, qualifierIndex)));
>
> which reads a QName from the XMLStreamReader.
>
> Either (a) the qualifiableIntent is always in the target namespace, and
> then it's name is defined as an NCName and we shouldn't be trying to
> read it as a QName, or (b) the qualifiable intent name is actually
> defined as a QName and then it can belong to another namespace.
>
> If I understand it correctly, the policy-xsd defines these names as
> QNames, leading me to believe that (b) is the correct option.
Given the context of disussion in this thread (a) seems to be what it should
be. When cleaning up I missed out this line and I will fix it rightaway
:(. But it ends up working because the name is reset with the
targetnamespace later. Why I say (a) is because we'd then have consistency
with all intent names being NCNames. Ofcourse, this means that the
qualifiable intents should also be from the same namespace.
If we allowed intent names to be QNames then (b) would apply and we have the
freedom of having qualifiable intents belonging to a different namespace
than the targetnamespace. But that will get us back to the bunch of issues
that has been discussed in
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28653.html.
I guess it can't be that qualified intents alone have names that are QNames
and the rest will be NCNames.
Thanks
- Venkat
>
>
> >>
> >> 3) Finally a bigger change: it seems that you have
> StAXArtifactProcessor
> >> extensions for Intent, PolicySet etc... but these elements are not
> >> extensions, so you didn't have to go through all that, as they are part
> >> of the SCA core namespace. So, a much simpler approach would be to just
> >> read them in, directly from SCADefinitionsProcessor. This is similar to
> >> CompositeProcessor for example, if we had made a separate processor for
> >> Component, we would have had to pass a lot of context to it.
> >>
> >> In short, it looks like you've created a maze of processor extensions
> >> for things that didn't have to be extensions, and are now wondering how
> >> to pass context through this maze :)
> >>
> >> The solution is simple, just don't make them extensions :) You can
> >> either move this code to SCADefinitionsProcessor.read() or to private
> >> methods of SCADefinitionsProcessor to which you'll be able to pass
> >> whatever context you need.
> >>
> >> Hope this helps.
> >> --
> >> Jean-Sebastien
> >>
> >
> > This is the the first temptation that I went thro i.e. to merge all of
> this
> > processing into the SCADefinitionsProcessor similar to the
> > CompositeProcessor. We did start with all of this in a single module
> but
> > somewhere down the line we decided to split them all into different
> modules
> > (can't quite remember and pull up that discussion around this). Ok, let
> me
> > get them back together for now.
> >
> > However, I am not sure how far we could go with this. You will agree
> that
> > the 'read' and 'resolve' methods of the CompositeProcessor are quite
> bulky
> > running to pages and contains quite a bit of state management.
> >
>
> I'm not saying that you need to do all the processing in a single method
> :), you can split it multiple methods if you like, but these methods can
> be private methods, do not have to belong to the StAXArtifactProcessor
> interface, and can take whatever context you want to pass to them.
>
> We just need to find the right balance between bulky methods and a maze
> of small methods calling each other :)
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: About StAXArtifactProcessor
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
>> 2) Unless I'm missing something, I don't think that you need to set the
>> targetNamespace of QualifiedIntent.qualifiableIntents, as it looks like
>> it's already read as a QName from the XML stream (and this QName does
>> not have to be in the current targetNamespace).
>
>
> First, I think that the Qualifiable intent needs to be in the current
> namespace since I I am not sure and the specs does not mention either, on
> how we could represent a qualified intent whose qualifiable intent belongs
> to a different namespace. So going with the assumption, in this context the
> qualifiable intent needs to be assigned the targetnamspace. Only then would
> it be correctly resolved during the resolution phase.
>
Then I don't understand this code:
PolicyIntentProcessor:74
qualifiableIntent.setName(getQNameValue(reader,
policyIntentName.substring(0, qualifierIndex)));
which reads a QName from the XMLStreamReader.
Either (a) the qualifiableIntent is always in the target namespace, and
then it's name is defined as an NCName and we shouldn't be trying to
read it as a QName, or (b) the qualifiable intent name is actually
defined as a QName and then it can belong to another namespace.
If I understand it correctly, the policy-xsd defines these names as
QNames, leading me to believe that (b) is the correct option.
>>
>> 3) Finally a bigger change: it seems that you have StAXArtifactProcessor
>> extensions for Intent, PolicySet etc... but these elements are not
>> extensions, so you didn't have to go through all that, as they are part
>> of the SCA core namespace. So, a much simpler approach would be to just
>> read them in, directly from SCADefinitionsProcessor. This is similar to
>> CompositeProcessor for example, if we had made a separate processor for
>> Component, we would have had to pass a lot of context to it.
>>
>> In short, it looks like you've created a maze of processor extensions
>> for things that didn't have to be extensions, and are now wondering how
>> to pass context through this maze :)
>>
>> The solution is simple, just don't make them extensions :) You can
>> either move this code to SCADefinitionsProcessor.read() or to private
>> methods of SCADefinitionsProcessor to which you'll be able to pass
>> whatever context you need.
>>
>> Hope this helps.
>> --
>> Jean-Sebastien
>>
>
> This is the the first temptation that I went thro i.e. to merge all of this
> processing into the SCADefinitionsProcessor similar to the
> CompositeProcessor. We did start with all of this in a single module but
> somewhere down the line we decided to split them all into different modules
> (can't quite remember and pull up that discussion around this). Ok, let me
> get them back together for now.
>
> However, I am not sure how far we could go with this. You will agree that
> the 'read' and 'resolve' methods of the CompositeProcessor are quite bulky
> running to pages and contains quite a bit of state management.
>
I'm not saying that you need to do all the processing in a single method
:), you can split it multiple methods if you like, but these methods can
be private methods, do not have to belong to the StAXArtifactProcessor
interface, and can take whatever context you want to pass to them.
We just need to find the right balance between bulky methods and a maze
of small methods calling each other :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: About StAXArtifactProcessor
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien
Please see my comments inline. Thanks.
- Venkat
On Fri, Mar 14, 2008 at 1:07 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Venkata Krishnan wrote:
> I set up the targetnamespace for the names of
> > Intents and PolicySets in the SCADefnsProcessor after an Intent or
> PolicySet
> > has been read by a downstream processor.
>
> Given how the policy code is currently organized that seems the simplest
> option: SCADefinitionsProcessor is responsible for handling the
> targetNamespace, and setting it in the qnames of the policy intents and
> policySets that it adds to its lists of policy intents and policySets.
>
> This could be much simplified though, with the following changes:
>
> 1) cosmetic but it'll help make that code more readable, change
>
> if (extension != null) {
> if ( extension instanceof Intent ) {
> ((Intent)extension).setName(new QName(targetNamespace,
>
> ((Intent)extension).getName().getLocalPart()));
>
> to
>
> if (extension instanceof Intent ) {
> Intent intent = (Intent)extension;
> intent.setName(new QName(targetNamespace,
> intent.getName().getLocalPart()));
>
> as the double 'if' is not necessary, and a local variable will help
> avoid repeating the casts.
>
Yes :) this if looks really crazy now that I am looking back at it. Will
correct it.
>
> 2) Unless I'm missing something, I don't think that you need to set the
> targetNamespace of QualifiedIntent.qualifiableIntents, as it looks like
> it's already read as a QName from the XML stream (and this QName does
> not have to be in the current targetNamespace).
First, I think that the Qualifiable intent needs to be in the current
namespace since I I am not sure and the specs does not mention either, on
how we could represent a qualified intent whose qualifiable intent belongs
to a different namespace. So going with the assumption, in this context the
qualifiable intent needs to be assigned the targetnamspace. Only then would
it be correctly resolved during the resolution phase.
>
>
> 3) Finally a bigger change: it seems that you have StAXArtifactProcessor
> extensions for Intent, PolicySet etc... but these elements are not
> extensions, so you didn't have to go through all that, as they are part
> of the SCA core namespace. So, a much simpler approach would be to just
> read them in, directly from SCADefinitionsProcessor. This is similar to
> CompositeProcessor for example, if we had made a separate processor for
> Component, we would have had to pass a lot of context to it.
>
> In short, it looks like you've created a maze of processor extensions
> for things that didn't have to be extensions, and are now wondering how
> to pass context through this maze :)
>
> The solution is simple, just don't make them extensions :) You can
> either move this code to SCADefinitionsProcessor.read() or to private
> methods of SCADefinitionsProcessor to which you'll be able to pass
> whatever context you need.
>
> Hope this helps.
> --
> Jean-Sebastien
>
This is the the first temptation that I went thro i.e. to merge all of this
processing into the SCADefinitionsProcessor similar to the
CompositeProcessor. We did start with all of this in a single module but
somewhere down the line we decided to split them all into different modules
(can't quite remember and pull up that discussion around this). Ok, let me
get them back together for now.
However, I am not sure how far we could go with this. You will agree that
the 'read' and 'resolve' methods of the CompositeProcessor are quite bulky
running to pages and contains quite a bit of state management.
- Venkat
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: About StAXArtifactProcessor
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Mar 13, 2008 at 12:37 PM, Jean-Sebastien Delfino
<js...@apache.org> wrote:
> Venkata Krishnan wrote:
> I set up the targetnamespace for the names of
> > Intents and PolicySets in the SCADefnsProcessor after an Intent or PolicySet
> > has been read by a downstream processor.
>
> Given how the policy code is currently organized that seems the simplest
> option: SCADefinitionsProcessor is responsible for handling the
> targetNamespace, and setting it in the qnames of the policy intents and
> policySets that it adds to its lists of policy intents and policySets.
>
> This could be much simplified though, with the following changes:
>
> 1) cosmetic but it'll help make that code more readable, change
>
> if (extension != null) {
> if ( extension instanceof Intent ) {
> ((Intent)extension).setName(new QName(targetNamespace,
>
> ((Intent)extension).getName().getLocalPart()));
>
> to
>
> if (extension instanceof Intent ) {
> Intent intent = (Intent)extension;
> intent.setName(new QName(targetNamespace,
> intent.getName().getLocalPart()));
>
> as the double 'if' is not necessary, and a local variable will help
> avoid repeating the casts.
>
> 2) Unless I'm missing something, I don't think that you need to set the
> targetNamespace of QualifiedIntent.qualifiableIntents, as it looks like
> it's already read as a QName from the XML stream (and this QName does
> not have to be in the current targetNamespace).
>
> 3) Finally a bigger change: it seems that you have StAXArtifactProcessor
> extensions for Intent, PolicySet etc... but these elements are not
> extensions, so you didn't have to go through all that, as they are part
> of the SCA core namespace. So, a much simpler approach would be to just
> read them in, directly from SCADefinitionsProcessor. This is similar to
> CompositeProcessor for example, if we had made a separate processor for
> Component, we would have had to pass a lot of context to it.
>
> In short, it looks like you've created a maze of processor extensions
> for things that didn't have to be extensions, and are now wondering how
> to pass context through this maze :)
>
> The solution is simple, just don't make them extensions :) You can
> either move this code to SCADefinitionsProcessor.read() or to private
> methods of SCADefinitionsProcessor to which you'll be able to pass
> whatever context you need.
>
+1, I started looking into this approach, but didn't have time to
finish the changes.
Venkat, if you still need help, I can probably get something on this
path by early next week, otherwise, please feel free to do it :)
> Hope this helps.
> --
> 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
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: About StAXArtifactProcessor
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
I set up the targetnamespace for the names of
> Intents and PolicySets in the SCADefnsProcessor after an Intent or PolicySet
> has been read by a downstream processor.
Given how the policy code is currently organized that seems the simplest
option: SCADefinitionsProcessor is responsible for handling the
targetNamespace, and setting it in the qnames of the policy intents and
policySets that it adds to its lists of policy intents and policySets.
This could be much simplified though, with the following changes:
1) cosmetic but it'll help make that code more readable, change
if (extension != null) {
if ( extension instanceof Intent ) {
((Intent)extension).setName(new QName(targetNamespace,
((Intent)extension).getName().getLocalPart()));
to
if (extension instanceof Intent ) {
Intent intent = (Intent)extension;
intent.setName(new QName(targetNamespace,
intent.getName().getLocalPart()));
as the double 'if' is not necessary, and a local variable will help
avoid repeating the casts.
2) Unless I'm missing something, I don't think that you need to set the
targetNamespace of QualifiedIntent.qualifiableIntents, as it looks like
it's already read as a QName from the XML stream (and this QName does
not have to be in the current targetNamespace).
3) Finally a bigger change: it seems that you have StAXArtifactProcessor
extensions for Intent, PolicySet etc... but these elements are not
extensions, so you didn't have to go through all that, as they are part
of the SCA core namespace. So, a much simpler approach would be to just
read them in, directly from SCADefinitionsProcessor. This is similar to
CompositeProcessor for example, if we had made a separate processor for
Component, we would have had to pass a lot of context to it.
In short, it looks like you've created a maze of processor extensions
for things that didn't have to be extensions, and are now wondering how
to pass context through this maze :)
The solution is simple, just don't make them extensions :) You can
either move this code to SCADefinitionsProcessor.read() or to private
methods of SCADefinitionsProcessor to which you'll be able to pass
whatever context you need.
Hope this helps.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: About StAXArtifactProcessor
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Luciano,
Here is what I am facing...
- The targetnamespace attribute is a part of the sca:definitions element and
that is read by the SCADefnProcessor.
- For subsequent elements such as Intents and Policysets in the
definitions.xml, the SCADefnsProcessor delegates to the extension processor
which inturn ends up calling the IntentProcessor (to process Intents) or the
PolicySetProcessor (to process PolicySets). But it happens that the Intents
and PolicySets should inherit the 'targetnmaespace' so that its made to be a
part of their name. So it seems like it would have been good for the
SCADefnsProcessor to pass this value down.
Since this is not possible, I set up the targetnamespace for the names of
Intents and PolicySets in the SCADefnsProcessor after an Intent or PolicySet
has been read by a downstream processor. I am not so comfortable with this.
Does that give you some picture ?
Thanks
- Venkat
On Tue, Mar 11, 2008 at 6:32 AM, Luciano Resende <lu...@gmail.com>
wrote:
> Maybe you could describe a little more what is the issue you are
> having, and we could try helping finding another solution for your
> issue, particularly related to targetNamespace, as it might be
> available trough the parser API. Also, I usually try to avoid context
> objects, as they usually grow out of control very fast causing various
> side effects.
>
>
> On Mon, Mar 10, 2008 at 10:39 AM, Luciano Resende <lu...@gmail.com>
> wrote:
> > I was going to take a quick look at this, but before I do, let me ask
> > if svn revision #635604 is related to the issue you are asking here.
> >
> >
> >
> > On Mon, Mar 10, 2008 at 2:40 AM, Venkata Krishnan <
> for.svkrish@gmail.com> wrote:
> > > Hi,
> > >
> > > I recently faced a situation where I wished to passed some context
> from one
> > > StAXArtifact Processor to others down the chain. More specifically,
> to get
> > > the 'targetNamespace' of the definitions.xml file apply to
> PoliyIntent and
> > > PolicySet names, I wished to pass the 'targetNamespace' value from
> the
> > > Definitions Processor (which is where it is read) down to the
> PolicyIntent
> > > and PolicySet processors. I could not figure out a way to do this.
> Am I
> > > missing something here or would it make sense to add an argument
> named
> > > 'context' to the read methods of our StAXProcessor ? I guess there
> could be
> > > other situations when we might need some information from parent
> element to
> > > be passed down.
> > >
> > > Thoughts ?
> > >
> > > Thanks
> > >
> > > - Venkat
> > >
> >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
> > http://lresende.blogspot.com/
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: About StAXArtifactProcessor
Posted by Luciano Resende <lu...@gmail.com>.
Maybe you could describe a little more what is the issue you are
having, and we could try helping finding another solution for your
issue, particularly related to targetNamespace, as it might be
available trough the parser API. Also, I usually try to avoid context
objects, as they usually grow out of control very fast causing various
side effects.
On Mon, Mar 10, 2008 at 10:39 AM, Luciano Resende <lu...@gmail.com> wrote:
> I was going to take a quick look at this, but before I do, let me ask
> if svn revision #635604 is related to the issue you are asking here.
>
>
>
> On Mon, Mar 10, 2008 at 2:40 AM, Venkata Krishnan <fo...@gmail.com> wrote:
> > Hi,
> >
> > I recently faced a situation where I wished to passed some context from one
> > StAXArtifact Processor to others down the chain. More specifically, to get
> > the 'targetNamespace' of the definitions.xml file apply to PoliyIntent and
> > PolicySet names, I wished to pass the 'targetNamespace' value from the
> > Definitions Processor (which is where it is read) down to the PolicyIntent
> > and PolicySet processors. I could not figure out a way to do this. Am I
> > missing something here or would it make sense to add an argument named
> > 'context' to the read methods of our StAXProcessor ? I guess there could be
> > other situations when we might need some information from parent element to
> > be passed down.
> >
> > Thoughts ?
> >
> > Thanks
> >
> > - Venkat
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: About StAXArtifactProcessor
Posted by Luciano Resende <lu...@gmail.com>.
I was going to take a quick look at this, but before I do, let me ask
if svn revision #635604 is related to the issue you are asking here.
On Mon, Mar 10, 2008 at 2:40 AM, Venkata Krishnan <fo...@gmail.com> wrote:
> Hi,
>
> I recently faced a situation where I wished to passed some context from one
> StAXArtifact Processor to others down the chain. More specifically, to get
> the 'targetNamespace' of the definitions.xml file apply to PoliyIntent and
> PolicySet names, I wished to pass the 'targetNamespace' value from the
> Definitions Processor (which is where it is read) down to the PolicyIntent
> and PolicySet processors. I could not figure out a way to do this. Am I
> missing something here or would it make sense to add an argument named
> 'context' to the read methods of our StAXProcessor ? I guess there could be
> other situations when we might need some information from parent element to
> be passed down.
>
> Thoughts ?
>
> Thanks
>
> - Venkat
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org