from:"Greg Dritschler"

Problems in BaseStAXArtifactProcessor with writing prefixes

2008-05-25 Thread Greg Dritschler

I have some questions about the processing in BaseStAXArtifactProcessor to
write namespace prefixes.  Let's start with this method:

protected void writeStart(XMLStreamWriter writer, String uri, String
name, XAttr... attrs) throws XMLStreamException {
String prefix = writeElementPrefix(writer, uri);
writeAttributePrefixes(writer, attrs);
writer.writeStartElement(uri, name);

if (prefix != null){
writer.writeNamespace(prefix,uri);
}
writeAttributes(writer, attrs);
}

writeAttributePrefixes calls down to XAttr.writePrefix.  If the value is a
QName then it calls writeQNamePrefix.

private void writeQNamePrefix(XMLStreamWriter writer, QName qname)
throws XMLStreamException {
if (qname != null) {
String prefix = qname.getPrefix();
String uri = qname.getNamespaceURI();
prefix = writer.getPrefix(uri);
if (prefix != null) {
return;
} else {

// Find an available prefix and bind it to the given URI

NamespaceContext nsc = writer.getNamespaceContext();
for (int i=1; ; i++) {
prefix = ns + i;
if (nsc.getNamespaceURI(prefix) == null) {
break;
}
}
writer.setPrefix(prefix, uri);
}
}
}

If the QName has a uri which isn't yet bound to a prefix, this method binds
it.  Note that it does not write the namespace to the stream, nor does it
return anything to its caller to tell it to write the namespace.  So the
resulting XML has an unbound prefix.  writeQNamePrefix cannot write the
namespace itself because it is being called before the element has been
started.  I think the processing needs to be changed to bubble up the prefix
bindings back to writeStart, and then writeStart can write them.

PolicyAttachPointProcessor.writePolicyPrefixes also goes through this code,
so it would also have to be changed to return the prefix bindings to its
callers (ConfiguredOperationProcessor, JavaImplementationProcessor).

I gather that the reason the code is arranged this way is to minimize the
number of prefixes generated by binding the prefix in the parent's element
rather than the element we are about to write?  Otherwise writeQNameValue
could just write the namespace at the time the attribute value is being
written.

Speaking of writeQName value, I have a question about it too.

private String writeQNameValue(XMLStreamWriter writer, QName qname)
throws XMLStreamException {
if (qname != null) {
String prefix = qname.getPrefix();
String uri = qname.getNamespaceURI();
prefix = writer.getPrefix(uri);
if (prefix != null  prefix.length()  0) {

// Use the prefix already bound to the given URI
return prefix + : + qname.getLocalPart();
} else {

// Find an available prefix and bind it to the given URI

NamespaceContext nsc = writer.getNamespaceContext();
for (int i=1; ; i++) {
prefix = ns + i;
if (nsc.getNamespaceURI(prefix) == null) {
break;
}
}
writer.setPrefix(prefix, uri);
writer.writeNamespace(prefix, uri);
return prefix + : + qname.getLocalPart();
}
} else {
return null;
}
}

I am wondering about the check for prefix.length()  0.  The documentation
for getPrefix() is sketchy, but it seems to return the empty string if the
given namespace is the default namespace.  So this code generates a new
prefix when the QName value uses the default namespace.  Why does it do
that?  I think if getPrefix returns a non-null value of zero length, this
method should return the local part of the QName with no prefix.

Greg Dritschler

Re: Authentication Authorization across wsBinding java Implementation - was : Using security policies in the Bigbank scenario

2008-04-23 Thread Greg Dritschler

I don't know whether the POLICY-26 proposal has been accepted.  I think
POLICY-26 is a bit clearer in conveying the meaning of the different choices
than Venkat's proposal.

While POLICY-26 fixes the schema so that conflicting authorization elements
cannot be specified within a policy set, it does not address what should
happen when authorization policy is inherited across levels.  The framework
says policy sets are additive and clearly this can result in conflicts.  I
guess one could say that this is an error in the composite.  However that
limits the use of inheritance for this type of policy because then one can't
establish a default policy for the composite and override for particular
components.

On Mon, Apr 21, 2008 at 7:30 PM, Raymond Feng [EMAIL PROTECTED] wrote:

 Hi,

 I assume you are implementing the syntax in OSOA SCA spec 1.0. Do we know
 if http://www.osoa.org/jira/browse/POLICY-26 is an officially accepted
 proposal?

 Thanks,
 Raymond
 --
 From: Venkata Krishnan [EMAIL PROTECTED]
 Sent: Monday, April 21, 2008 12:20 AM
 To: tuscany-dev@ws.apache.org
 Subject: Re: Authentication  Authorization across wsBinding  java
 Implementation - was : Using security policies in the Bigbank scenario


  Hi,
 
  With r650032, I have committed some simple additions to support the
  model
  and StaX processor for the bunch of policy assertions specified in
  section
  1.7.3-Implementation-Security-Policy of the PolicyFwk Specs.
 
  I'd wish to optimize this a bit and cut down on some classes in the
  future.
  As a start for this here is a question related to the specs and hope
  somebody is able to help me with some clarity...
 
  - Do we need three assertions viz. permitAll, denyAll, allow.  Why not
  just
  the one as follows: -
allow roles=listOfNCNames  permitAll=xs:boolean/
 
  So if permitAll is 'true' then all roles is permitted.  If it is false
  then
  only those roles in the 'roles' attribute is permitted.   If it is false
  and
  there aren't any roles specified then it is equivalent to 'denyAll'.
 
  Thanks
 
  - Venkat
 
  On Thu, Mar 6, 2008 at 11:43 PM, Greg Dritschler 
  [EMAIL PROTECTED]
  wrote:
 
   Ok.  Please be aware there is an errata associated with the
   authorization
   elements.
http://www.osoa.org/jira/browse/POLICY-26
  
   On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan 
   [EMAIL PROTECTED]
   wrote:
  
+1.  I will start looking into this after I am done with some
half-finished
things on my plate at the moment.  Thanks.
   
- Venkat
   
On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino 
[EMAIL PROTECTED] wrote:
   
 Greg Dritschler wrote:
  Is the authentication policy going to bear any resemblance to
   the
policy
  described in section 1.7.3.1 of the Policy spec, or is it   
   completely
  different?
 
  Greg
 

 I think that Tuscany should implement the authorization - I guess
   that's
 what you meant :) - and security identity policies as described in
 section 1.7.3.1 of the Policy spec, at least.

 We could start with just implementing the model and XML reading
   for
   the
 elements described in 1.7.3.1 and let the various component
 implementation extensions handle them (or not) in their own way,
   but
 having the model and XML processors would be a good start IMO.

 Any thoughts?
 --
 Jean-Sebastien


   -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


   
  
  
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Created: (TUSCANY-2239) Support for mutually-exclusive intents

2008-04-20 Thread Greg Dritschler

The patch validates the final list of intents collected into the binding or
implementation does not contain exclusive intents.  I suppose you could do
validation calls at other levels to better pinpoint the source of the error.

Greg

On Sat, Apr 19, 2008 at 7:37 AM, Venkata Krishnan [EMAIL PROTECTED]
wrote:

 Hi,

 With specific reference to the inheritance of intents and policysets
 across
 the SCDL-XML hierarchy i.e. the one by which child elements inherit that
 which is specified in the parent element I have a question as follows :-

 Do we need to bother about the validity of what a child element actually
 inherits UNLESS its a binding or implementation element ?  For example how
 very important is it to worry about validating for Mutually exclusive
 intents at a 'reference' element.

 I am wondering if I could just about aggregate all intents and policysets
 upto the immediate parent of a binding or implementation element.  Then at
 this point, when the binding or implementation is about to inherit, I
 would
 apply validations related to checks for mutually exclusive intents.

 I am thinking on these lines because it seems to me that the binding and
 implementation elements are where intents and policyset actually matter.
  If
 specified in any other levle its only for convenience so as to cover a
 whole
 bunch of child elements.

 Am I trying to overly simply things here missing some key point ?

 Thanks

 - Venkat


 On Fri, Apr 18, 2008 at 7:08 PM, Greg Dritschler 
 [EMAIL PROTECTED]
 wrote:

  Thanks Mike.  As you know I relied on these 2 JIRAs to compose a
 solution.
  With respect to POLICY-39, I didn't implement some of the features like
  wildcarding of qualifiers or not requiring reciprocal exclusions in the
  interest of getting the basics done and into the code base.  These
  features
  could be added later if someone has an interest in them.
 
  On Thu, Apr 17, 2008 at 9:54 AM, Mike Edwards 
  [EMAIL PROTECTED] wrote:
 
   Greg Dritschler (JIRA) wrote:
  
Support for mutually-exclusive intents
--
   
Key: TUSCANY-2239
URL:
  https://issues.apache.org/jira/browse/TUSCANY-2239
Project: Tuscany
 Issue Type: New Feature
 Components: Java SCA Core Runtime
   Reporter: Greg Dritschler
   
   
The SCA Policy specification does not provide a means to define
  intents
which are mutually exclusive.  This is a noticeable omission when
considering the intents in the SCA Transaction specification which
 are
mutually exclusive by nature (managedTransaction vs.
  noManagedTransaction,
propagatesTransaction vs. suspendsTransaction).   There is a need to
  be able
to define intents which are mutually exclusive and for the exclusion
  to be
checked by the SCA runtime to avoid the error of specifying
 exclusive
intents on a single artifact.  In addition, there should be rules
  defined
for the handling of mutually exclusive intents which are attached at
different levels of a composite or a hierarchy of composites.
   
I have attached a patch to provide the capability to define mutually
exclusive intents.  This is achieved using a new @excludes attribute
  on the
intent/ element in definitions.xml.  For example:
   
   intent name=propagatesTransaction constrains=implementation
excludes=suspendsTransaction/
   
@excludes is a list of intents which are mutually-exclusive with the
named intent.  In order to be effective, a reciprocal definition
 needs
  to be
made as shown below.
   
 intent name=suspendsTransaction constrains=implementation
excludes=propagatesTransaction/
   
The patch makes no assumptions about the relationship of qualified
intents to the base intent.  Therefore exclusive relationships
 between
qualified intents need to be spelled out.
   
 intent name=noManagedTransaction constrains=implementation
   excludes=managedTransaction managedTransaction.global
managedTransaction.local/
   
A key part of the patch is that there now are two types of intent
inheritance with respect to exclusive intents.  There is a default
inheritance between certain hierarchical elements within a
 composite.
   For
example consider this snippet from a composite:
   
   component name=C1 requires=propagatesTransaction
   reference name=r1/
   reference name=r2/
   reference name=r3 requires=suspendsTransaction/
   /component
   
In this case the first two references inherit the default intent
propagatesTransaction from the component element.  However the
 third
reference does not inherit it because it specifies an exclusive
 intent
suspendsTransaction which overrides the component-level default.
   
The second type of inheritance is used when inheriting intents from
 an
implementation (e.g

[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive intents

2008-04-20 Thread Greg Dritschler (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Greg Dritschler updated TUSCANY-2239:
-

Attachment: tuscany-2239-CompositeWireBuilder.patch

Support for mutually-exclusive intents
--

Key: TUSCANY-2239
URL: https://issues.apache.org/jira/browse/TUSCANY-2239
Project: Tuscany
Issue Type: New Feature
Components: Java SCA Core Runtime
Reporter: Greg Dritschler
Assignee: Venkatakrishnan
Attachments: tuscany-2239-CompositeWireBuilder.patch,
tuscany-2239.patch

The SCA Policy specification does not provide a means to define intents which
are mutually exclusive. This is a noticeable omission when considering the
intents in the SCA Transaction specification which are mutually exclusive by
nature (managedTransaction vs. noManagedTransaction, propagatesTransaction
vs. suspendsTransaction). There is a need to be able to define intents
which are mutually exclusive and for the exclusion to be checked by the SCA
runtime to avoid the error of specifying exclusive intents on a single
artifact. In addition, there should be rules defined for the handling of
mutually exclusive intents which are attached at different levels of a
composite or a hierarchy of composites.
I have attached a patch to provide the capability to define mutually
exclusive intents. This is achieved using a new @excludes attribute on the
intent/ element in definitions.xml. For example:
intent name=propagatesTransaction constrains=implementation
excludes=suspendsTransaction/
@excludes is a list of intents which are mutually-exclusive with the named
intent. In order to be effective, a reciprocal definition needs to be made
as shown below.
intent name=suspendsTransaction constrains=implementation
excludes=propagatesTransaction/
The patch makes no assumptions about the relationship of qualified intents to
the base intent. Therefore exclusive relationships between qualified intents
need to be spelled out.
intent name=noManagedTransaction constrains=implementation
excludes=managedTransaction managedTransaction.global
managedTransaction.local/
A key part of the patch is that there now are two types of intent inheritance
with respect to exclusive intents. There is a default inheritance between
certain hierarchical elements within a composite. For example consider this
snippet from a composite:
component name=C1 requires=propagatesTransaction
reference name=r1/
reference name=r2/
reference name=r3 requires=suspendsTransaction/
/component
In this case the first two references inherit the default intent
propagatesTransaction from the component element. However the third
reference does not inherit it because it specifies an exclusive intent
suspendsTransaction which overrides the component-level default.
The second type of inheritance is used when inheriting intents from an
implementation (e.g. introspected Java code, or an implementation composite).
In this case the intents of the implementation cannot be overridden.
Consider this example:
component name=D1
implementation.composite name=CZ1/
reference name=r1 requires=suspendsTransaction/
/component
Let's assume CZ1 contains the component C1 shown earlier and that it promotes
the component reference C1/r1 as r1. C1/r1 has the intent
propagatesTransaction. This intent is considered a requirement of the
implementation and it cannot be overridden by the using composite. Therefore
D1 is in error.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive intents

2008-04-20 Thread Greg Dritschler (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Greg Dritschler updated TUSCANY-2239:
-

Attachment: (was: tuscany-2239-CompositeWireBuilder.patch)

Support for mutually-exclusive intents
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive intents

2008-04-20 Thread Greg Dritschler (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Greg Dritschler updated TUSCANY-2239:
-

Attachment: tuscany-2239-CompositeWireBuilder.patch

Support for mutually-exclusive intents
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2239) Support for mutually-exclusive intents

2008-04-20 Thread Greg Dritschler (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590785#action_12590785
]

Greg Dritschler commented on TUSCANY-2239:
--

I have attached a new patch for CompositeWireBuilderImpl.

Support for mutually-exclusive intents
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2246) Update DefaultContextFactoryExtensionPoint to use ServiceDiscovery

2008-04-20 Thread Greg Dritschler (JIRA)

Update DefaultContextFactoryExtensionPoint to use ServiceDiscovery
--

 Key: TUSCANY-2246
 URL: https://issues.apache.org/jira/browse/TUSCANY-2246
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
Reporter: Greg Dritschler


Change DefaultContextFactoryExtensionPoint to use ServiceDiscovery to find 
implementation of context factory.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-2246) Update DefaultContextFactoryExtensionPoint to use ServiceDiscovery

2008-04-20 Thread Greg Dritschler (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Dritschler updated TUSCANY-2246:
-

Attachment: tuscany-2246.patch

 Update DefaultContextFactoryExtensionPoint to use ServiceDiscovery
 --

 Key: TUSCANY-2246
 URL: https://issues.apache.org/jira/browse/TUSCANY-2246
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
Reporter: Greg Dritschler
 Attachments: tuscany-2246.patch


 Change DefaultContextFactoryExtensionPoint to use ServiceDiscovery to find 
 implementation of context factory.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Created: (TUSCANY-2239) Support for mutually-exclusive intents

2008-04-18 Thread Greg Dritschler

Thanks Mike.  As you know I relied on these 2 JIRAs to compose a solution.
With respect to POLICY-39, I didn't implement some of the features like
wildcarding of qualifiers or not requiring reciprocal exclusions in the
interest of getting the basics done and into the code base.  These features
could be added later if someone has an interest in them.

On Thu, Apr 17, 2008 at 9:54 AM, Mike Edwards 
[EMAIL PROTECTED] wrote:

 Greg Dritschler (JIRA) wrote:

  Support for mutually-exclusive intents
  --
 
  Key: TUSCANY-2239
  URL: https://issues.apache.org/jira/browse/TUSCANY-2239
  Project: Tuscany
   Issue Type: New Feature
   Components: Java SCA Core Runtime
 Reporter: Greg Dritschler
 
 
  The SCA Policy specification does not provide a means to define intents
  which are mutually exclusive.  This is a noticeable omission when
  considering the intents in the SCA Transaction specification which are
  mutually exclusive by nature (managedTransaction vs. noManagedTransaction,
  propagatesTransaction vs. suspendsTransaction).   There is a need to be able
  to define intents which are mutually exclusive and for the exclusion to be
  checked by the SCA runtime to avoid the error of specifying exclusive
  intents on a single artifact.  In addition, there should be rules defined
  for the handling of mutually exclusive intents which are attached at
  different levels of a composite or a hierarchy of composites.
 
  I have attached a patch to provide the capability to define mutually
  exclusive intents.  This is achieved using a new @excludes attribute on the
  intent/ element in definitions.xml.  For example:
 
 intent name=propagatesTransaction constrains=implementation
  excludes=suspendsTransaction/
 
  @excludes is a list of intents which are mutually-exclusive with the
  named intent.  In order to be effective, a reciprocal definition needs to be
  made as shown below.
 
   intent name=suspendsTransaction constrains=implementation
  excludes=propagatesTransaction/
 
  The patch makes no assumptions about the relationship of qualified
  intents to the base intent.  Therefore exclusive relationships between
  qualified intents need to be spelled out.
 
   intent name=noManagedTransaction constrains=implementation
 excludes=managedTransaction managedTransaction.global
  managedTransaction.local/
 
  A key part of the patch is that there now are two types of intent
  inheritance with respect to exclusive intents.  There is a default
  inheritance between certain hierarchical elements within a composite.  For
  example consider this snippet from a composite:
 
 component name=C1 requires=propagatesTransaction
 reference name=r1/
 reference name=r2/
 reference name=r3 requires=suspendsTransaction/
 /component
 
  In this case the first two references inherit the default intent
  propagatesTransaction from the component element.  However the third
  reference does not inherit it because it specifies an exclusive intent
  suspendsTransaction which overrides the component-level default.
 
  The second type of inheritance is used when inheriting intents from an
  implementation (e.g. introspected Java code, or an implementation
  composite).  In this case the intents of the implementation cannot be
  overridden.  Consider this example:
 
 component name=D1
 implementation.composite name=CZ1/
 reference name=r1 requires=suspendsTransaction/
 /component
 
  Let's assume CZ1 contains the component C1 shown earlier and that it
  promotes the component reference C1/r1 as r1.  C1/r1 has the intent
  propagatesTransaction.  This intent is considered a requirement of the
  implementation and it cannot be overridden by the using composite.
   Therefore D1 is in error.
 
   Folks,

 I would like to make everyone aware that the OASIS Policy TC have been
 working on the topic of mutually exclusive intents and there is both a
 formal Issue and an agreed resolution to that issue.

 The related topic of inheritance of intents has also received the same
 treatment!

 The issues concerned are:

 a) Issue 39 Need Support for Mutually exclusive intents
 http://www.osoa.org/jira/browse/POLICY-39

 The agreed resolution is on the page linked above.
 It is very close to the solution expressed above, but it does deal with
 qualified intents in detail.

 b) Issue 38 Improve description of the overides available to the two
 different hierarchies in SCA
 http://www.osoa.org/jira/browse/POLICY-38

 This is a comprehensive description of how intents are inherited by a
 given element in SCA - both from the surrounding SCDL and also from any
 implementations that are being used.

 The full resolution text is attached to the following email:
 http://lists.oasis-open.org/archives/sca-policy/200804/msg00018.html

 ...this is actually a complete updated version

[jira] Created: (TUSCANY-2239) Support for mutually-exclusive intents

2008-04-16 Thread Greg Dritschler (JIRA)

Support for mutually-exclusive intents
--

 Key: TUSCANY-2239
 URL: https://issues.apache.org/jira/browse/TUSCANY-2239
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Core Runtime
Reporter: Greg Dritschler


The SCA Policy specification does not provide a means to define intents which 
are mutually exclusive.  This is a noticeable omission when considering the 
intents in the SCA Transaction specification which are mutually exclusive by 
nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. 
suspendsTransaction).   There is a need to be able to define intents which are 
mutually exclusive and for the exclusion to be checked by the SCA runtime to 
avoid the error of specifying exclusive intents on a single artifact.  In 
addition, there should be rules defined for the handling of mutually exclusive 
intents which are attached at different levels of a composite or a hierarchy of 
composites.

I have attached a patch to provide the capability to define mutually exclusive 
intents.  This is achieved using a new @excludes attribute on the intent/ 
element in definitions.xml.  For example:

intent name=propagatesTransaction constrains=implementation 
excludes=suspendsTransaction/

@excludes is a list of intents which are mutually-exclusive with the named 
intent.  In order to be effective, a reciprocal definition needs to be made as 
shown below.

  intent name=suspendsTransaction constrains=implementation 
excludes=propagatesTransaction/

The patch makes no assumptions about the relationship of qualified intents to 
the base intent.  Therefore exclusive relationships between qualified intents 
need to be spelled out.

  intent name=noManagedTransaction constrains=implementation
excludes=managedTransaction managedTransaction.global 
managedTransaction.local/

A key part of the patch is that there now are two types of intent inheritance 
with respect to exclusive intents.  There is a default inheritance between 
certain hierarchical elements within a composite.  For example consider this 
snippet from a composite:

component name=C1 requires=propagatesTransaction
reference name=r1/
reference name=r2/
reference name=r3 requires=suspendsTransaction/
/component

In this case the first two references inherit the default intent 
propagatesTransaction from the component element.  However the third 
reference does not inherit it because it specifies an exclusive intent 
suspendsTransaction which overrides the component-level default.

The second type of inheritance is used when inheriting intents from an 
implementation (e.g. introspected Java code, or an implementation composite).  
In this case the intents of the implementation cannot be overridden.  Consider 
this example:

component name=D1
implementation.composite name=CZ1/
reference name=r1 requires=suspendsTransaction/
/component

Let's assume CZ1 contains the component C1 shown earlier and that it promotes 
the component reference C1/r1 as r1.  C1/r1 has the intent 
propagatesTransaction.  This intent is considered a requirement of the 
implementation and it cannot be overridden by the using composite.  Therefore 
D1 is in error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive intents

2008-04-16 Thread Greg Dritschler (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Greg Dritschler updated TUSCANY-2239:
-

Attachment: tuscany-2239.patch

Support for mutually-exclusive intents
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

issues with transaction itest

2008-04-12 Thread Greg Dritschler

The transaction itest has some policy issues.

WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyComputationException: The
following are unfulfilled intents for component implementation -
TransferServiceComponent
Unfulfilled Intents = [{
http://www.osoa.org/xmlns/sca/1.0}managedTransaction.global]
Apr 12, 2008 5:27:14 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyComputationException: The
are unfulfilled intents for binding in reference - savings
Unfulfilled Intents = [{
http://www.osoa.org/xmlns/sca/1.0}propagatesTransaction]
Apr 12, 2008 5:27:14 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyComputationException: The
are unfulfilled intents for binding in reference - checking
Unfulfilled Intents = [{
http://www.osoa.org/xmlns/sca/1.0}propagatesTransaction]
Apr 12, 2008 5:27:14 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyComputationException: The
following are unfulfilled intents for component implementation -
SavingsAccountServiceComponent
Unfulfilled Intents = [{
http://www.osoa.org/xmlns/sca/1.0}managedTransaction.global]
Apr 12, 2008 5:27:14 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyComputationException: The
following are unfulfilled intents for binding in service - AccountService
Unfulfilled Intents = [{
http://www.osoa.org/xmlns/sca/1.0}propagatesTransaction]
Apr 12, 2008 5:27:14 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyComputationException: The
following are unfulfilled intents for component implementation -
CheckingAccountServiceComponent
Unfulfilled Intents = [{
http://www.osoa.org/xmlns/sca/1.0}managedTransaction.global]
Apr 12, 2008 5:27:14 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyComputationException: The
following are unfulfilled intents for binding in service - AccountService
Unfulfilled Intents = [{
http://www.osoa.org/xmlns/sca/1.0}propagatesTransaction]
Apr 12, 2008 5:27:14 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyComputationException: The
are unfulfilled intents for binding in reference - checking
Unfulfilled Intents = [{
http://www.osoa.org/xmlns/sca/1.0}propagatesTransaction]
Apr 12, 2008 5:27:14 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyComputationException: The
are unfulfilled intents for binding in reference - savings
Unfulfilled Intents = [{
http://www.osoa.org/xmlns/sca/1.0}propagatesTransaction]

I believe the problem is with the appliesTo expressions in the policy sets
which use implementation and binding.  I tried changing these to
sca:implementation.java and sca:binding.sca.  (I had to use a namespace
prefix.  implementation.java and binding.sca without a prefix didn't
help.  I'm not sure if that's expected.)  This eliminated the warnings
related to the implementation intents but not the binding intents.  I
realized that the .composite file doesn't have binding.sca elements.  I
added them and the warnings went away.  Ideally it should not be necessary
to add binding.sca elements to the composite to get the applicable policy
sets to work.

After making the above corrections the TransactionTestCase fails with the
following exception.

java.lang.IllegalStateException: Thread already associated with another
transaction
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.resume(TransactionManagerImpl.java:172)
at
org.apache.tuscany.sca.policy.transaction.TransactionManagerHelper.suspendsTransactionPostInvoke(TransactionManagerHelper.java:85)
at
org.apache.tuscany.sca.policy.transaction.TransactionManagerHelper.handlesInbound(TransactionManagerHelper.java:199)
at
org.apache.tuscany.sca.policy.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:97)
at
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.policy.transaction.TransactionInterceptor$TransactionalInvocation.run(TransactionInterceptor.java:117)
at
org.apache.tuscany.sca.policy.transaction.TransactionInterceptor$TransactionalInvocation.run(TransactionInterceptor.java:106)
at

Re: policy itest question

2008-04-08 Thread Greg Dritschler

D'oh!  I didn't think to look at the java classes for annotations.  That
explains a lot.

I agree the itest had some limitations.  In particular I think it would
catch if the policy handlers were created with the wrong policy sets, but it
didn't verify if some expected policy handlers were not created.

Doesn't the test in the assembly module do read/resolve/build testing?  How
would this be different?  I think the assembly module can't test the full
inheritance of intents down to implementation or binding given assembly is
so early in the build.  Would this new test address that?

The reason I'm asking about this is that I'm working on the support for
mutually-exclusive intents and I would like to modify an existing test
rather than start from scratch.

On Tue, Apr 8, 2008 at 9:20 AM, Venkata Krishnan [EMAIL PROTECTED]
wrote:

 Hi Greg,

 This itest needs to be re-written after the changes to the PolicyHandling
 story for the java implementation extension.

 Also I put in this itest to get some cases of policy annotations verified
 at
 a rudimentary level - like checking to see if the annotations ever get
 picked up and applied.  IMO, using interceptors for this testing is quite
 ugly and not going to go very far.  I am going to change this to
 explicitly
 execute read, resolve and build phases and simply verify against the built
 up composite.

 Thanks

 - Venkat

 On Mon, Apr 7, 2008 at 4:12 AM, Greg Dritschler [EMAIL PROTECTED]
 
 wrote:

  What is the status of the policy itest?  It uses the PolicyHandler
  interface
  to do its verification and that doesn't seem to work anymore, at least
 for
  Java implementations.  (The call to instantiate the
  JavaPolicyHandlingRuntimeWireProcessor in JavaRuntimeModuleActivator is
  commented out.)  Is this itest going to be rewritten?
 
  I can't say that I understand how this itest was supposed to have
 worked.
  The composite uses only one intent, TestIntent_3, on the implementation
 of
  AddServiceComponent.  That intent is provided by one policy set
  TestPolicySet_3_implementation.  Yet it looks to me like
  TestImplPolicyHandler is quite happy if various other policy sets are
  selected, such TestPolicySet_1_implementation or
  TestPolicySet_2_implementation.  What's the story?
 
  Greg Dritschler

policy itest question

2008-04-06 Thread Greg Dritschler

What is the status of the policy itest?  It uses the PolicyHandler interface
to do its verification and that doesn't seem to work anymore, at least for
Java implementations.  (The call to instantiate the
JavaPolicyHandlingRuntimeWireProcessor in JavaRuntimeModuleActivator is
commented out.)  Is this itest going to be rewritten?

I can't say that I understand how this itest was supposed to have worked.
The composite uses only one intent, TestIntent_3, on the implementation of
AddServiceComponent.  That intent is provided by one policy set
TestPolicySet_3_implementation.  Yet it looks to me like
TestImplPolicyHandler is quite happy if various other policy sets are
selected, such TestPolicySet_1_implementation or
TestPolicySet_2_implementation.  What's the story?

Greg Dritschler

Re: Synchronizing the access to SCADefinitions

2008-04-04 Thread Greg Dritschler

Ramkumar,

Sorry for the delay in responding.  I think you are probably right that
CopyOnWriteArrayList is the way to go.  Presumably there will be far more
contributions traversing the definitions (looking for policy sets etc) than
contributions adding to the contributions.  So trading off a high penalty on
write for no penalty on traversal sounds like a good idea.  The write
penalty could be mitigated by batching updates; i.e. instead of adding new
intents, policy sets, etc. to the lists one-by-one, collect them and make
one update to each list.

Greg Dritschler

On Wed, Apr 2, 2008 at 5:56 AM, Ramkumar R [EMAIL PROTECTED] wrote:

 Hi All, I am new to Tuscany Community, being interested in contributing
 and
 trying to catch up. Right now am going through the code to get a feel of
 it
 and the threading issue (as mentioned in
 http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html)
 seems
 to be something simple that I can fix to try a hand with Tuscany.



 Looking at the current implementation SCADefinitionsImpl.java uses java
 ArrayList to store the list of policy sets, intents, binding types etc.
 Possible solutions to this issue woule be to



 a) synchronize the methods that does the operations like clear/addAll OR

 b) replace the existing ArrayList with Vectors OR

 c) replace the existing ArrayList with CopyOnWriteArrayList (new with
 Java1.5)



 Option (a) seems to be a bad idea for me as it would lock the entire
 method,
 instead i would go for option (b) OR (c).



 Going for option (b), using Vectors OR Collections.synchronizedList
 synchronizes your list object. However, the iterators implemented in the
 java.util Collections classes are fail-fast, which means that if one
 thread
 changes a collection while another thread is traversing it through an
 Iterator, the next Iterator.hasNext() or Iterator.next() call will throw
 ConcurrentModificationException. If we have to prevent
 ConcurrentModificationException, we must lock the entire List while you
 are
 iterating by wrapping it with a synchronized block, which inturn is
 costly.



 Option (c) seems to be a good solution to the above problem, the
 CopyOnWriteArrayList class from util.concurrent (which will also appear in
 the java.util.concurrent package in JDK 1.5) is a thread-safe
 implementation
 of ArrayList that offers far better concurrency. Multiple reads can almost
 always execute concurrently, simultaneous reads and writes can usually
 execute concurrently, and multiple simultaneous writes can often execute
 concurrently. Also CopyOnWriteArrayList contains a mutable reference to an
 immutable array, so as long as that reference is held fixed, you get all
 the
 thread-safety benefits of immutability without the need for locking.



 I have opened a JIRA (Tuscany-2170) to fix this issue. Please suggest me
 if
 this one is the right approach.
 --
 Thanks  Regards,
 Ramkumar Ramalingam

Re: Synchronizing the access to SCADefinitions

2008-04-04 Thread Greg Dritschler

Oops, meant to say ...than contributions adding definitions.

On Fri, Apr 4, 2008 at 4:00 PM, Greg Dritschler [EMAIL PROTECTED]
wrote:

 Ramkumar,

 Sorry for the delay in responding.  I think you are probably right that
 CopyOnWriteArrayList is the way to go.  Presumably there will be far more
 contributions traversing the definitions (looking for policy sets etc) than
 contributions adding to the contributions.  So trading off a high penalty on
 write for no penalty on traversal sounds like a good idea.  The write
 penalty could be mitigated by batching updates; i.e. instead of adding new
 intents, policy sets, etc. to the lists one-by-one, collect them and make
 one update to each list.

 Greg Dritschler


 On Wed, Apr 2, 2008 at 5:56 AM, Ramkumar R [EMAIL PROTECTED] wrote:

  Hi All, I am new to Tuscany Community, being interested in contributing
  and
  trying to catch up. Right now am going through the code to get a feel of
  it
  and the threading issue (as mentioned in
  http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html)
  seems
  to be something simple that I can fix to try a hand with Tuscany.
 
 
 
  Looking at the current implementation SCADefinitionsImpl.java uses java
  ArrayList to store the list of policy sets, intents, binding types etc.
  Possible solutions to this issue woule be to
 
 
 
  a) synchronize the methods that does the operations like clear/addAll OR
 
  b) replace the existing ArrayList with Vectors OR
 
  c) replace the existing ArrayList with CopyOnWriteArrayList (new with
  Java1.5)
 
 
 
  Option (a) seems to be a bad idea for me as it would lock the entire
  method,
  instead i would go for option (b) OR (c).
 
 
 
  Going for option (b), using Vectors OR Collections.synchronizedList
  synchronizes your list object. However, the iterators implemented in the
  java.util Collections classes are fail-fast, which means that if one
  thread
  changes a collection while another thread is traversing it through an
  Iterator, the next Iterator.hasNext() or Iterator.next() call will throw
  ConcurrentModificationException. If we have to prevent
  ConcurrentModificationException, we must lock the entire List while you
  are
  iterating by wrapping it with a synchronized block, which inturn is
  costly.
 
 
 
  Option (c) seems to be a good solution to the above problem, the
  CopyOnWriteArrayList class from util.concurrent (which will also appear
  in
  the java.util.concurrent package in JDK 1.5) is a thread-safe
  implementation
  of ArrayList that offers far better concurrency. Multiple reads can
  almost
  always execute concurrently, simultaneous reads and writes can usually
  execute concurrently, and multiple simultaneous writes can often execute
  concurrently. Also CopyOnWriteArrayList contains a mutable reference to
  an
  immutable array, so as long as that reference is held fixed, you get all
  the
  thread-safety benefits of immutability without the need for locking.
 
 
 
  I have opened a JIRA (Tuscany-2170) to fix this issue. Please suggest me
  if
  this one is the right approach.
  --
  Thanks  Regards,
  Ramkumar Ramalingam

Re: Questions on how much Tuscany supports SCA 1.0 Assembly Model Spec section 1.8

2008-04-04 Thread Greg Dritschler

Yang, see replies within.

Greg Dritschler

On Thu, Apr 3, 2008 at 4:41 PM, Yang Lei [EMAIL PROTECTED] wrote:

 Hello,

 I am interested in knowing how Tuscany supports SCA Assembly Spec 1.0
 section 1.8

 1.8 SCA Definitions
 2491 There are a variety of SCA artifacts which are generally useful
 and which are not specific to a
 2492 particular composite or a particular component. These shared
 artifacts include intents, policy
 2493 sets, bindings, binding type definitions and implementation type
 definitions.
 2494 All of these artifacts within an SCA Domain are defined in a
 global, SCA Domain-wide file named
 2495 definitions.xml. The definitions.xml file contains a definitions
 element that conforms to the
 2496 following pseudo-schema snippet:
 2497 ?xml version=1.0 encoding=ASCII?
 2498 !-- Composite schema snippet --
 2499 definitions xmlns=http://www.osoa.org/xmlns/sca/1.0;
 2500 targetNamespace=xs:anyURI
 2501
 2502 sca:intent/*
 2503
 2504 sca:policySet/*
 2505
 2506 sca:binding/*
 2507
 2508 sca:bindingType/*
 2509
 2510 sca:implementationType/*
 2511
 2512 /definitions

 What interest me are:

 1. on a high level, how many places Tuscany can honor definitions.xml?

 e.g. definitions.xml is in a system class library,  and/or
 definitions.xml in a contribution that can be contributed to a SCA
 domain by using
 aEmbeddedSCADomain.getContributionService().contribute...

 I remember seeing a thread of discussion, will appreciate a link to
 the answers .


A contribution can include definitions.xml file(s) at any location.

Tuscany and Tuscany extensions also can provide definitions.xml files.  The
manner of doing this has changed several times.  The current way I believe
is to implement the SCADefinitionsProvider extension point.



 2. I assume regardless how definitions.xml is introduced into a
 domain, there is an aggregated view on the intents, policySets,
 bindings, bindingTypes, implementationTypes supported for the system.

 Is there some API/SPI somewhere to do a query and return the list?


SCADefinitions/SCADefinitionsImpl holds the lists but it is somewhat
internal to the builder at the moment.



 3.  What contents are supported for definitions.xml in Tuscany

 I understand we can define intents and policySets in definitions.xml
 today. How about binding , bindingType and implementationType.


bindingType and implementationType work too.


  I
 understand Tuscany has extension points to register binding types and
 implementation types. I wonder if/how we plan to support using
 definitions.xml for implementation type and binding type and how the
 two will work together. E.g. if definitions.xml can introduce additional
 binding type or
 implementation type through contribution, it will mean the
 implementation of the new bindingType or implementationType can be in
 a contribution related classLibrary we can add and remove during the
 lifecycle of a domain...


I would not expect a contribution to define a bindingType or an
implementationType.  A Tuscany extension that provides the binding or
implementation functionality would do that.  Note however that it is
completely optional.  A bindingType or implementationType is required only
if the binding or implementation provides built-in intents.  If the
binding or implementation doesn't provide any built-in intents, it does not
need to define a bindingType or implementationType as far as I understand.



 Looking forward to some answers.

 Yang.

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2171) binding.sca bindingType in definitions.xml not used if SCA binding is created during build phase

2008-03-31 Thread Greg Dritschler (JIRA)

binding.sca bindingType in definitions.xml not used if SCA binding is created 
during build phase


 Key: TUSCANY-2171
 URL: https://issues.apache.org/jira/browse/TUSCANY-2171
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler


I have a definitions.xml file which defines a bindingType for binding.sca.
  bindingType type=sca:binding.sca  mayProvide=propagatesTransaction/

I have a composite which uses an intent on a reference.
  reference name=daService target=DataAccessComponent 
requires=propagatesTransaction/

The reference does not have a binding.sca element.  In this case the binding 
model object is created by CompositeConfigurationBuilderImpl.createSCABinding() 
which is shown below.

private SCABinding createSCABinding() {
SCABinding scaBinding = scaBindingFactory.createSCABinding();
IntentAttachPointType bindingType = 
intentAttachPointTypeFactory.createBindingType();
bindingType.setName(BINDING_SCA_QNAME);
bindingType.setUnresolved(true);
((PolicySetAttachPoint)scaBinding).setType(bindingType);
return scaBinding;
}

This method creates an IntentAttachPointType which is unresolved.  There is no 
code to resolve the IntentAttachPointType to the real one.  As a result the 
PolicyComputer uses the unresolved IntentAttachPointType model and does not 
realize that binding.sca provides the intent needed by the reference.

Discussed on tuscany-dev here:  
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28903.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2172) Removing a contribution that has a definitions.xml file leaves the definitions in place

2008-03-31 Thread Greg Dritschler (JIRA)

Removing a contribution that has a definitions.xml file leaves the definitions 
in place
---

 Key: TUSCANY-2172
 URL: https://issues.apache.org/jira/browse/TUSCANY-2172
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler


A contribution may contain a definitions.xml document that defines intents 
and/or policy sets.  When such a contribution is removed, I would expect these 
definitions to be removed from the runtime.

Discussed on tuscany-dev here:  
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29138.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Removing definitions

2008-03-18 Thread Greg Dritschler

Hi.  I have noticed that there doesn't seem to be a way to remove
definitions (policy sets etc) from the domain.  The specs don't explicitly
say how this would happen, but surely this can't be a one-way process (you
can add but can't delete).  I can only guess that if definitions are added
as part of a contribution, then those definitions should be removed when the
contribution is removed?  There are some interesting issues, like what if
there are other contributions using elements of those definitions.

As an aside, I've noticed that SCADefinitionsImpl doesn't synchronize the
lists of policy sets, intents, etc. that it keeps, so it is exposed to bad
things happening if multiple threads try to add definitions at the same
time.  SCADefinitionsUtil also does clear/addAll operations that need to be
made thread-safe.

Greg

[jira] Created: (TUSCANY-2092) ConcurrentModificationException in ExtensibleContributionListener

2008-03-17 Thread Greg Dritschler (JIRA)

ConcurrentModificationException in ExtensibleContributionListener
-

 Key: TUSCANY-2092
 URL: https://issues.apache.org/jira/browse/TUSCANY-2092
 Project: Tuscany
  Issue Type: Bug
Reporter: Greg Dritschler


java.util.ConcurrentModificationException
at java.util.AbstractList$SimpleListIterator.next(Unknown Source)
at 
org.apache.tuscany.sca.contribution.service.ExtensibleContributionListener.contributionAdded(ExtensibleContributionListener.java:40)
at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:389)
at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)

The problem occurs if two threads try to add a contribution simultaneously.

DefaultContributionListenerExtensionPoint does not synchronize the list of 
listeners.  In particular loadListeners does not prevent multiple threads from 
trying to load the list of listeners.  One thread completes first while the 
other is still loading.  This leads to the exception shown above when a thread 
tries to iterate the listener list.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

IntentAttachPointType for internally-created SCA bindings

2008-03-13 Thread Greg Dritschler

I have a question about this method in CompositeConfigurationBuilderImpl.

private SCABinding createSCABinding() {
SCABinding scaBinding = scaBindingFactory.createSCABinding();
IntentAttachPointType bindingType =
intentAttachPointTypeFactory.createBindingType();
bindingType.setName(BINDING_SCA_QNAME);
bindingType.setUnresolved(true);
((PolicySetAttachPoint)scaBinding).setType(bindingType);
return scaBinding;
}

This is used to create the SCA binding for wires without explicit bindings.
My question is, how is the IntentAttachPointType model resolved?  This code
is in the build phase, which is past the read and resolve phases.  I can't
see how it is resolved.  The consequence of not resolving it is that the
bindingType definition for binding.sca (which may define mayProvide or
alwaysProvides intents) won't be used.  I tried to add a resolve() call here
to try to resolve the model but I couldn't figure out how to get the
ModelResolver to use.

Greg

[jira] Created: (TUSCANY-2069) Missing serialization in DirectedGraph

2008-03-08 Thread Greg Dritschler (JIRA)

Missing serialization in DirectedGraph
--

 Key: TUSCANY-2069
 URL: https://issues.apache.org/jira/browse/TUSCANY-2069
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler


I have a service with a web service binding that processes its input using an 
SDO.  The service works fine with one client.  It also works fine if it is 
driven once by one client and then driven by multiple clients.  But if it is 
driven initially by multiple clients (2 is enough), various failures occur in 
org.apache.tuscany.sca.databinding.impl.DirectedGraph.  It appears there is a 
lack of synchronization in this class.

Failure 1 - NPE

java.lang.NullPointerException
at 
org.apache.tuscany.sca.databinding.impl.DirectedGraph$Node.access$400(DirectedGraph.java:188)
at 
org.apache.tuscany.sca.databinding.impl.DirectedGraph.getShortestPath(DirectedGraph.java:314)
at 
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint.getTransformerChain(DefaultTransformerExtensionPoint.java:302)
at 
org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:162)
at 
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:76)
at 
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:183)
at 
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:59)
at 
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:88)
at 
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:192)
at 
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:89)
at 
com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.invokeNextInterceptor(RuntimeExtensionManager.java:211)
at 
com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.processMessage(RuntimeExtensionManager.java:96)
at 
com.ibm.ws.soa.sca.runtime.impl.RuntimeTuscanyInterceptor.invoke(RuntimeTuscanyInterceptor.java:154)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTarget(Axis2ServiceProvider.java:852)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:119)
at 
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:42)
at 
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:147)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)

Failure 2 - timeout (code is probably looping)

WTRN0124I: When the timeout occurred the thread with which the transaction is, 
or was most recently, associated was Thread[WebContainer : 0,5,main]. The stack 
trace of this thread when the timeout occurred was: 
java.util.HashMap.findNonNullKeyEntry(Unknown Source)
java.util.HashMap.putImpl(Unknown Source)
java.util.HashMap.put(Unknown Source)

org.apache.tuscany.sca.databinding.impl.DirectedGraph.getShortestPath(DirectedGraph.java:296)

org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint.getTransformerChain(DefaultTransformerExtensionPoint.java:302)

org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:162)

org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:76)

org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:183)

org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:59)

org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:88)

org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:192)

org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:89)

com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.invokeNextInterceptor(RuntimeExtensionManager.java:211)

com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.processMessage(RuntimeExtensionManager.java:96)

com.ibm.ws.soa.sca.runtime.impl.RuntimeTuscanyInterceptor.invoke(RuntimeTuscanyInterceptor.java:154)

org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTarget

Re: [Spec Related] 'provides' attribute in PolicySet

2008-03-07 Thread Greg Dritschler

No.  The type of @name is either NCName or QName.  It cannot be both.  If it
is an NCName, then it cannot have a namespace prefix;  the namespace is
always the targetNamespace.  If it is a QName, then it can have a namespace
prefix;  if it does not have a prefix then it uses the default namespace
from xmlns.  The spec says @name is a QName, but I thought from the above
discussion that we had concluded this is not correct and that it should be
an NCName.

On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan [EMAIL PROTECTED]
wrote:

 Hi Greg,

 Yes, it seems that when the PolicySet name is a NCName it does not assume
 the targetNamespace as its namespace.  I shall fix this rightaway.

 But then, I suppose its ok for a PolicySet name to be a QName when it is
 desired to have the PolicySet take a namespace other than the
 targetNamespace. i.e. all policysets in a definitions.xml need not belong
 to
 the same namespace.  Do you share this thought ?

 Thanks

 - Venkat

 If a PolicySet name does not have a prefix it assumes the targetNamespace.
 If a

 On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler 
 [EMAIL PROTECTED]
 wrote:

  Venkat,
 
  I was trying some stuff with policy sets and noticed the QName
 resolution
  wasn't working as I expected.  Specifically the targetNameSpace
 attribute
  of
  the definitions.xml document doesn't appear to be used to form the QName
  of
  the policy sets within.  I recalled we had discussed this in this old
  thread.
 
  PolicySetProcessor does this:
policySet.setName(getQName(reader, NAME));
 
  So it is trying to treat the @name attribute as a QName.  I thought we
 had
  concluded it is an NCName.
 
  For comparison CompositeProcessor does this:
   composite.setName(new QName(getString(reader, TARGET_NAMESPACE),
  getString(reader, NAME)));
 
  This is what I thought would happen based on this discussion.
 
  On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards 
  [EMAIL PROTECTED] wrote:
 
   Venkat,
  
   I was out on vacation when your original question was posted, so
 here's
   my contribution.
  
   Venkata Krishnan wrote:
Thanks Raymond.  A few more questions ;-)
   
- The xsd defines the name attribute for PolicyIntent and PolicySet
 as
of type NCName.  However we have model these in the model classes
QNames.  I am assuming that the namespace uri for all intents and
policyset defined in a specific definitions.xml is the value of the
'targetNamespace' attribute of the 'definitions' element.  Is this
right?
   
  
   Typically, all declarations of name elements for elements which live
 in
   a particular namespace are defined in the XSDs as NCNames (see
   Composite, for example).  It is usual for the targetNamespace to
 declare
   the namespace into which the elements are being declared.
  
   So, in this case for the intents  policySets, you're right, we'd
 expect
   the targetNamespace to be used.  Anything else would look distinctly
  odd.
  
- Can a qualified intent have its qualifiable parent intent
 belonging
to a different targetnamespace.  If so how would this be evident
 from
the name of the qualified intent?  For example if there is an intent
a:intentOne and then there is a qualified intent over this like
intentOne.intentTwo - how is to be inferred that intentOne belongs
 to
a different namespace
   
  
   Hmm, we had never intended this. I'd expect the qualified intent and
 its
   qualifiers to be in the same namespace.  It's not outlawed for them to
   be in different namespaces, but I've no idea how you would express the
   definition to indicate this.
  
  
Thanks
   
- Venkat
  
   Hope this helps,
  
   Yours,  Mike.
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Spec Related] 'provides' attribute in PolicySet

2008-03-07 Thread Greg Dritschler

See below.

On Fri, Mar 7, 2008 at 12:11 PM, Venkata Krishnan [EMAIL PROTECTED]
wrote:

 Thinking a bit futher about this, I am wondering what would we expect for
 'requires' attribute of a ProfileIntent.  Do we assume that the intents
 required by the Profile Intent should also belong to the same namespace as
 the Profile Intent ?  I guess not.


Right.  @requires takes a list of QNames so it can be composed of intents in
various namespaces.  I can see someone wanting to create a profile intent in
their own namespace that uses intents in other standard namespaces.



 How about the case of the 'provides' attribute for PolicySets ?  Do we say
 these must be QNames strictly even if the PolicySet was just about
 providing
 for intents in the same namespace ?


@provides is also a list of QNames so the usual rules for the prefix should
be followed.  If there is no prefix, then xmlns is used by default (not
targetNamespace).  If you want @provides to refer to an intent that's
defined in the same definitions.xml, you need to define a namespace prefix
for it (with the same value as targetNamespace) and use the prefix
appropriately.



 Am just about trying to understand if the targetnamespace is to be applied
 only to Intent and PolicySet names and not to where they might be
 referrred
 within the same definitions.xml file.

 - Venkat


 On Fri, Mar 7, 2008 at 10:09 PM, Venkata Krishnan [EMAIL PROTECTED]
 wrote:

  Ok.  I seemed to have lost the plot down the line.  Now that I have
  re-read Mike's explanation in this thread, it does seem like you have a
  point.
 
  - Venkat
 
 
  On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler 
 [EMAIL PROTECTED]
  wrote:
 
   No.  The type of @name is either NCName or QName.  It cannot be both.
If it
   is an NCName, then it cannot have a namespace prefix;  the namespace
 is
   always the targetNamespace.  If it is a QName, then it can have a
   namespace
   prefix;  if it does not have a prefix then it uses the default
 namespace
   from xmlns.  The spec says @name is a QName, but I thought from the
   above
   discussion that we had concluded this is not correct and that it
 should
   be
   an NCName.
  
   On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan 
 [EMAIL PROTECTED]
   wrote:
  
Hi Greg,
   
Yes, it seems that when the PolicySet name is a NCName it does not
   assume
the targetNamespace as its namespace.  I shall fix this rightaway.
   
But then, I suppose its ok for a PolicySet name to be a QName when
 it
   is
desired to have the PolicySet take a namespace other than the
targetNamespace. i.e. all policysets in a definitions.xml need not
   belong
to
the same namespace.  Do you share this thought ?
   
Thanks
   
- Venkat
   
If a PolicySet name does not have a prefix it assumes the
   targetNamespace.
If a
   
On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler 
[EMAIL PROTECTED]
wrote:
   
 Venkat,

 I was trying some stuff with policy sets and noticed the QName
resolution
 wasn't working as I expected.  Specifically the targetNameSpace
attribute
 of
 the definitions.xml document doesn't appear to be used to form the
   QName
 of
 the policy sets within.  I recalled we had discussed this in this
   old
 thread.

 PolicySetProcessor does this:
   policySet.setName(getQName(reader, NAME));

 So it is trying to treat the @name attribute as a QName.  I
 thought
   we
had
 concluded it is an NCName.

 For comparison CompositeProcessor does this:
  composite.setName(new QName(getString(reader, TARGET_NAMESPACE),
 getString(reader, NAME)));

 This is what I thought would happen based on this discussion.

 On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards 
 [EMAIL PROTECTED] wrote:

  Venkat,
 
  I was out on vacation when your original question was posted, so
here's
  my contribution.
 
  Venkata Krishnan wrote:
   Thanks Raymond.  A few more questions ;-)
  
   - The xsd defines the name attribute for PolicyIntent and
   PolicySet
as
   of type NCName.  However we have model these in the model
   classes
   QNames.  I am assuming that the namespace uri for all intents
   and
   policyset defined in a specific definitions.xml is the value
 of
   the
   'targetNamespace' attribute of the 'definitions' element.  Is
   this
   right?
  
 
  Typically, all declarations of name elements for elements which
   live
in
  a particular namespace are defined in the XSDs as NCNames (see
  Composite, for example).  It is usual for the targetNamespace to
declare
  the namespace into which the elements are being declared.
 
  So, in this case for the intents  policySets, you're right,
 we'd
expect
  the targetNamespace to be used.  Anything else would look
   distinctly
 odd.
 
   - Can

Re: [Spec Related] 'provides' attribute in PolicySet

2008-03-06 Thread Greg Dritschler

Venkat,

I was trying some stuff with policy sets and noticed the QName resolution
wasn't working as I expected.  Specifically the targetNameSpace attribute of
the definitions.xml document doesn't appear to be used to form the QName of
the policy sets within.  I recalled we had discussed this in this old
thread.

PolicySetProcessor does this:
   policySet.setName(getQName(reader, NAME));

So it is trying to treat the @name attribute as a QName.  I thought we had
concluded it is an NCName.

For comparison CompositeProcessor does this:
  composite.setName(new QName(getString(reader, TARGET_NAMESPACE),
getString(reader, NAME)));

This is what I thought would happen based on this discussion.

On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards 
[EMAIL PROTECTED] wrote:

 Venkat,

 I was out on vacation when your original question was posted, so here's
 my contribution.

 Venkata Krishnan wrote:
  Thanks Raymond.  A few more questions ;-)
 
  - The xsd defines the name attribute for PolicyIntent and PolicySet as
  of type NCName.  However we have model these in the model classes
  QNames.  I am assuming that the namespace uri for all intents and
  policyset defined in a specific definitions.xml is the value of the
  'targetNamespace' attribute of the 'definitions' element.  Is this
  right?
 

 Typically, all declarations of name elements for elements which live in
 a particular namespace are defined in the XSDs as NCNames (see
 Composite, for example).  It is usual for the targetNamespace to declare
 the namespace into which the elements are being declared.

 So, in this case for the intents  policySets, you're right, we'd expect
 the targetNamespace to be used.  Anything else would look distinctly odd.

  - Can a qualified intent have its qualifiable parent intent belonging
  to a different targetnamespace.  If so how would this be evident from
  the name of the qualified intent?  For example if there is an intent
  a:intentOne and then there is a qualified intent over this like
  intentOne.intentTwo - how is to be inferred that intentOne belongs to
  a different namespace
 

 Hmm, we had never intended this. I'd expect the qualified intent and its
 qualifiers to be in the same namespace.  It's not outlawed for them to
 be in different namespaces, but I've no idea how you would express the
 definition to indicate this.


  Thanks
 
  - Venkat

 Hope this helps,

 Yours,  Mike.

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Authentication Authorization across wsBinding java Implementation - was : Using security policies in the Bigbank scenario

2008-03-06 Thread Greg Dritschler

Ok.  Please be aware there is an errata associated with the authorization
elements.
  http://www.osoa.org/jira/browse/POLICY-26

On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan [EMAIL PROTECTED]
wrote:

 +1.  I will start looking into this after I am done with some
 half-finished
 things on my plate at the moment.  Thanks.

 - Venkat

 On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino 
 [EMAIL PROTECTED] wrote:

  Greg Dritschler wrote:
   Is the authentication policy going to bear any resemblance to the
 policy
   described in section 1.7.3.1 of the Policy spec, or is it completely
   different?
  
   Greg
  
 
  I think that Tuscany should implement the authorization - I guess that's
  what you meant :) - and security identity policies as described in
  section 1.7.3.1 of the Policy spec, at least.
 
  We could start with just implementing the model and XML reading for the
  elements described in 1.7.3.1 and let the various component
  implementation extensions handle them (or not) in their own way, but
  having the model and XML processors would be a good start IMO.
 
  Any thoughts?
  --
  Jean-Sebastien
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

Re: PolicyHanders

2008-02-12 Thread Greg Dritschler

Comments below.

On Feb 11, 2008 7:36 AM, Venkata Krishnan [EMAIL PROTECTED] wrote:

 Hi Greg,

 Thanks for your observations / suggestions.  Please see my comments
 inline.
 I apologize for making them lengthy in the hope that it would trigger more
 discussions.

 - Venkat

 On Feb 7, 2008 1:33 AM, Greg Dritschler [EMAIL PROTECTED] wrote:

  I have been looking at the PolicyHandler support for Java
 implementations
  and overall I like the direction this is going.  I have some comments
  about
  it.
 
  1.  If a given component/operation has multiple policy sets that are
  handled
  by the same PolicyHandler, it appears that one PolicyHandler is created
  for
  each such policy set.  I wonder if it wouldn't be better to call a given
  PolicyHandler only once per invocation and give it the full list of
 policy
  sets it handles.  This may be more efficient depending on the policy
 (the
  handler may be able to optimize/combine policies, and it may be able to
  find
  conflicts that are beyond the powers of the policy framework).


 Just to clarify, I did start with PolicyHanlder types classified against
 the
 PolicySet name, but later discovered that this is not scalable.  Today,
 the
 PolicyHandler types are classified against the PolicyModel that they can
 understand (i.e. WS-Policy or some customer model) and the Intent that
 they
 can deal with (i.e authentication or transaction).  I feel we might also
 have to add one more classifier that denotes the QoS infrastructure that
 the
 PolicyHandler is capable of working with. While the policy model and
 intent
 can be extracted for a PolicySet to find the appropriate PolicyHandler, I
 am
 not sure where we can encapsulate this 'specific infrastructure'
 information.


I wasn't suggesting any changes along these lines.  I think using model
objects and intents is sufficient.


 So, if it does happen that we have mutliple PolicySets on a wire that
 point
 to the same PolicyHandler type, yes it makes sense to do what you suggest.
 Infact, this turns out to be a necessity for example when we want to
 configure the Axis2 Config Parameters for binding.ws to say enable
 authentication AND integrity where each of these could have their own
 PolicySets.

 2.  Some intents can be provided without requiring a policy set (these are
  the intents in the implementation's mayProvides list).  Although the
  PolicyHandler gets registered for an intent, it appears it is only
 driven
  if
  the intent is satisfied by a policy set.  It would be nice if it could
 be
  driven if the intent appears in the mayProvides list too.


 +1.  At the present moment this is left to how implementation and binding
 extensions would choose to deal with.  I'd prefer that the binding /
 implementation providers parse the list of required intents and if there
 are
 the ones that they 'mayProvide' then suitable PolicySets should be added
 to
 the list of PolicySets.  Ofcourse the corresponding PolicyHandlers should
 also be defined and registered.  This I feel provide uniformity and
 extensibility to how policy handling plugs into extensions.


Intents in the 'mayProvides' list don't require policy sets.


 
  3.  I'm also wondering whether it should be possible to register a
  PolicyHandler that always gets control regardless of what intents or
  policy
  sets are specified.  This might be to implement some default behavior.
   I'm
  thinking of transactions here.  The transaction spec says that the
 runtime
  can provide one of the intents by default, but the choice of default is
  implementation-specific.  There's no way to declare the default intent
 to
  the policy framework today, so there's no choice but to give control to
  the
  transaction handler and let it figure it out.
 

 This sounds like something that is left for bindings / implementations to
 deal with, in the way they might choose to.  As I had mentioned in the
 previous point a cleaner way would be for binding /implementation
 providers
 to verify if a default intent needs to be in force and add the
 corresponding
 PolicySet to the list of policysets.  For example, if an implementation
 provider parses the requiredIntents and discovers nothing in there related
 to transaction intent type, then it could add the default transaction
 PolicySet to the list of policysets.  Makes sense or am I missing your
 point?


Intents in the 'mayProvides' list don't require policy sets.



  4.  The PolicyHandler is provided the target Operation and Message.  I
  wonder if that's enough context.  Can the handler works its way up the
  model (component, etc) if it needs to?
 

  I suppose what is 'provided' to the handler depends on the implementation
 or binding extension and from where it decides to call the handlers.  If
 the
 handlers are called from the interceptors they can provide any state that
 is
 available to them.  Or if there is context information that is not going
 to
 change across service calls then such information could

Re: Adding phase-based ordering support for invokers/interceptors in the InvocationChain

2008-02-12 Thread Greg Dritschler

Raymond,

Your proposal works for me.

On Feb 4, 2008 11:47 AM, Raymond Feng [EMAIL PROTECTED] wrote:

 Please see my comments below.

 Thanks,
 Raymond

 - Original Message -
 From: Jean-Sebastien Delfino [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Saturday, February 02, 2008 2:09 PM
 Subject: Re: Adding phase-based ordering support for invokers/interceptors
 in the InvocationChain


  Raymond Feng wrote:
  [snip]
  As of today, we can add multiple interceptors to the invocation chain,
  but we cannot control their ordering.
 
  Is that a problem?

 Yes, it's a problem. For example, I had to hack to add the databinding
 transformation interceptor to be added before the binding/implementation
 invoker.

 
  When more policies are supported,
  I see a need to provide some simple ordering mechnisim for
 interceptors.
  [snip]
 
  Do you have a specific use case?

 Yes. A few:
 1) binding/implementation invokers have to be the last one in the
 invocation
 chain.
 2) for a service wire, service-level policy handlers (such as
 propategate/suspend transaction) must be called before
 implementation-level
 handlers (such as managed/noManagedTransaction, security run-as).
 3) if I add a encryption/decryption policy handler, it needs to be invoked
 after the data transformation interceptor on the client side, and before
 the
 data transformation interceptor on the service side.
 4) pass-by-value interceptor (if required) should be invoked before the
 implementation-invoker.

 
  --
  Jean-Sebastien
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

PolicyHanders

2008-02-06 Thread Greg Dritschler

I have been looking at the PolicyHandler support for Java implementations
and overall I like the direction this is going.  I have some comments about
it.

1.  If a given component/operation has multiple policy sets that are handled
by the same PolicyHandler, it appears that one PolicyHandler is created for
each such policy set.  I wonder if it wouldn't be better to call a given
PolicyHandler only once per invocation and give it the full list of policy
sets it handles.  This may be more efficient depending on the policy (the
handler may be able to optimize/combine policies, and it may be able to find
conflicts that are beyond the powers of the policy framework).

2.  Some intents can be provided without requiring a policy set (these are
the intents in the implementation's mayProvides list).  Although the
PolicyHandler gets registered for an intent, it appears it is only driven if
the intent is satisfied by a policy set.  It would be nice if it could be
driven if the intent appears in the mayProvides list too.

3.  I'm also wondering whether it should be possible to register a
PolicyHandler that always gets control regardless of what intents or policy
sets are specified.  This might be to implement some default behavior.  I'm
thinking of transactions here.  The transaction spec says that the runtime
can provide one of the intents by default, but the choice of default is
implementation-specific.  There's no way to declare the default intent to
the policy framework today, so there's no choice but to give control to the
transaction handler and let it figure it out.

4.  The PolicyHandler is provided the target Operation and Message.  I
wonder if that's enough context.  Can the handler works its way up the
model (component, etc) if it needs to?

5.  It might be nice for the PolicyHandlingInterceptor constructor to make
an initialization call to the handler so it can do some setup.

6.  If policy sets are attached to the operation,
JavaPolicyHandlingRuntimeWireProcessor uses the handlers associated with
those policy sets instead of the handlers associated with the component
level.  I don't think this is completely right.  It should be possible to
use a policy from one domain (say security) for a given operation while
using a policy for another domain (say transactions) at the component
level.  The section of the Policy spec dealing with operation-level
attachment for implementations does not address this point specifically.
However the section on operation-level attachment for bindings does offer
this:  ...operation-level policySets override corresponding policySets
specified for the binding (where a 'corresponding' policySet @provides at
least one common intent).

7.  JavaPolicyHandlingRuntimeWireProcessor adds the interceptor to the end
of the invocation chain.  In the case of chains for oneway operations, this
places the interceptor after the NonBlockingInterceptor.  This may present
problems for policy handlers such as transactions that are sensitive to
running on the thread of execution.  It's a bit tricky.  For wires into a
service, the handler would want to be called after the
NonBlockingInterceptor has switched threads.  For wires into a reference,
the handler would want to be before the NonBlockingInterceptor switches off
to another thread.

Transaction intents

2008-01-24 Thread Greg Dritschler

I have been looking at the SCA Transaction spec and I have noticed some
difficulties reconciling the transaction intent descriptions with the
capabilities of the policy framework.

  1) The SCA Transaction spec has several sets of mutually-exclusive
intents: managedTransaction and noManagedTransaction, propagatesTransaction
and suspendsTransaction, transactedOneWay and immediateOneWay.  In the
policy framework all intents are additive and there is no concept of
exclusive intents.  I know this problem was discussed in the OSOA Policy
working group but it was left unresolved in the published specs.  I think
there needs to be some extension to the policy framework implementation to
handle exclusive intents.

  2) The transactedOneWay and immediateOneWay intents are unique in that
they apply to services and references but are classified as implementation
intents (rather than interaction intents).  What this means is that the
intents specified at each end of the wire having no bearing on each other.
A reference might use transactedOneWay while the service uses
immediateOneWay or vice versa.  This conflicts with the following statement
in section 1.4.10 of the SCA Policy Framework:

   If the element is a binding instance and its parent element
(service, reference or callback) is wired, the required intents of the other
side of the wire may be added to the intent set when they are available.
This may simplify, or eliminate, the policy matching step later described in
step C.

I think this statement needs to be clarified to say that only interaction
intents are to be copied.  It also means there needs to be some extension to
the intent definition that indicates whether an intent is an interaction
intent or not.

I also found a minor problem in the Tuscany implementation of the policy
framework.  In the process of trying to find a policy set that matches the
required intents, the code removes intents from the intent attach point that
it finds in a bindingType or implementationType mayProvide list.  I'm not
sure how the binding or implementation can provide the intent if it has been
removed.  I think the code needs to be changed to preserve these intents in
the intent attach point and just skip over them when looking for matching
policy sets.

Greg Dritschler

Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.

2008-01-15 Thread Greg Dritschler

I agree that intents that are listed in mayProvide do not require a policy
set.  The binding/implementation provides the functionality of the intent if
the intent is present on the relevant composite element.  It looks to me
that CompositeWireBuilderImpl, as part of the process of trying to find
matching policy sets, removes intents that are found in mayProvide from the
model object.  In that case, how would the binding/implementation know it
should provide the intent functionality if the intent isn't present in the
model anymore?

Greg Dritschler

[jira] Created: (TUSCANY-1949) import.sdo element is not resolved if it follows a property element

2008-01-04 Thread Greg Dritschler (JIRA)

import.sdo element is not resolved if it follows a property element
---

 Key: TUSCANY-1949
 URL: https://issues.apache.org/jira/browse/TUSCANY-1949
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.0
Reporter: Greg Dritschler
Priority: Minor


I have an SCA composite that uses both a property element and an import.sdo 
element.  If the property element appears before the import.sdo element as 
shown below, then the application fails during execution when it tries to 
create an SDO.

 composite ...
   component ...
 property name=p type=xsd:stringXYZZY/property
   /component
   dbsdo:import.sdo .../
 /composite

If I reorder the elements as shown below then the application works.

 composite ...
   dbsdo:import.sdo .../
   component ...
 property name=p type=xsd:stringXYZZY/property
   /component
 /composite

I found the problem in CompositeProcessor.  When a property element is found, 
it calls a method readPropertyValue.  This method consumes the property end 
element so CompositeProcessor won't see it.  Since CompositeProcessor does not 
see the property end element, it does not clear the property method variable. 
 Then when it processes the import.sdo element, it sees the property variable 
is non-null and mistakenly associates the import.sdo extension with the 
property instead of with the composite.

I was able to work around the problem by clearing the property variable after 
the readPropertyValue call as shown below.  (There are actually two such calls, 
one for component level and one for composite level, and I cleared it in both 
cases.)

// Read the property value
Document value = 
readPropertyValue(property.getXSDElement(), property.getXSDType(), reader);
property.setValue(value);

composite.getProperties().add(property);
property = null; // **WORKAROUND**

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1949) import.sdo element is not resolved if it follows a property element

2008-01-04 Thread Greg Dritschler (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555995#action_12555995
 ] 

Greg Dritschler commented on TUSCANY-1949:
--

Can property elements have extension elements?  If not maybe the correct 
solution is to remove the code that tries to associate extensions with 
properties?

// Add the extension element to the current
// element
if (callback != null) {
callback.getExtensions().add(extension);
} else if (contract != null) {
contract.getExtensions().add(extension);
} else if (property != null) {
property.getExtensions().add(extension);
} else if (component != null) {
component.getExtensions().add(extension);
} else {
composite.getExtensions().add(extension);
}

 import.sdo element is not resolved if it follows a property element
 ---

 Key: TUSCANY-1949
 URL: https://issues.apache.org/jira/browse/TUSCANY-1949
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.0
Reporter: Greg Dritschler
Priority: Minor

 I have an SCA composite that uses both a property element and an import.sdo 
 element.  If the property element appears before the import.sdo element as 
 shown below, then the application fails during execution when it tries to 
 create an SDO.
  composite ...
component ...
  property name=p type=xsd:stringXYZZY/property
/component
dbsdo:import.sdo .../
  /composite
 If I reorder the elements as shown below then the application works.
  composite ...
dbsdo:import.sdo .../
component ...
  property name=p type=xsd:stringXYZZY/property
/component
  /composite
 I found the problem in CompositeProcessor.  When a property element is found, 
 it calls a method readPropertyValue.  This method consumes the property end 
 element so CompositeProcessor won't see it.  Since CompositeProcessor does 
 not see the property end element, it does not clear the property method 
 variable.  Then when it processes the import.sdo element, it sees the 
 property variable is non-null and mistakenly associates the import.sdo 
 extension with the property instead of with the composite.
 I was able to work around the problem by clearing the property variable after 
 the readPropertyValue call as shown below.  (There are actually two such 
 calls, one for component level and one for composite level, and I cleared it 
 in both cases.)
 // Read the property value
 Document value = 
 readPropertyValue(property.getXSDElement(), property.getXSDType(), reader);
 property.setValue(value);
 
 composite.getProperties().add(property);
 property = null; // **WORKAROUND**

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Do we still need special handling of callback bindings and wires?

2007-11-26 Thread Greg Dritschler

I missed it when it happened, but it appears that this discussion was
settled (not sure where or how) in favor of not ever creating static wires
for callbacks.  Why is that?  I have no idea what the performance cost is
one way or the other, but I agree with Simon Nash that it seems a bit
strange to have static wires in the forward direction and only a dynamic
wire in the callback direction.

Greg Dritschler

On Aug 21, 2007 11:00 AM, Simon Nash [EMAIL PROTECTED] wrote:

 Comments inline.

   Simon

 Raymond Feng wrote:

  Comments inline.
 
  Thanks,
  Raymond
 
  - Original Message - From: Simon Nash [EMAIL PROTECTED]
  To: tuscany-dev@ws.apache.org
  Sent: Monday, August 20, 2007 5:14 PM
  Subject: Re: Do we still need special handling of callback bindings and
  wires?
 
 
  The short answer is Yes.  The long answer follows below :-)
 
  I'll describe the design approach used by the code in my patch for
  TUSCANY-1496.  Things are moving rapidly in this area with Raymond's
  work to support late binding between references and services, so some
  of this description may need to be updated.
 
 
  It's my turn to update the discription now :-)
 
 
  Wires may be reference wires or service wires:
   1. Reference wires connect a source reference to a target binding
  and endpoint.  The source reference could be a callback service's
  pseudo-reference.
   2. Service wires connect a binding endpoint to a service
 implementation.
  The service implementation could be a callback reference's
  pseudo-service.
 
  Reference wires may be static or dynamic:
   1. A static wire targets a specific binding and endpoint (local or
  remote).  Dispatching a call down an invocation chain for this
  wire results in a call to the statically configured binding and
  endpoint for the wire.
   2. A dynamic wire targets a specific binding but an unspecified
  endpoint.  The actual target endpoint is provided at invocation
  time.  Depending on the binding type, dynamic wires may perform
  worse than static wires, or their performance may be the same.
  Some bindings may only support static wires.  Some may only support
  dynamic wires.  Some may support both, with static wires providing
  better performance.
 
 
  I'm not sure why you think it's the binding's job to support static or
  dynanic wire. To me, the dynamic wire needs to be bound an endpoint
  before it can used for invocations.
 
 Maybe the terminology static and dynamic is confusing here.  By
 static I mean a wire that is bound to a specific target endpoint and
 all invocations down that wire will go to this pre-bound endpoint.
 By dynamic I mean a wire that is not pre-bound to a specific endpoint,
 allowing each invocation down the wire to specify its target endpoint.

 Some bindings can optimize if they have have static knowledge of the
 target.  The local SCA binding is in this category, because static
 pre-knowledge allows the source and target invocation chains to be
 connected (now by means of the binding invoker), so that each invocation
 becomes a direct call through pre-built invocation chains.

 Other bindings perform the same whether or not they have this static
 knowledge.  The Axis2 Web Service binding is in this category, because
 it always creates an Axis2 operation client for each request, and it
 passes the target endpoint into Axis2 as a creation parameter for the
 operation client.

 Requiring all wires to be be pre-bound to a target endpoint before they
 can be used for an invocation would require many more wires to be created
 than is necessary.  An extreme case of this is callbacks over Web Services
 from multiple clients to a single service, where the service's callback
 pseudo-reference should not use a separate callback wire for each client
 but should have a single dynamic wire that can invoke any client endpoint.
 Forcing every callback operation to create and bind a runtime wire first
 is unneccessary and will incur both time and space costs.

 
  Service wires are effectively always static since on the service
  side, the binding and endpoint is known.  Every service and binding
  combination has a single service wire that is used by the binding
  provider to invoke the service.
 
  For statically connected references and services (e.g., wired in SCDL,
  using an SCA binding, and locally accessible), static forward wires
  are created.  The core can't fully complete the end-to-end invocation
  chain for the static wire, so the start methods of bindings that
  support local optimization (like the local SCA binding) can complete
  these connections using information provided by the core.
 
 
  Now we support the lazy creation of RuntimeWire/Invocation for a
  reference. I also changed the code to have the RuntimeSCABindingInvoker
  to delegate the call to the first invoker in the target service chain
  instead of trying to merge/connect the two chains together.
 
 Lazy creation is fine

Re: Conversation in RuntimeWireInvoker and thread safety

2007-11-21 Thread Greg Dritschler

Simon,

Yes you are right.  RuntimeWireInvoker is using member variables for
conversation-related data which isn't thread-safe.  I noticed a few other
things too:

1)  Both RuntimeWireInvoker and JavaImplementationInvoker try to manage a
conversational scope object.  In particular they both try to remove the
object at the end of a conversation.  JavaImplementationInvoker gets the
first crack at it and in the process nullifies the conversation id in the
to parameters.  I think this prevents
RuntimeWireInvoker.conversationPostInvoke from doing its thing.  This might
leave a conversation dangling in the ConversationManager since only
RuntimeWireInvoker interacts with the ConversationManager.  I think only one
class should be trying to manage conversational objects and it makes sense
to me for it to be the RuntimeWireInvoker (which should cover all
implementations).  In that case the conversation management in
JavaImplementationInvoker should be removed.  In order for this to work
though all bindings need to dispatch through the RuntimeWireInvoker;  I
don't think all do.

2)  Why do we need both a ConversationalScopeContainer and a
ConversationManager to track conversations?  This seems overly complicated
to me.  I think all uses of ConversationManager should be removed and the
code should be updated to work directly with the
ConversationalScopeContainer.  This affects JDKInvocationHandler as well as
RuntimeWireInvoker.

3) RuntimeWireInvoker has a method handleCallback which was copied from
JDKInvocationHandler.  This method makes no sense to me in an inbound
dispatch context.

Greg Dritschler

On Oct 18, 2007 10:32 AM, Simon Laws [EMAIL PROTECTED] wrote:

 Hi

 Similar code for handling conversational state as appears in the
 JDKInvocationHandler has been added to the RuntimeWireInvoker and I was
 just
 putting a change in and spotted something that looks a little strange. I'm
 expecting the RuntimeWireInvoker to be used by many different
 conversations
 as it's created on a wire. This is slightly different from the
 JDKInvocationHandler as in that case you always get the same conversation
 when you send messages through a reference. So I want to fix it so that
 that
 the conversation object is retrieved from the conversation manager each
 time
 before it is used. There are a couple of places where this doesn't happen
 (including in a piece of code I've just edited).But I want to check I
 understand RuntimeWireInvoker correctly before making the change.

 Regards

 Simon

[jira] Updated: (TUSCANY-1765) Component implementation has wrong intent

2007-09-19 Thread Greg Dritschler (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Dritschler updated TUSCANY-1765:
-

Attachment: TUSCANY-1765.patch

BaseJavaImplementationImpl.equals is modified to call its superclass 
ComponentType.equals.

ComponentType.equals is modified to compare required intents.

 Component implementation has wrong intent
 -

 Key: TUSCANY-1765
 URL: https://issues.apache.org/jira/browse/TUSCANY-1765
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.99
Reporter: Greg Dritschler
Priority: Minor
 Attachments: TUSCANY-1765.patch


 Suppose there is a composite with multiple components that use the same 
 implementation class but different implementation intents, as shown below.
 composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=CompositeX
 component name=ComponentA
 implementation.java class=test.DataServiceImpl 
 requires=managedTransaction.none/
 /component
 component name=ComponentB
 implementation.java class=test.DataServiceImpl 
 requires=managedTransaction.global/
 /component
 /composite
 In this case the components will share a common Implementation model object 
 because only the class name is being used to determine whether a component's 
 implementation is the same as another's.  This means one of the components 
 will have the wrong implementation intents recorded in the model.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1765) Component implementation has wrong intent

2007-09-19 Thread Greg Dritschler (JIRA)

Component implementation has wrong intent
-

 Key: TUSCANY-1765
 URL: https://issues.apache.org/jira/browse/TUSCANY-1765
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.99
Reporter: Greg Dritschler
Priority: Minor


Suppose there is a composite with multiple components that use the same 
implementation class but different implementation intents, as shown below.

composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=CompositeX
component name=ComponentA
implementation.java class=test.DataServiceImpl 
requires=managedTransaction.none/
/component
component name=ComponentB
implementation.java class=test.DataServiceImpl 
requires=managedTransaction.global/
/component
/composite

In this case the components will share a common Implementation model object 
because only the class name is being used to determine whether a component's 
implementation is the same as another's.  This means one of the components will 
have the wrong implementation intents recorded in the model.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

IntentAttachPoint

2007-09-10 Thread Greg Dritschler

I have a question about changes that were made in revision 566649.  This
revision changed the assembly model object interfaces so that they don't
extend IntentAttachPoint.  The assembly model implementations now extend
IntentAttachPoint.  As a consequence any code that wants to reference the
intents needs to check if the implementation object is an instance of
IntentAttachPoint and then cast it.  Why was this done?  I'm not saying it's
right or wrong, I just want to know the point of the change.  It seems to
allow assembly model objects (implementations, bindings) to be created which
don't support intents.  Is that a good thing?

Greg

[jira] Created: (TUSCANY-1554) Support alternate WorkScheduler implementations

2007-08-20 Thread Greg Dritschler (JIRA)

Support alternate WorkScheduler implementations
---

 Key: TUSCANY-1554
 URL: https://issues.apache.org/jira/browse/TUSCANY-1554
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.90
Reporter: Greg Dritschler
Priority: Minor


A patch is submitted that allows Tuscany's implementation of the WorkScheduler 
SPI, Jsr237WorkScheduler, to be plug-replaced by another implementation.  The 
patch uses the mechanism created in revision 564364 which allows the 
implementations of registry objects to be created dynamically based on a 
metadata file.

In order to simplify things, I took the position that the WorkManager is now a 
private implementation detail of the WorkScheduler.  This avoids the need for 
the dynamic registry object creation mechanism to support a specialized 
WorkScheduler constructor.  The only use of the WorkManager outside the 
WorkScheduler was a destroy() call in ReallySmallRuntime.  I moved the 
destroy() method into the WorkScheduler interface.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1554) Support alternate WorkScheduler implementations

2007-08-20 Thread Greg Dritschler (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Dritschler updated TUSCANY-1554:
-

Attachment: Tuscany-1554.patch

 Support alternate WorkScheduler implementations
 ---

 Key: TUSCANY-1554
 URL: https://issues.apache.org/jira/browse/TUSCANY-1554
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.90
Reporter: Greg Dritschler
Priority: Minor
 Attachments: Tuscany-1554.patch


 A patch is submitted that allows Tuscany's implementation of the 
 WorkScheduler SPI, Jsr237WorkScheduler, to be plug-replaced by another 
 implementation.  The patch uses the mechanism created in revision 564364 
 which allows the implementations of registry objects to be created 
 dynamically based on a metadata file.
 In order to simplify things, I took the position that the WorkManager is now 
 a private implementation detail of the WorkScheduler.  This avoids the need 
 for the dynamic registry object creation mechanism to support a specialized 
 WorkScheduler constructor.  The only use of the WorkManager outside the 
 WorkScheduler was a destroy() call in ReallySmallRuntime.  I moved the 
 destroy() method into the WorkScheduler interface.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Spec Related] 'provides' attribute in PolicySet

2007-08-08 Thread Greg Dritschler

The policy framework spec says the @name attribute is a QName and even gives
an example where the namespace prefix is used:

 intent name=acme:messageProtection

constrains=sca:binding

requires=confidentiality integrity

description

  Protect messages from unauthorized reading or

  modification.

/description

/intent


It is ambiguous to me whether 'acme' can refer to a different namespace than
the targetNamespace.  However in my mind it seems conceptually wrong to
construct a definitions.xml file with a given targetNamespace and then make
definitions for another namespace.

I don't think there's a clear way to define qualifiers in one namespace that
extend intents in another namespace.

Re: NonBlockingInterceptor and transacted oneway invocations

2007-08-06 Thread Greg Dritschler

Oops, I see that
ReferenceBindingProvider2.supportsAsyncOneWayInvocationaccomplishes
what I want to do.  Thanks.

On 8/3/07, Greg Dritschler [EMAIL PROTECTED] wrote:

 A NonBlockingInterceptor is inserted into invocation chains for all oneway
 methods.  This causes a problem when a component invokes a oneway method
 over a binding that supports transactional messaging, such as JMS.  The
 binding must run on the client's thread in order to enlist in the client's
 transaction.  It can't do this because the NonBlockingInterceptor switches
 the invocation off the client's thread to a new thread that doesn't have the
 same transaction context.  It isn't practical or efficient for the
 WorkManager to propagate transaction context to the new thread.

 I think the binding needs to be consulted before the
 NonBlockingInterceptor is added to the chain.  I propose adding a method to
 org.apache.tuscany.sca.assembly.Binding along the lines of
   boolean isOneWayCapable();

 CompositeActivatorImpl would call this method before adding the
 NonBlockingInterceptor to the invocation chain.  It would only add the
 interceptor if the method returned false.

 I think any binding that natively supports oneway messages could return
 true, regardless of whether the message delivery is transacted or not.
 Bindings that do support transacted sends could make a decision based on
 policy.  For example if the default binding were to support transacted
 sends, it could return true if a transacted send is required and false if a
 transacted send is not required and a simple thread switch will do.

 I can submit a patch to support the interface.  I wanted to get some
 feedback first since it does require a minor SPI change.

 Greg

Re: WirePostProcessor needs more context

2007-05-04 Thread Greg Dritschler


On 5/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


More comments inline.

Greg Dritschler wrote:
 Replies within.

 On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 I'm thinking about policy, but why limit it?  Shouldn't it have access
to
 the complete model and sufficient context for where the wire is being
 added
 within the model?

I agree with you, it should have access to the complete model. I was
just trying to understand your scenario. So if it's about policies...

Policies can be specified at many different levels, ComponentTypes,
ConstrainingTypes, Components, Implementations...  I would like to get
people's opinion on:
- Should the policy elements be left where they were initially placed in
the model? you may then have to navigate the model a bit to find them.
- Or do you think it would be useful to merge/combine the policy
definitions from different levels, and prepare pre-compiled lists of
policy definitions at the outmost level
(ComponentService/ComponentReference+Binding for example).



Intents can be specified all over the place so combining them would be
helpful.  One problem is knowing which intent qualifiers can be combined and
which cannot.  The Policy Framework spec has this example:

 composite requires=confidentiality.transport

   service name=foo /

   reference name=bar

   requires=confidentiality.message/

 /composite
  In this case, both the *confidentiality.transport* *and* the *
confidentiality.message* intent are required for the reference 'bar'.

However the transaction spec now under discussion has mutually exclusive
qualifiers.

 composite requires=propagatesTransaction.true

   service name=foo /

   reference name=bar

   requires=propagatesTransaction.false/

 /composite

In this case only propagatesTransaction.false is required for the reference
bar;  it overrides the qualifier at the composite level.

There is nothing in the intent definition to help distinguish these cases
which makes it difficult to write generic code to combine intents across
levels.





 I understand the problems with the runtime model but I'm not sure
 where you
 are going with it.  I assume you are still going to have builders for
 extensible elements like implementation and binding.  Are you planning
to
 get rid of the builders for other elements like component?  How will the
 runtime objects created by builders be organized with respect to the
 assembly model?

I'd like to avoid the duplication of info and constant navigation
between the two models (as most of the existing builders simply build
the second model from the first one).

I think this can be simplified as follows:
- For model elements that represent extensibility points, Implementation
or Binding for example, we can have the runtime specific Implementation
or Binding model class simply extend the Implementation or Binding
assembly model class, and augment it with the runtime specific info.
- For generic model elements,  Component for example, we can have a
simple field to host runtime and Implementation specific configuration,
like Component.set/getImplementationConfiguration().

This way we don't have to maintain two parallel (and often inconsistent)
hierarchies for everything, and the runtime layer can simply access the
SCA assembly metadata in the base model class or by following a simple
pointer.



I definitely agree with eliminating duplication across models.  I'm not sure
how I feel about polluting the assembly model with runtime artifacts such as
invocation chains.  Most systems I have worked on keep metadata and
implementation objects separate.

[jira] Created: (TUSCANY-1242) Provide a runtime which supports multiple composites

2007-05-03 Thread Greg Dritschler (JIRA)

Provide a runtime which supports multiple composites


 Key: TUSCANY-1242
 URL: https://issues.apache.org/jira/browse/TUSCANY-1242
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Standalone Runtime
Reporter: Greg Dritschler


The current runtime implementations are capable of starting a single composite 
only.  This isn't very usable outside a standalone environment.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1242) Provide a runtime which supports multiple composites

2007-05-03 Thread Greg Dritschler (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Greg Dritschler updated TUSCANY-1242:
-

Attachment: jira.patch

The patch is a first step at providing a Tuscany runtime that supports multiple
composites.

I decided to break the logic in SimpleRuntimeImpl.start into separate methods
for adding a contribution and deploying components. The method signatures are
based on the way the code in SimpleRuntimeImpl.start() currently works.
Clearly these aren't the method signatures we want in the end. However the
code to support the contribution service and to resolve the model discrepancies
is still in progress, so it is difficult to come up with better interfaces
right at this moment.

I also added methods to SimpleRuntimeImpl to support undeploying components and
removing a contribution. Again I expect the signatures to evolve.

I changed DefaultSCARuntime to call the new methods in SimpleRuntimeImpl
appropriately. The names of these two classes perhaps are backwards --
DefaultSCARuntime perhaps should provide the basic runtime infrastructure and
SimpleRuntimeImpl perhaps should be the class that provides a simple runtime
capable of running one contribution. However I decided not to rename things at
this point to make it easier to accept the patch.

Other changes:

* ContributionServiceImpl uses an ArtifactResolver to resolve artifacts in
contributions. The problem is that the default implementation
DefaultArtifactResolver doesn't know how to isolate artifacts by contribution.
As a temporary workaround, I changed ContributionServiceImpl to use a
transient DefaultArtifactResolver during resolution processing. Follow on work
will be needed to work out the correct relationship between the
ContributionService, a Contribution, and an ArtifactResolver.

* BuilderRegistryImpl was using the ComponentManager to keep lists of
SCAObjects and model objects for the deployer to be able to correlate them.
These lists are really a temporary workaround for relating the different
models. Furthermore the lists are transient and don't need to be kept after a
deploy completes. For that reason I moved the lists from the ComponentManager
to the DeploymentContext. I expect the lists will go away altogether when the
model relationship issues are resolved.

* I moved the code which sets up SimpleCompositeContextImpl from
SimpleRuntimeImpl to DefaultSCARuntime. This is something that belongs on the
thread of execution. DefaultSCARuntime knows the application is going to run
on the current thread. SimpleRuntimeImpl shouldn't assume that.

* I removed the tuscanySystem member variable in SimpleRuntimeImpl, which
pointed to the single composite that start() handled before. Since the runtime
has to handle more than one composite, this variable doesn't make sense
anymore. I had to change some of the code that was using tuscanySystem to do
component lookups.

* I removed the use of SimpleRuntimeInfo which didn't seem to be serving much
purpose anymore.

Provide a runtime which supports multiple composites

Key: TUSCANY-1242
URL: https://issues.apache.org/jira/browse/TUSCANY-1242
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Standalone Runtime
Reporter: Greg Dritschler
Attachments: jira.patch

The current runtime implementations are capable of starting a single
composite only. This isn't very usable outside a standalone environment.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WirePostProcessor needs more context

2007-04-30 Thread Greg Dritschler


Replies within.

On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Greg Dritschler wrote:
 The WirePostProcessor is passed a Wire from which it can find the
 source and
 target contract and the source and target URI.  If it needs context
 from the
 SCDL that is not in the contracts, is the processor expected to look
 up the
 URIs in the component manager?  That seems rather indirect.  Since the
 code
 building the wires has the source and target objects, couldn't it just
 pass
 them to the postprocessor?

 Greg Dritschler


Greg,

If I understand correctly, the problem is that o.a.t.spi.wire.Wire
duplicates some of the info already present in the assembly model, and
does not give a way to access the other info that is not duplicated.
What other context do you need? policies? binding info? the
implementation types on both ends of the wire? anything else?



I'm thinking about policy, but why limit it?  Shouldn't it have access to
the complete model and sufficient context for where the wire is being added
within the model?

This is not the first time that we run into this kind of issue. This

seems to be a general design issue in the Tuscany runtime, not just with
wires but also with component implementations and bindings, and I think
that we need two fixes here:
- avoid duplicating most of the assembly model in another incomplete
runtime model (like o.a.t.spi.wire.Wire or
o.a.t.spi.component.AtomicComponent)
- make sure that Tuscany extensions get passed the pointers to the
assembly model so that they get the info they need

I think that the changes that we've started to make to the core runtime
and the SPI work that Raymond and Ant have started will have to address
this.

Thoughts?



I understand the problems with the runtime model but I'm not sure where you
are going with it.  I assume you are still going to have builders for
extensible elements like implementation and binding.  Are you planning to
get rid of the builders for other elements like component?  How will the
runtime objects created by builders be organized with respect to the
assembly model?

--

Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SCARuntime.getComponentContext

2007-04-30 Thread Greg Dritschler


Sebastien,

When I wrote this I was thinking of the recursive composition case.  Let's
say I have a composite with a component A that is initially implemented by a
POJO.  I write some code that uses ComponentContext to get a
ServiceReference to one of its services or references.  Later I decide to
replace component A with a composite implementation that has a matching
component type.  Shouldn't the code I wrote that uses ComponentContext still
work with the services and references exposed by that composite
implementation?

If we ignore the recursive case and just think about independent composites,
then I'm also unsure about the use cases for finding an arbitrary component
context in the SCA domain.  I had been assuming it would be possible for a
client (perhaps non-SCA) to get a ServiceReference to a service exposed by
an arbitrary *top-level* component to invoke it.  I'm not so sure why anyone
would want to ServiceReference to a reference exposed by an arbitrary
top-level component.

I don't understand your comments about the implementation language of the
target.  How does the ComponentContext interface require the target to be a
Java component?

On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Greg Dritschler wrote:
 This is a bit of a nit. It appears that the
 SCARuntime.getComponentContextdoes not work if the given component is
 implemented by another composite.
 For example SCARuntime.getComponentContext(CalculatorServiceComponent)
 returns null when CalculatorServiceComponent has a composite
 implementation.
 component name=CalculatorServiceComponent
 implementation.composite name=foo:InnerCalculatorComposite/
 /component
 Should CompositeComponentImpl implement ComponentContextProvider?


Greg,

Thanks for reporting this. This is the current design. I checked the
spec documents, and I think we're going to have to ask the SCA Java Spec
workgroup to clarify if a ComponentContext is meant to represent any
kind of non-composite component or only Java components, and if a
ComponentContext can represent a composite or not...

On one hand supporting ComponentContexts for composite components seems
required to support what the SCA Java API and Annotation spec says on
line 351:
Non-SCA client code can use the ComponentContext API to perform
operations against a component in an SCA domain.

On the other hand it seems odd - to me at least :) to allow Java code to
sneak in the context of any component to get proxies for its references,
as described on line 798:
getService(ClassB businessInterface, String referenceName) – Returns a
proxy for the reference defined by the current component.

And I find this even more troubling given that references on composite
components represent (through promotion) references declared by inner
non-composite components. So, as an SCA application developer, if I had
an OuterCompositeComponent/sampleReference reference promoting an
InnerJavaComponent/sampleReference, I'm not sure at all which
ComponentContext I should use to getService(BusinessInterface.class
sampleReference)... Should I use the ComponentContext for the
OuterCompositeComponent or the InnerJavaComponent?

Another question is: What will a Java based ComponentContext mean if the
component is a BPEL or C++ component?

I'll follow up with the SCA Java spec workgroup.

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Setting up a Tuscany runtime to run multiple applications

2007-04-30 Thread Greg Dritschler


On 4/24/07, Greg Dritschler [EMAIL PROTECTED] wrote:


I'm also wondering about the code in DeployerImpl.deploy that connects
objects.  It starts as follows:
// Connect components, services and references
ListSCAObject scaObjects = componentManager.getSCAObjects ();



Is it fair to say that the ComponentManager's interfaces to keep a list of
model objects and corresponding SCAObjects is a workaround for the Deployer
to find the objects created by the Builder, and that when we have a better
integration between the runtime and the assembly models that these
interfaces are likely to disappear?

Re: Setting up a Tuscany runtime to run multiple applications

2007-04-27 Thread Greg Dritschler


I've determined that there are a lot of dependencies on having a single
ComponentManager.  DeployerImpl, BuilderRegistryImpl, and
DatabindingModuleActivator assume there is one.  I'm now thinking it would
be simplest to have a single ComponentManager and make it a little smarter
about how it organizes its list of SCAObjects.

On 4/25/07, Greg Dritschler [EMAIL PROTECTED] wrote:



I'm still having difficulty with the cardinality of the
ContributionService and related services (ComponentManager, Deployer) and
have to think about it some more.

SCARuntime.getComponentContext

2007-04-27 Thread Greg Dritschler


This is a bit of a nit.  It appears that the
SCARuntime.getComponentContextdoes not work if the given component is
implemented by another composite.
For example SCARuntime.getComponentContext(CalculatorServiceComponent)
returns null when CalculatorServiceComponent has a composite implementation.
   component name=CalculatorServiceComponent
   implementation.composite name=foo:InnerCalculatorComposite/
   /component
Should CompositeComponentImpl implement ComponentContextProvider?

WirePostProcessor needs more context

2007-04-27 Thread Greg Dritschler


The WirePostProcessor is passed a Wire from which it can find the source and
target contract and the source and target URI.  If it needs context from the
SCDL that is not in the contracts, is the processor expected to look up the
URIs in the component manager?  That seems rather indirect.  Since the code
building the wires has the source and target objects, couldn't it just pass
them to the postprocessor?

Greg Dritschler

Re: Setting up a Tuscany runtime to run multiple applications

2007-04-25 Thread Greg Dritschler


On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

You'll need one instance of ArtifactResolver per application as well.


Is the ArtifactResolver eventually intended to resolve artifacts within a
single contribution (application) only or across contributions in the
domain?  The comments at the top of the interface make me think it is the
latter.  If instead it is the case that it resolves artifacts within a
single contribution only, it isn't clear to me how to set this up since
there seems to be a 1:1 relationship between the ContributionService and the
ArtifactResolver.

I'm also wondering about the code in DeployerImpl.deploy that connects
objects.  It starts as follows:
   // Connect components, services and references
   ListSCAObject scaObjects = componentManager.getSCAObjects();

Since there is one deployer, and the deployer has one component manager,
this says to me that every time a composite is deployed, all registered SCA
objects are going to be connected.  If multiple contributions are deployed
is that what should happen?

Greg Dritschler

Re: Setting up a Tuscany runtime to run multiple applications

2007-04-25 Thread Greg Dritschler


On 4/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

I'm not sure that there's a 1..1 relationship between application and

contribution.

No, there isn't.  In trying to switch terminology from application to
contribution, I mistakenly implied an equivalence which isn't true.  But you
caught the gist of my question anyway.  Thanks.

I'm still having difficulty with the cardinality of the ContributionService
and related services (ComponentManager, Deployer) and have to think about it
some more.

Re: Do annotations on interfaces or superclasses play a role for SCA Java CI?

2007-03-27 Thread Greg Dritschler


Regarding case 2, as far as I know the only place in the Java Common
Annotations spec that touches on the behavior of annotations with respect to
inheritance is chapter 2 on policy annotations.  It says that the rules of
JSR 250 apply.  According to JSR 250 annotations on hidden class members are
ignored.  So if we decided these rules also apply to @Reference, the
@Reference annotation would not be honored.  If your derived class did not
contain setYourService then the @Reference annotation would be honored.

I think this arose in the policy section because some of the security
annotations are similar to those in J2EE3 and the EE3 spec probably
references JSR 250.  Perhaps it should be raised as a spec issue whether the
statements made about this in chapter 2 should be broadened to apply to all
of the annotations.  I haven't tested this extensively but my impression is
that the current tuscany code base complies with at least some of these
rules.

BTW I think the example 2a in section 2.2.1 is wrong with respect to JSR 250
because it claims annotations from hidden members should be processed.

According to the javadoc java.lang.annotation.Inherited applies only to
classes so I don't think it applies in this case.

On 3/26/07, Scott Kurz [EMAIL PROTECTED] wrote:


Raymond,

I've wondered that before too.  Your case 2 would have been answered by
the
SCA spec if the @Reference annotation were defined to be, annotated itself
with:
java.lang.annotation.Inherited.Since it's not annotated, I'm not sure
what to think from the SCA perspective, (though it's clear what the Java
lang perspective is).


On 3/23/07, Raymond Feng [EMAIL PROTECTED] wrote:

 Hi,

 If I have component implementation class like this:

 Case 1:
 public class MyServiceImpl implements MyService {
 private YourService yourService;

 public void setYourService(YourService yourService) {
 this.yourService = yourService;
 }
 }

 public interface MyService {
 @Reference
 void setYourService(YourService yourService);
 }

 Q1: Should yourService be treated as a reference?

 Case 2:
 public class MyServiceImpl extends MyServiceBaseImpl {
 public void setYourService(YourService yourService) {
 super.setYourService(yourService);
 // Do addtional things here
 }
 }

 public class MyServiceBaseImpl {
 protected YourService yourService;

 @Reference
 public void setYourService(YourService yourService) {
 this.yourService = yourService;
 }
 }

 Q2: Should yourService be treated as a reference?

 Am I crazy?

 Thanks,
 Raymond

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to run Tuscany on top of WAS 6.0

2006-12-01 Thread Greg Dritschler


I believe He Yuan's point is the requirement on Java 1.5.  WAS6.0 is Java
1.4.
I will follow up with He Yuan offline.

Greg


On 12/1/06, Jim Marino [EMAIL PROTECTED] wrote:



On Dec 1, 2006, at 6:23 AM, He Yuan Huang wrote:



 Dears,

 Currently, we are working on migrating a SCA IBM Internal (SCA on
 top of
 WPS/WAS) based offering to SCA Public (Tuscany). As we know,
 Tuscany M2
 could be packaged with SCA application and deployed as a WAR. So, I
 think
 it could also be deployed to WAS 6.0. However, I realized that the JDK
 version of WAS 6.0 is not SUN JDK 1.5. Then, how to fix this issue?
 Thanks
 a lot!

We shouldn't be tied to the Sun JDK. Could you please try it with the
IBM JDK (I assume that is what you are using with WAS) and report any
bugs in JIRA so we can fix them?

Jim

 Best Regards,
 York


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Creating proxies (fix for TUSCANY-862)

2006-11-30 Thread Greg Dritschler


I've tried out the suggested fixes and I have run into a big problem.
By proxying the inbound wire of the composite reference, there is no
databinding interceptor in the invocation chain.  This causes
Axis2TargetInvoker to choke.

   Exception java.lang.IllegalArgumentException Exception message: Can't
handle mixed payloads betweem OMElements and other types.

   java.lang.IllegalArgumentException: Can't handle mixed payloads betweem
OMElements and other types.
at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.createOperationClient
(Axis2TargetInvoker.java)
at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(
Axis2TargetInvoker.java:70)
at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke(
Axis2TargetInvoker.java:107)
at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(
InvokerInterceptor.java:44)
at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(
SynchronousBridgingInterceptor.java:41)
at org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(
AbstractInboundInvocationHandler.java:60)
at org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(
JDKInboundInvocationHandler.java:108)

How do we get the databinding transformation into this flow?  The
DatabindingInterceptor currently requires an outbound wire from the client.
Dynamically creating an outbound wire for a non-SCA client and connecting it
to the composite reference sounds like a major piece of work.  Is there a
simpler solution?

Re: Creating proxies (fix for TUSCANY-862)

2006-11-30 Thread Greg Dritschler


I've been using a JSP to test this.  At this point I'm not sure how much
restricting the client to an SCA component helps because the locateService
is still dynamic.  Anyway the spec says locateService is available to
non-SCA clients.

On 11/30/06, Jim Marino [EMAIL PROTECTED] wrote:


This I think highlights a problem with the spec around using
CurrentCompositeContext from unmamanged code in general...a locate
service only returns half of an invocation chain since the source
is not a component and is unmamanged code. Can you describe you
client code, is it a JSP or is it from a component?

Jim

On Nov 30, 2006, at 6:51 AM, Greg Dritschler wrote:

 I've tried out the suggested fixes and I have run into a big problem.
 By proxying the inbound wire of the composite reference, there is no
 databinding interceptor in the invocation chain.  This causes
 Axis2TargetInvoker to choke.

Exception java.lang.IllegalArgumentException Exception
 message: Can't
 handle mixed payloads betweem OMElements and other types.

java.lang.IllegalArgumentException: Can't handle mixed payloads
 betweem
 OMElements and other types.
 at
 org.apache.tuscany.binding.axis2.Axis2TargetInvoker.createOperationCli
 ent
 (Axis2TargetInvoker.java)
 at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(
 Axis2TargetInvoker.java:70)
 at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke(
 Axis2TargetInvoker.java:107)
 at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(
 InvokerInterceptor.java:44)
 at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(
 SynchronousBridgingInterceptor.java:41)
 at
 org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(
 AbstractInboundInvocationHandler.java:60)
 at
 org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(
 JDKInboundInvocationHandler.java:108)

 How do we get the databinding transformation into this flow?  The
 DatabindingInterceptor currently requires an outbound wire from the
 client.
 Dynamically creating an outbound wire for a non-SCA client and
 connecting it
 to the composite reference sounds like a major piece of work.  Is
 there a
 simpler solution?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-940) Test cases for scope, callback, oneway

2006-11-19 Thread Greg Dritschler (JIRA)

Test cases for scope, callback, oneway
--

 Key: TUSCANY-940
 URL: http://issues.apache.org/jira/browse/TUSCANY-940
 Project: Tuscany
  Issue Type: Test
  Components: Java Spec APIs
Affects Versions: Java-Mx
Reporter: Greg Dritschler


Submission of basic integration tests for @Scope, @Callback, @Oneway, and 
@Remotable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-940) Test cases for scope, callback, oneway

2006-11-19 Thread Greg Dritschler (JIRA)

 [ http://issues.apache.org/jira/browse/TUSCANY-940?page=all ]

Greg Dritschler updated TUSCANY-940:


Attachment: itest.zip

 Test cases for scope, callback, oneway
 --

 Key: TUSCANY-940
 URL: http://issues.apache.org/jira/browse/TUSCANY-940
 Project: Tuscany
  Issue Type: Test
  Components: Java Spec APIs
Affects Versions: Java-Mx
Reporter: Greg Dritschler
 Attachments: itest.zip


 Submission of basic integration tests for @Scope, @Callback, @Oneway, and 
 @Remotable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-936) HttpSessionScopeContainer requires a session to exist

2006-11-16 Thread Greg Dritschler (JIRA)

HttpSessionScopeContainer requires a session to exist
-

 Key: TUSCANY-936
 URL: http://issues.apache.org/jira/browse/TUSCANY-936
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core
Affects Versions: Java-Mx
Reporter: Greg Dritschler
Priority: Minor


In M1, the HttpSessionScopeContainer was able to lazy-initialize an HTTP 
session.  (Look at the class LazyHTTPSessionId to see how it worked.)  Now the 
HttpSessionScopeContainer requires a preexisting session.  If a session does 
not exist, a NullPointerException occurs when it tries to look up the instance 
using a null key.

InstanceWrapper ctx = wrappers.get(key);

The problem can be circumvented by creating a session in the web app client.  
JSPs have sessions by default.  Servlets can call getSession(true) to ensure a 
session exists before invoking an SCA component that requires session scope.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-921) wire element in SCDL causes UnrecognizedElementException

2006-11-12 Thread Greg Dritschler (JIRA)

wire element in SCDL causes UnrecognizedElementException
--

 Key: TUSCANY-921
 URL: http://issues.apache.org/jira/browse/TUSCANY-921
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core
Affects Versions: Java-Mx
Reporter: Greg Dritschler


Using a wire element in a composite results in an exception.

org.apache.tuscany.spi.loader.UnrecognizedElementException: 
{http://www.osoa.org/xmlns/sca/1.0}wire
[{http://www.osoa.org/xmlns/sca/1.0}wire]
Context stack trace: [application]
at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90)
at 
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:81)
at 
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:55)
at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:109)
at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:65)
at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:57)
at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:39)
at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at 
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101)
at 
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-922) Target instance is not cached in reference proxy

2006-11-12 Thread Greg Dritschler (JIRA)

Target instance is not cached in reference proxy


 Key: TUSCANY-922
 URL: http://issues.apache.org/jira/browse/TUSCANY-922
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core
Affects Versions: Java-Mx
Reporter: Greg Dritschler
Priority: Minor


The invocation handler and target invoker have code to support caching the 
target instance to avoid doing a container lookup every time the target is 
invoked.  However no code exists to turn caching on.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-923) @Scope(REQUEST) causes ScopeNotFoundException

2006-11-12 Thread Greg Dritschler (JIRA)

@Scope(REQUEST) causes ScopeNotFoundException
---

 Key: TUSCANY-923
 URL: http://issues.apache.org/jira/browse/TUSCANY-923
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core
Affects Versions: Java-Mx
Reporter: Greg Dritschler


Using @Scope(REQUEST) in an implementation class causes the following error 
at build time.

[INFO] 
[INFO] Scope object factory not registered for scope [REQUEST]
[INFO] 
[INFO] Trace
org.apache.tuscany.spi.component.ScopeNotFoundException: Scope object factory 
not registered for scope [REQUEST]
at 
org.apache.tuscany.core.component.scope.ScopeRegistryImpl.getScopeContainer(ScopeRegistryImpl.java:65)
at 
org.apache.tuscany.core.implementation.java.JavaComponentBuilder.build(JavaComponentBuilder.java:75)
at 
org.apache.tuscany.core.implementation.java.JavaComponentBuilder.build(JavaComponentBuilder.java:52)
at 
org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:115)
at 
org.apache.tuscany.core.implementation.composite.CompositeBuilder.build(CompositeBuilder.java:93)
at 
org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:115)
at 
org.apache.tuscany.core.deployer.DeployerImpl.build(DeployerImpl.java:115)
at 
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:81)

RequestScopeObjectFactory is not registering with the ScopeRegistry.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

context propagation

2006-09-27 Thread Greg Dritschler


I see there is a WorkContext interface for local propagation of context
between binding and runtime code and across threads.  Is there anything
equivalent for propagation of context across remote method invocations?  I
had been assuming this would be needed for conversational support, and
hoping it would be made general enough for other things (QOS) to piggyback
on top of it.

Greg Dritschler

adding an interceptor

2006-08-04 Thread Greg Dritschler

I am trying to understand how to add an interceptor to an invocation chain.
It looks like at one point this was accomplished by a implementing a
TargetPolicyBuilder and registering it with the PolicyBuilderRegistry.
However in the current code base it looks to me like the
PolicyBuilderRegistry is no longer instantiated.  Is this broken or has
this been replaced by some other mechanism?

Greg Dritschler


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

68 matches

Mail list logo