[jira] Assigned: (TUSCANY-2041) Repeated nill elements of extended type cause "Parser found unknown element" exception

[Pete Robbins (JIRA)]

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

Pete Robbins reassigned TUSCANY-2041:
-

Assignee: Pete Robbins

> Repeated nill elements of extended type cause "Parser found unknown element" 
> exception
> --
>
> Key: TUSCANY-2041
> URL: https://issues.apache.org/jira/browse/TUSCANY-2041
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: XP SP2, VC7 
>Reporter: Simon Laws
>Assignee: Pete Robbins
> Fix For: Cpp-Next
>
>
> With the schema
> http://www.w3.org/2001/XMLSchema"; 
> targetNamespace="http://www.example.org/AnnonTypes"; 
> xmlns:tns="http://www.example.org/AnnonTypes"; 
> elementFormDefault="qualified">
> 
> 
>   
> 
>  maxOccurs="unbounded">
>   
> 
>   
> 
>   
> 
>   
>   
> 
>   
>  
> 
> And XML
> http://www.example.org/AnnonTypes"; 
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
>  xsi:schemaLocation="http://www.example.org/AnnonTypes 
> AnnonTypes2.xsd ">
>   
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>   

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

Hi Sebastien,

Am yet to look into the Bigbank.  Will do it soon.  But then, I was able to
get the helloworld-ws-secure samples to work with only abstract intents like
authentication, integrity and not custom ones ;-).  The policysets
'appliesTo' was use to target them to specific services / references.

- Venkat

On Feb 12, 2008 8:23 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:

> Venkata Krishnan wrote:
> > Hi,
> >
> > Dealing with the 'appliesTo' attribute in PolicySets has been a subject
> that
> > I ended up discussing on the thread
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27768.html.
>  I
> > have gone forward with a suggestion that Sebastien sounded off on that
> > thread and have committed the changes under r620307.
> >
> > First to set the stage
> > ---
> > - The PolicySets could be defined in various definitions.xml which are
> all
> > read and aggreated for a domain
> > - Each PolicySet defines an 'appliesTo' attribute which is an xpath that
> > specifies the sca artifacts to which this policyset may apply.
> >
> > The problem is about being able to validate the computed or calculated
> > policysets for a binding / implementation using this 'appliesTo'
> attribute.
> >
> >
> > Here is a summary of what's been done.
> > ---
> > - In the contribution read phase, we postpone the reading of composite
> files
> > so that all definitions.xml file contents can all be aggregated
> > - After reading all other kinds of artifacts, we finally read the
> composite
> > files in the contribution.  The composite xml is first read as a xml
> > document and for each PolicySet defined for the domain we run the
> appliesTo
> > xpath against this xml document.  For the nodes returned as result of
> this
> > xpath evaluation, we add an attribute named 'applicablePolicySets' whose
> > value will be the name of the PolicySet in question.  So the read
> composite
> > will now be modified to include this attribute wherever applicable.
> > - The modified composite xml is then passed to the STaX processors for
> the
> > usual parsing and creation of the the assembly model objects.
> > - Then during the computing / calculation of PolicySets for a
> > PolicySetAttachPoint (i.e. a binding or an implementation) the matching
> > policysets are validated against the list that has been made in the
> > 'applicablePolicySets' attribute of the PolicySetAttachPoint.
> >
> > As a result of this our samples now don't define their own intents to
> target
> > specific policysets for specific references / services.  Instead this
> > targeting is achieved by the proper specification of the 'appliesTo'
> > attribute in the PolicySet.
> >
> > Please let me know your thoughts on this.
> >
> > Thanks
> >
> > - Venkat
> >
>
> Looks good to me. I am assuming that 'applicablePolicySets' is a
> transient and calculated attribute used by Tuscany to flow policySet
> info with model elements across the composite reading phases, and not
> exposed to application developers.
>
> Were you able to leverage these changes to simplify the bigbank scenario?
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

On Feb 12, 2008 1:09 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

> Hi Venkat
>
> A question.
>
> snip...
>
> >
> > - In the contribution read phase, we postpone the reading of composite
> > files
> > so that all definitions.xml file contents can all be aggregated
> >
>
> Do you mean all the definitions.xml files in the contribution or all the
> definitions.xml files in the domain?
>
> Simon
>

Hi Simon,

Ok, I should probably say that all definitions.xml in a runtime and that
includes the ones coming from our extensions / runtime and the ones coming
in from the contributions.

- Venkat

Re: Binding-echo-extension failing : missing abstract method getApplicablePolicySets() Fwd: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project

[Venkata Krishnan]

Sure, thanks Sebastien.

On Feb 12, 2008 8:34 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:

> Venkata Krishnan wrote:
> > Thanks.  I will ask Sebastien then :)
>
> I'm an administrator on project Tuscany but:
> - you are not in the Tuscany continuum group
> - I don't have seem to have authority to perform any user admin tasks
>
> Can you ask one of the continuum user administrators, here's the list:
>
> http://vmbuild.apache.org/continuum/security/userlist!show.action?roleName=User+Administrator
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

Yes.   Because we are now computing the 'applicablePolicySets' for various
SCA artifacts and that needs the list of 'all' PolicySets that might be
applicable ever.

- Venkat

On Feb 12, 2008 2:03 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

> On Feb 12, 2008 8:18 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> > On Feb 12, 2008 1:09 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > > Hi Venkat
> > >
> > > A question.
> > >
> > > snip...
> > >
> > > >
> > > > - In the contribution read phase, we postpone the reading of
> composite
> > > > files
> > > > so that all definitions.xml file contents can all be aggregated
> > > >
> > >
> > > Do you mean all the definitions.xml files in the contribution or all
> the
> > > definitions.xml files in the domain?
> > >
> > > Simon
> > >
> >
> > Hi Simon,
> >
> > Ok, I should probably say that all definitions.xml in a runtime and that
> > includes the ones coming from our extensions / runtime and the ones
> coming
> > in from the contributions.
> >
> > - Venkat
> >
>
> So does that mean that all definitions.xml processing has to complete for
> all contributions before any composites are parsed?
>
> Simon
>

Re: Binding-echo-extension failing : missing abstract method getApplicablePolicySets() Fwd: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project

[Venkata Krishnan]

It seems that page is protected from normal users.  It appears blank for me.

- Venkat

On Feb 12, 2008 1:50 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

> Sure, thanks Sebastien.
>
>
> On Feb 12, 2008 8:34 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
> wrote:
>
> > Venkata Krishnan wrote:
> > > Thanks.  I will ask Sebastien then :)
> >
> > I'm an administrator on project Tuscany but:
> > - you are not in the Tuscany continuum group
> > - I don't have seem to have authority to perform any user admin tasks
> >
> > Can you ask one of the continuum user administrators, here's the list:
> >
> > http://vmbuild.apache.org/continuum/security/userlist!show.action?roleName=User+Administrator
> > --
> > Jean-Sebastien
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

[jira] Commented: (TUSCANY-2041) Repeated nill elements of extended type cause "Parser found unknown element" exception

[Pete Robbins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567999#action_12567999
 ] 

Pete Robbins commented on TUSCANY-2041:
---

I checked in  a fix for this into the branch. If you could test it out, and it 
works ok, I'll create a patch for HEAD as well

> Repeated nill elements of extended type cause "Parser found unknown element" 
> exception
> --
>
> Key: TUSCANY-2041
> URL: https://issues.apache.org/jira/browse/TUSCANY-2041
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: XP SP2, VC7 
>Reporter: Simon Laws
>Assignee: Pete Robbins
> Fix For: Cpp-Next
>
>
> With the schema
> http://www.w3.org/2001/XMLSchema"; 
> targetNamespace="http://www.example.org/AnnonTypes"; 
> xmlns:tns="http://www.example.org/AnnonTypes"; 
> elementFormDefault="qualified">
> 
> 
>   
> 
>  maxOccurs="unbounded">
>   
> 
>   
> 
>   
> 
>   
>   
> 
>   
>  
> 
> And XML
> http://www.example.org/AnnonTypes"; 
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
>  xsi:schemaLocation="http://www.example.org/AnnonTypes 
> AnnonTypes2.xsd ">
>   
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>   

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Simon Laws]

On Feb 12, 2008 8:18 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

> On Feb 12, 2008 1:09 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> > Hi Venkat
> >
> > A question.
> >
> > snip...
> >
> > >
> > > - In the contribution read phase, we postpone the reading of composite
> > > files
> > > so that all definitions.xml file contents can all be aggregated
> > >
> >
> > Do you mean all the definitions.xml files in the contribution or all the
> > definitions.xml files in the domain?
> >
> > Simon
> >
>
> Hi Simon,
>
> Ok, I should probably say that all definitions.xml in a runtime and that
> includes the ones coming from our extensions / runtime and the ones coming
> in from the contributions.
>
> - Venkat
>

So does that mean that all definitions.xml processing has to complete for
all contributions before any composites are parsed?

Simon

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi

[Rajini Sivaram (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568011#action_12568011
 ] 

Rajini Sivaram commented on TUSCANY-1293:
-

The first block tries to run bundle.start() on SDO bundles and its dependent 
bundles (EMF). It will throw an exception if one of these bundles could not be 
resolved. There is a testBundle.start() outside the loop which has dependencies 
on SDO (and hence on its dependencies). So if an exception is thrown by the 
loop, the following testBundle.start() will throw an uncaught exception 
,causing the test to fail. I put the code to catch and print the exception from 
the loop rather than fail at the first exception so that all the bundles which 
failed to resolve can be identified in one run, rather than have to rerun after 
fixing one-by-one. The tests shouldn't really throw an exception now anyway, so 
please feel free to remove the try-catch block if you prefer.


The second catch block corresponds to delegation to the parent classloader 
during ClassLoader.loadClass(), and the exception there is deliberately caught 
and ignored (the child classloader loads the class if the parent classloader 
cannot). So the try-catch is necessary, and the exception doesn't reflect a 
failure.

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at 
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.T

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Simon Laws]

snip..

On Feb 12, 2008 8:40 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

> Yes.   Because we are now computing the 'applicablePolicySets' for various
> SCA artifacts and that needs the list of 'all' PolicySets that might be
> applicable ever.
>
>
So, in the code today, how do you know you have reached the point that all
contributions have been added and you can start associating policy sets with
composites? Is the composite processing now in a separate phase independent
of the the contribution processing.

To try and get this clearer in my mind I've written out a part of the
various phases on the wiki [1]. Is there a new phase? Looking at the code I
don't see it.

Simon

[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases

Re: Spring Integration Tests

[Kevin Williams]

Thanks Venkat!  That's the approach I'll take.

On Feb 11, 2008 6:07 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Thanks.  Any addition to the tests will be really helpful.  To get a
> jumpstart you could copy over one of the existing tests and modify it
> deleting / adding classes and resources.
>
> - Venkat
>
>
> On Feb 12, 2008 12:01 AM, Kevin Williams <[EMAIL PROTECTED]> wrote:
>
> > I noticed there are no spring-related tests in the sca/itest folder
> > and I would like to volunteer to add a few.  Does this sound like a
> > good idea?  I would probably need some help setting up the basic
> > structure before adding content.
> >
> > Thanks,
> >
> > --Kevin
> >
>
> > -
> > 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: PolicyHanders

[Venkata Krishnan]

Hi,

Thanks for sharing your thoughts further.  My comments inline.

- Venkat

On Feb 12, 2008 9:51 PM, Greg Dritschler <[EMAIL PROTECTED]> wrote:

> 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.
>

Yes, I understood. :) ..but wanted to see if I could trigger some thoughts /
ideas.


>
>
> > 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.


True and will remain so for users.  Amongst the choices of various
mechanisms that a binding or implementation extension might use to handle
mayProvides intents, I am just about suggesting why not use the PolicySet
mechanism itself.  The fact that the extension uses PolicySets for this is
going to be opaque to users.  Or am I missing a perspective here ?


>
>
> >
> > >
> > > 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 need

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

Hi,

No there isn't a separate phase.  Just that in the current read phase I look
for *.composite files and set those aside in a list without processing them
further.  After all artifacts in the contribution have been read I then read
the list of composite URIs, read them and modify them with the additional
attribute 'applicablePolicySets' and then push it further for the usual
processing.

I see that this is what you have also summarized on the wiki.  I have
assumed that in the section titled "New Policy Processing Phase" should go
the description of what we do now with the composite reading and
augmenting.  I have added that information.  Let me know if your thoughts
for it were otherwise.

I think I might have to change this a bit in the context of multiple
contributions.  Isn't it ?

- Venkat

On Feb 12, 2008 2:41 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

> snip..
>
> On Feb 12, 2008 8:40 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> > Yes.   Because we are now computing the 'applicablePolicySets' for
> various
> > SCA artifacts and that needs the list of 'all' PolicySets that might be
> > applicable ever.
> >
> >
> So, in the code today, how do you know you have reached the point that all
> contributions have been added and you can start associating policy sets
> with
> composites? Is the composite processing now in a separate phase
> independent
> of the the contribution processing.
>
> To try and get this clearer in my mind I've written out a part of the
> various phases on the wiki [1]. Is there a new phase? Looking at the code
> I
> don't see it.
>
> Simon
>
> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases
>

Injecting the SCADomain from the TuscanyServletFilter into itest cases

[Raymond Feng]

Hi,

In the WAR-based Tuscany deployment, the TuscanyServletFilter is responsible 
to start/stop the SCADomain. At this moment, most of our itest cases create 
the SCADomain using SCADomain.newInstance() during the setup. If we run 
itests as a webapp, it ends up with two different domain instances.


To really test the webapp scheme, the itests should use the SCADomain 
created by the TuscanyServletFilter. I propose that we convert the itests 
using the following pattern so that they can be run under both J2SE and 
Webapp.


For the test case:
1) Declare a static field typed by SCADomain
2) Test if it is null before creating a new instance (it will be injected 
under Webapp)


For the runtime:
1) WebAppServletHost will subclass SCADomain so that SCADomain.close() will 
only happen during the TuscanyServletFilter.destroy() and the 
SCADomain.close() statement in itest doesn't really shutdown the domain.
2) The JUnitServletFilter will get the SCADomain attribute from the 
ServletContext and try to inject it into the test case class.


Here is an example of the itest.

public class XYZServiceTestCase extends TestCase {
   private static SCADomain scaDomain; // A static field which can be 
injected

   private MyService service;

   protected void setUp() throws Exception {
   if (scaDomain == null) {
   // J2SE case
   scaDomain = SCADomain.newInstance("XYZ.composite");
   }
   service = scaDomain.getService(MyService.class, "MyComponent");
   }

   protected void tearDown() throws Exception {
   scaDomain.close();
   }
}

What do you guys think?

Thanks,
Raymond 



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

Re: Legacy JMS System suppport

[Venkata Krishnan]

Hi Ant,

How about bringing in some policy handling into our JMS binding ?  We could
pick some non-functional characteristic that is typical with use of
messaging.  I am not sure what that could be - is it message encryption ?

If you can help a bit with the things to be done from the JMS side, I will
take care of all that might need to come from the PolciyFwk side. ?

Thoughts ?

Thanks

- Venkat



On Feb 12, 2008 11:34 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:

> Great, thanks Ant - I shall take a look and see :)
>
> On Feb 12, 2008 6:02 PM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On Feb 12, 2008 4:33 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
> >
> > > Hi All,
> > >
> > > I'm trying to ascertain whether it is possible to specify a policySet
> > > applied to a service which would allow us to replace or augment the
> > > data binding?
> > >
> > > The rationale behind this is that we're trying to use a legacy JMS
> > > system as a binding.jms reference, but the TextMessage payload is
> > > marked up in XML and we don't have the ability to change the
> > > interface/implementation of this system to be able to strip off/pad
> > > the xml as appropriate.
> > >
> > > Is this possible?  Or is there another option that would allow me to
> do
> > > this?
> > >
> > > Cheers,
> > >
> > > Dave.
> > >
> >
> > There's no official way to do what you want, all the JMS binding spec
> says
> > about this is:
> >
> > "231 To support any other type of JMS message, the SCA runtime should
> > provide the means for supplying and identifying alternative data binding
> > behaviors."
> >
> > In early drafts of the spec there was a description of a Message
> processing
> > component that provided this but it got removed. We still have some of
> the
> > code for supporting those early drafts still left in the jms binding
> though
> > and i've just committed a change to make it available again from a
> composite
> > so you could try that to see if it does what you need and help us come
> up
> > with a good way to do this. This current code adds a "messageProcessor"
> > attribute to the JMS binding scdl, that class must implement the
> > MessageProcessor interface which gives access to the JMS message to
> fiddle
> > with the payloads during the invocation. There's a testcase
> demonstrating
> > this at:
> >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/jms/src/main/resources/simple/mpclient.composite
> >
> > This is all completely open to change to architect a better, more
> complete
> > solution, so if you could try this out and provide feed back that would
> be
> > great as this seems like this will be quite a common thing to want to
> do.
> >
> >...ant
> >
>
>
>
> --
> Dave Sowerby MEng MBCS
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Legacy JMS System suppport

[ant elder]

On Feb 12, 2008 4:33 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:

> Hi All,
>
> I'm trying to ascertain whether it is possible to specify a policySet
> applied to a service which would allow us to replace or augment the
> data binding?
>
> The rationale behind this is that we're trying to use a legacy JMS
> system as a binding.jms reference, but the TextMessage payload is
> marked up in XML and we don't have the ability to change the
> interface/implementation of this system to be able to strip off/pad
> the xml as appropriate.
>
> Is this possible?  Or is there another option that would allow me to do
> this?
>
> Cheers,
>
> Dave.
>

There's no official way to do what you want, all the JMS binding spec says
about this is:

"231 To support any other type of JMS message, the SCA runtime should
provide the means for supplying and identifying alternative data binding
behaviors."

In early drafts of the spec there was a description of a Message processing
component that provided this but it got removed. We still have some of the
code for supporting those early drafts still left in the jms binding though
and i've just committed a change to make it available again from a composite
so you could try that to see if it does what you need and help us come up
with a good way to do this. This current code adds a "messageProcessor"
attribute to the JMS binding scdl, that class must implement the
MessageProcessor interface which gives access to the JMS message to fiddle
with the payloads during the invocation. There's a testcase demonstrating
this at:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/jms/src/main/resources/simple/mpclient.composite

This is all completely open to change to architect a better, more complete
solution, so if you could try this out and provide feed back that would be
great as this seems like this will be quite a common thing to want to do.

   ...ant

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

Hi Sebastien,

I have made the changes to the secure-bigbank demo.  Let me know if there is
something that looks odd and not practical in a real world scenario.
Thanks.

- Venkat

On Feb 12, 2008 8:23 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:

> Venkata Krishnan wrote:
> > Hi,
> >
> > Dealing with the 'appliesTo' attribute in PolicySets has been a subject
> that
> > I ended up discussing on the thread
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27768.html.
>  I
> > have gone forward with a suggestion that Sebastien sounded off on that
> > thread and have committed the changes under r620307.
> >
> > First to set the stage
> > ---
> > - The PolicySets could be defined in various definitions.xml which are
> all
> > read and aggreated for a domain
> > - Each PolicySet defines an 'appliesTo' attribute which is an xpath that
> > specifies the sca artifacts to which this policyset may apply.
> >
> > The problem is about being able to validate the computed or calculated
> > policysets for a binding / implementation using this 'appliesTo'
> attribute.
> >
> >
> > Here is a summary of what's been done.
> > ---
> > - In the contribution read phase, we postpone the reading of composite
> files
> > so that all definitions.xml file contents can all be aggregated
> > - After reading all other kinds of artifacts, we finally read the
> composite
> > files in the contribution.  The composite xml is first read as a xml
> > document and for each PolicySet defined for the domain we run the
> appliesTo
> > xpath against this xml document.  For the nodes returned as result of
> this
> > xpath evaluation, we add an attribute named 'applicablePolicySets' whose
> > value will be the name of the PolicySet in question.  So the read
> composite
> > will now be modified to include this attribute wherever applicable.
> > - The modified composite xml is then passed to the STaX processors for
> the
> > usual parsing and creation of the the assembly model objects.
> > - Then during the computing / calculation of PolicySets for a
> > PolicySetAttachPoint (i.e. a binding or an implementation) the matching
> > policysets are validated against the list that has been made in the
> > 'applicablePolicySets' attribute of the PolicySetAttachPoint.
> >
> > As a result of this our samples now don't define their own intents to
> target
> > specific policysets for specific references / services.  Instead this
> > targeting is achieved by the proper specification of the 'appliesTo'
> > attribute in the PolicySet.
> >
> > Please let me know your thoughts on this.
> >
> > Thanks
> >
> > - Venkat
> >
>
> Looks good to me. I am assuming that 'applicablePolicySets' is a
> transient and calculated attribute used by Tuscany to flow policySet
> info with model elements across the composite reading phases, and not
> exposed to application developers.
>
> Were you able to leverage these changes to simplify the bigbank scenario?
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Tuscany web-apps and jUnit dependencies

[Raymond Feng]

+1 on what Sebastien described. In fact, the refactored code already works 
this way.


Thanks,
Raymond

- Original Message - 
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>

To: 
Sent: Monday, February 11, 2008 6:46 PM
Subject: Re: Tuscany web-apps and jUnit dependencies



Simon Nash wrote:

ant elder wrote:

On Feb 8, 2008 8:55 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:



As for the other items, If we have TuscanyServletFilter and

TuscanyTestServletFilter, it would only work for the iTests, as they
have generated web.xml. If we want to have simmilar aproach on our
sample applications, that have real web.xml, how would we do it ?



I already said earlier on the other thread but just to reiterate I don't
think we should use this approach with the samples. They need to be as
simple and clear as possible so they're easy for new users to 
understand.


   ...ant


+1 for keeping the samples as simple as possible.

Is it possible to automate the running of sample tests in a way that
doesn't change the contents of the sample war files?  I'm thinking of
a test framework that starts Tomcat or Jetty, deploys a sample war,
then runs some JUnit tests.  I don't see why this would need any change
to the web.xml in the sample war.

  Simon



My 2c, with my application developer hat on:

My webapp should not have to depend on junit unless I'm packaging test 
cases that need junit.


I don't want any fancy web.xml generator as it'll wipe out the application 
servlets and welcome pages that I'll declare in web.xml.


My application's web.xml should just contain the following:

  tuscany
  
  org.apache.tuscany.sca.host.webapp.TuscanyServletFilter
  


and in that case the TuscanyServletFilter should not open execution of 
test cases under the /junit path.


To enable junit test execution, I should just have to add the following to 
my web.xml:


  tuscany-junit
  
  org.apache.tuscany.sca.whatever.TuscanyJUnitServletFilter
  


Finally, samples should show me how to do what I just described.

--
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: PolicyHanders

[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 

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi

[Kelvin Goodson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568126#action_12568126
 ] 

Kelvin Goodson commented on TUSCANY-1293:
-

I have applied your 2nd patch,  after seeing a clean build in my own 
environment.  I will now seek a continuum build

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi-export-patch.txt, sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at 
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at 
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at 
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157)
> at commo

[jira] Updated: (TUSCANY-1293) SDO does not work with OSGi

[Rajini Sivaram (JIRA)]

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

Rajini Sivaram updated TUSCANY-1293:


Attachment: sdo-osgi-export-patch.txt

I have tried to recreate the problem with IBM JDK 1.4.2, 5.0 and 6.0, and the 
tests work fine with all of them with a clean build.

Based on the errors in continuum, the attached patch explictly exports/imports 
the packages that reported missing classes. I am not sure if they are 
sufficient to fix the test, but it is worth a try.



> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi-export-patch.txt, sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at 
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at 
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at 
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constr

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi

[Kelvin Goodson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568099#action_12568099
 ] 

Kelvin Goodson commented on TUSCANY-1293:
-

So it would seem that the failure is due to 106 repetitions of the same error,  
reported to stdout as ...

Running org.apache.tuscany.sdo.test.osgi.OSGiTestCase
Runs 189, Errors: 106
testBasicsDO(org.apache.tuscany.sdo.test.ChangeSummaryOnDataObjectTestCase): 
org/xml/sax/ext/LexicalHandler
org/xml/sax/ext/LexicalHandler
testBasicsDG(org.apache.tuscany.sdo.test.ChangeSummaryOnDataObjectTestCase): 
org/xml/sax/ext/LexicalHandler
org/xml/sax/ext/LexicalHandler
..
..

investigating

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at 
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at 
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at 
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at 
> sun.reflect.

Re: svn commit: r620763 - in /incubator/tuscany/java/sdo: impl/ impl/src/main/java/org/apache/tuscany/sdo/osgi/ impl/src/main/resources/META-INF/ impl/src/test/java/org/apache/tuscany/sdo/test/osgi/ i

[kelvin goodson]

This commit seems to be causing problems in continuum and elsewhere,  but
not in my env.  See comments in the JIRA (1293) Investigating.


On 12/02/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Author: kelvingoodson
> Date: Tue Feb 12 03:13:53 2008
> New Revision: 620763
>
> URL: http://svn.apache.org/viewvc?rev=620763&view=rev
> Log:
> Fix for TUSCANY-1293
>
> Added:
>
> incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/
> 
> incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java
> (with props)
>
> 
> incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/osgi/
> 
> incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/osgi/ClassLoaderTestCase.java
> (with props)
> 
> incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/osgi/OSGiTestCase.java
> (with props)
> 
> incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/osgi/TestBundleActivator.java
> (with props)
> incubator/tuscany/java/sdo/impl/src/test/resources/osgi/
> incubator/tuscany/java/sdo/impl/src/test/resources/osgi/sdo.impl.mf
>
> incubator/tuscany/java/sdo/impl/src/test/resources/osgi/sdo.osgi.test.mf
> Modified:
> incubator/tuscany/java/sdo/impl/pom.xml
>
> incubator/tuscany/java/sdo/impl/src/main/resources/META-INF/MANIFEST.MF
> incubator/tuscany/java/sdo/lib/src/main/resources/META-INF/MANIFEST.MF
> incubator/tuscany/java/sdo/sdo-api/pom.xml
>
> 
> incubator/tuscany/java/sdo/sdo-api/src/main/java/commonj/sdo/impl/HelperProvider.java
>
> Modified: incubator/tuscany/java/sdo/impl/pom.xml
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/impl/pom.xml?rev=620763&r1=620762&r2=620763&view=diff
>
> ==
> --- incubator/tuscany/java/sdo/impl/pom.xml (original)
> +++ incubator/tuscany/java/sdo/impl/pom.xml Tue Feb 12 03:13:53 2008
> @@ -103,6 +103,13 @@
>  3.2.1
>  
>
> +
> +
> +org.apache.felix
> +org.apache.felix.main
> +1.0.1
> +
> +
> 
>  
>  junit
>
> Added:
> incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java?rev=620763&view=auto
>
> ==
> ---
> incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java
> (added)
> +++
> incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java
> Tue Feb 12 03:13:53 2008
> @@ -0,0 +1,22 @@
> +package org.apache.tuscany.sdo.osgi;
> +
> +import org.osgi.framework.BundleActivator;
> +import org.osgi.framework.BundleContext;
> +
> +import commonj.sdo.impl.HelperProvider;
> +
> +public class SdoBundleActivator implements BundleActivator {
> +
> +
> +   public void start(BundleContext bundleContext) throws Exception {
> +
> +   HelperProvider.setDefaultInstance(this.getClass
> ().getClassLoader());
> +
> +   }
> +
> +   public void stop(BundleContext bundleContext) throws Exception {
> +
> +   }
> +
> +
> +}
>
> Propchange:
> incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java
>
> --
> svn:eol-style = native
>
> Propchange:
> incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/osgi/SdoBundleActivator.java
>
> --
> svn:keywords = Rev Date
>
> Modified:
> incubator/tuscany/java/sdo/impl/src/main/resources/META-INF/MANIFEST.MF
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/impl/src/main/resources/META-INF/MANIFEST.MF?rev=620763&r1=620762&r2=620763&view=diff
>
> ==
> ---
> incubator/tuscany/java/sdo/impl/src/main/resources/META-INF/MANIFEST.MF
> (original)
> +++
> incubator/tuscany/java/sdo/impl/src/main/resources/META-INF/MANIFEST.MF Tue
> Feb 12 03:13:53 2008
> @@ -11,15 +11,19 @@
> Bundle-SymbolicName: org.apache.tuscany.sdo.impl
> Bundle-Version: 1.0.0
> Bundle-Vendor: Apache Software Foundation
> -Require-Bundle: org.eclipse.emf.common,
> +Require-Bundle-FIXME: org.eclipse.emf.common,
>   org.eclipse.emf.ecore,
>   org.eclipse.emf.ecore.change,
>   org.eclipse.emf.ecore.xmi,
>   org.eclipse.xsd,
>   org.apache.tuscany.sdo.spec;visibility:=reexport
> +Import-Package: org.osgi.framework
> Export-Package: commonj.sdo.impl,
>   org.apache.tuscany.sdo,
>   org.apache.tuscany.sdo.helper,
>   org.apache.tuscany.sdo.impl,
>   org.apache.tuscany.sdo.test,

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568085#action_12568085
 ] 

Amita Vadhavkar commented on TUSCANY-1293:
--

I am not clear about 106 outputs , but I see the same failure in [continuum] 
BUILD FAILURE: Apache Tuscany SDO Implementation Project latest mail.
Will you please check the details there?

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at 
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at 
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at 
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at commonj.sdo.impl.HelperProvider.loadImpl

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

[Simon Laws (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568066#action_12568066
 ] 

Simon Laws commented on TUSCANY-1949:
-

There looks like there is a fix required here to property processing. Having 
said that do we need to support import.sdo at all now? In the case of 
interfaces with static SDO typed parameters the runtime will scan contributions 
looking for SDO factories. In the case of dynamic SDO typed parameters it's a 
little more tricky as the runtime doesn't know what to look for. Could we rely 
on an init method on a service implementation to provide the mapping 
programatically rather than having a Tuscany specific extension of  the 
assembly model .

> 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
> Fix For: Java-SCA-Next
>
>
> 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.
>XYZZY
>
>
>  
> If I reorder the elements as shown below then the application works.
>  
>  XYZZY
>
>  
> 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-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4

[Kelvin Goodson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568064#action_12568064
 ] 

Kelvin Goodson commented on TUSCANY-257:


Thanks Amita,  I took a scan of the patch file and it appears good.  The only 
thing I spotted is that we need a new java_1_4 maven profile that does not 
include the new project.

> recently added file Interface2JavaGenerator.java is not compatible with JDK 
> 1.4
> ---
>
> Key: TUSCANY-257
> URL: https://issues.apache.org/jira/browse/TUSCANY-257
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
> Environment: all
>Reporter: Paul Golick
> Fix For: Java-SDO-Next
>
> Attachments: 257.patch, newFiles.jar, 
> patchInterface2JavaGenerator.txt, patchUpdated.txt
>
>
> Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and 
> java.lang.reflect.Type that were added in Java 5 for generics.  It appears 
> that the portion of Interface2JavaGenerator that uses ParameterizedType and 
> Type is not needed for Java 1.4 classes.

-- 
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] Resolved: (TUSCANY-1293) SDO does not work with OSGi

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson resolved TUSCANY-1293.
-

Resolution: Fixed

Thanks for the patch Rajini.

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at 
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at 
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at 
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157)
> at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126)
> at commonj.sdo.impl.HelperProvider.(HelperProvider.java:69)
> at commonj.sdo.help

Relax WS support

[ant elder]

Fyi, i've added a sandbox module [1] to try out support for Relax WS
interfaces and posted to the Tuscany blog with how to use it:
http://apache-tuscany.blogspot.com/2008/02/tuscany-sca-support-for-relax-ws.html

   ...ant

[1] https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/relax-ws/

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568078#action_12568078
 ] 

Amita Vadhavkar commented on TUSCANY-1293:
--

---
Test set: org.apache.tuscany.sdo.test.osgi.OSGiTestCase
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 8.469 sec <<< 
FAILURE!
test(org.apache.tuscany.sdo.test.osgi.OSGiTestCase)  Time elapsed: 8.438 sec  
<<< ERROR!
org.osgi.framework.BundleException: Activator start error.
at org.apache.felix.framework.Felix._startBundle(Felix.java:1580)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1470)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:354)
at 
org.apache.tuscany.sdo.test.osgi.OSGiTestCase.test(OSGiTestCase.java:172)
Caused by: junit.framework.AssertionFailedError: expected:<0> but was:<106>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at 
org.apache.tuscany.sdo.test.osgi.TestBundleActivator.runSDOTests(TestBundleActivator.java:63)
at 
org.apache.tuscany.sdo.test.osgi.TestBundleActivator.start(TestBundleActivator.java:40)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1536)
... 29 more

Please see the exception during mvn

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi

[Kelvin Goodson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568083#action_12568083
 ] 

Kelvin Goodson commented on TUSCANY-1293:
-

Amita,   I get clean build from a clean extraction.  Looking at runSDOTests()  
for your run there ought to be 106 outputs to system.out of TestFalluire 
instances.  Can you take a look at these, and attach to the JIRA please?

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at 
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at 
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at 
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at comm

[jira] Resolved: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4

[Amita Vadhavkar (JIRA)]

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

Amita Vadhavkar resolved TUSCANY-257.
-

Resolution: Fixed

resolved at rev 620782

> recently added file Interface2JavaGenerator.java is not compatible with JDK 
> 1.4
> ---
>
> Key: TUSCANY-257
> URL: https://issues.apache.org/jira/browse/TUSCANY-257
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
> Environment: all
>Reporter: Paul Golick
> Fix For: Java-SDO-Next
>
> Attachments: 257.patch, newFiles.jar, 
> patchInterface2JavaGenerator.txt, patchUpdated.txt
>
>
> Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and 
> java.lang.reflect.Type that were added in Java 5 for generics.  It appears 
> that the portion of Interface2JavaGenerator that uses ParameterizedType and 
> Type is not needed for Java 1.4 classes.

-- 
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: Adding phase-based ordering support for invokers/interceptors in the InvocationChain

[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: 
> 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]
>
>

Legacy JMS System suppport

[Dave Sowerby]

Hi All,

I'm trying to ascertain whether it is possible to specify a policySet
applied to a service which would allow us to replace or augment the
data binding?

The rationale behind this is that we're trying to use a legacy JMS
system as a binding.jms reference, but the TextMessage payload is
marked up in XML and we don't have the ability to change the
interface/implementation of this system to be able to strip off/pad
the xml as appropriate.

Is this possible?  Or is there another option that would allow me to do this?

Cheers,

Dave.

-- 
Dave Sowerby MEng MBCS

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

Re: Legacy JMS System suppport

[Dave Sowerby]

Great, thanks Ant - I shall take a look and see :)

On Feb 12, 2008 6:02 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> On Feb 12, 2008 4:33 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
>
> > Hi All,
> >
> > I'm trying to ascertain whether it is possible to specify a policySet
> > applied to a service which would allow us to replace or augment the
> > data binding?
> >
> > The rationale behind this is that we're trying to use a legacy JMS
> > system as a binding.jms reference, but the TextMessage payload is
> > marked up in XML and we don't have the ability to change the
> > interface/implementation of this system to be able to strip off/pad
> > the xml as appropriate.
> >
> > Is this possible?  Or is there another option that would allow me to do
> > this?
> >
> > Cheers,
> >
> > Dave.
> >
>
> There's no official way to do what you want, all the JMS binding spec says
> about this is:
>
> "231 To support any other type of JMS message, the SCA runtime should
> provide the means for supplying and identifying alternative data binding
> behaviors."
>
> In early drafts of the spec there was a description of a Message processing
> component that provided this but it got removed. We still have some of the
> code for supporting those early drafts still left in the jms binding though
> and i've just committed a change to make it available again from a composite
> so you could try that to see if it does what you need and help us come up
> with a good way to do this. This current code adds a "messageProcessor"
> attribute to the JMS binding scdl, that class must implement the
> MessageProcessor interface which gives access to the JMS message to fiddle
> with the payloads during the invocation. There's a testcase demonstrating
> this at:
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/jms/src/main/resources/simple/mpclient.composite
>
> This is all completely open to change to architect a better, more complete
> solution, so if you could try this out and provide feed back that would be
> great as this seems like this will be quite a common thing to want to do.
>
>...ant
>



-- 
Dave Sowerby MEng MBCS

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

Re: Legacy JMS System suppport

[ant elder]

That would be good, there's probably things we could do for databindings as
hinted by Dave in this thread but to start with section 1.6 of the spec does
define a little:

240 

So how about we get those first few mayProvides going?

   ...ant

On Feb 13, 2008 6:14 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

> Hi Ant,
>
> How about bringing in some policy handling into our JMS binding ?  We
> could
> pick some non-functional characteristic that is typical with use of
> messaging.  I am not sure what that could be - is it message encryption ?
>
> If you can help a bit with the things to be done from the JMS side, I will
> take care of all that might need to come from the PolciyFwk side. ?
>
> Thoughts ?
>
> Thanks
>
> - Venkat
>
>
>
> On Feb 12, 2008 11:34 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
>
> > Great, thanks Ant - I shall take a look and see :)
> >
> > On Feb 12, 2008 6:02 PM, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > On Feb 12, 2008 4:33 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hi All,
> > > >
> > > > I'm trying to ascertain whether it is possible to specify a
> policySet
> > > > applied to a service which would allow us to replace or augment the
> > > > data binding?
> > > >
> > > > The rationale behind this is that we're trying to use a legacy JMS
> > > > system as a binding.jms reference, but the TextMessage payload is
> > > > marked up in XML and we don't have the ability to change the
> > > > interface/implementation of this system to be able to strip off/pad
> > > > the xml as appropriate.
> > > >
> > > > Is this possible?  Or is there another option that would allow me to
> > do
> > > > this?
> > > >
> > > > Cheers,
> > > >
> > > > Dave.
> > > >
> > >
> > > There's no official way to do what you want, all the JMS binding spec
> > says
> > > about this is:
> > >
> > > "231 To support any other type of JMS message, the SCA runtime should
> > > provide the means for supplying and identifying alternative data
> binding
> > > behaviors."
> > >
> > > In early drafts of the spec there was a description of a Message
> > processing
> > > component that provided this but it got removed. We still have some of
> > the
> > > code for supporting those early drafts still left in the jms binding
> > though
> > > and i've just committed a change to make it available again from a
> > composite
> > > so you could try that to see if it does what you need and help us come
> > up
> > > with a good way to do this. This current code adds a
> "messageProcessor"
> > > attribute to the JMS binding scdl, that class must implement the
> > > MessageProcessor interface which gives access to the JMS message to
> > fiddle
> > > with the payloads during the invocation. There's a testcase
> > demonstrating
> > > this at:
> > >
> >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/jms/src/main/resources/simple/mpclient.composite
> > >
> > > This is all completely open to change to architect a better, more
> > complete
> > > solution, so if you could try this out and provide feed back that
> would
> > be
> > > great as this seems like this will be quite a common thing to want to
> > do.
> > >
> > >...ant
> > >
> >
> >
> >
> > --
> > Dave Sowerby MEng MBCS
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>