[jira] Assigned: (TUSCANY-2041) Repeated nill elements of extended type cause Parser found unknown element exception
[ 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 schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.example.org/AnnonTypes; xmlns:tns=http://www.example.org/AnnonTypes; elementFormDefault=qualified element name=Top complexType sequence element name=attribute nillable=true minOccurs=0 maxOccurs=unbounded complexType simpleContent extension base=string attribute name=name type=string use=required/ /extension /simpleContent /complexType /element /sequence /complexType /element /schema And XML tns:Top xmlns:tns=http://www.example.org/AnnonTypes; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.example.org/AnnonTypes AnnonTypes2.xsd tns:attribute name=ABC xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ !--tns:attribute name=DEF xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ tns:attribute name=GHI xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ tns:attribute name=JKL xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance-- /tns:Top When multiple attribute elements are present the following error is reported. SDO_DAS_XML_ParserException Object ( [message:protected] = SDO_DAS_XML::loadFile - Unable to parse the supplied xml file 1 parse error(s) occurred when parsing the file 'AnnonTypes2.xml': 1. Parser found unknown element attribute [string:private] = [code:protected] = 0 [file:protected] = C:\simon\php\workspace\php-branch\phpscripts\chrisdougla s\test.php [line:protected] = 52 [trace:private] = Array ( [0] = Array ( [file] = C:\simon\php\workspace\php-branch\phpscripts\chris douglas\test.php [line] = 52 [function] = loadFile [class] = SDO_DAS_XML [type] = - [args] = Array ( [0] = AnnonTypes2.xml ) ) ) [cause] = ) -- 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 'applicablePolicySets' to PolicySetAttachPoints
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: Binding-echo-extension failing : missing abstract method getApplicablePolicySets() Fwd: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project
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+Administratorhttp://vmbuild.apache.org/continuum/security/userlist%21show.action?roleName=User+Administrator -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
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
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+Administratorhttp://vmbuild.apache.org/continuum/security/userlist%21show.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
[ https://issues.apache.org/jira/browse/TUSCANY-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.example.org/AnnonTypes; xmlns:tns=http://www.example.org/AnnonTypes; elementFormDefault=qualified element name=Top complexType sequence element name=attribute nillable=true minOccurs=0 maxOccurs=unbounded complexType simpleContent extension base=string attribute name=name type=string use=required/ /extension /simpleContent /complexType /element /sequence /complexType /element /schema And XML tns:Top xmlns:tns=http://www.example.org/AnnonTypes; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.example.org/AnnonTypes AnnonTypes2.xsd tns:attribute name=ABC xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ !--tns:attribute name=DEF xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ tns:attribute name=GHI xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ tns:attribute name=JKL xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance-- /tns:Top When multiple attribute elements are present the following error is reported. SDO_DAS_XML_ParserException Object ( [message:protected] = SDO_DAS_XML::loadFile - Unable to parse the supplied xml file 1 parse error(s) occurred when parsing the file 'AnnonTypes2.xml': 1. Parser found unknown element attribute [string:private] = [code:protected] = 0 [file:protected] = C:\simon\php\workspace\php-branch\phpscripts\chrisdougla s\test.php [line:protected] = 52 [trace:private] = Array ( [0] = Array ( [file] = C:\simon\php\workspace\php-branch\phpscripts\chris douglas\test.php [line] = 52 [function] = loadFile [class] = SDO_DAS_XML [type] = - [args] = Array ( [0] = AnnonTypes2.xml ) ) ) [cause] = ) -- 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 'applicablePolicySets' to PolicySetAttachPoints
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
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(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.clinit(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.clinit(ModelFactory.java:41)
at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
at
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
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
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
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 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
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
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
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
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
+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: tuscany-dev@ws.apache.org 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: snip 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: filter filter-nametuscany/filter-name filter-class org.apache.tuscany.sca.host.webapp.TuscanyServletFilter /filter-class /filter 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: filter filter-nametuscany-junit/filter-name filter-class org.apache.tuscany.sca.whatever.TuscanyJUnitServletFilter /filter-class /filter 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
Comments below. On Feb 11, 2008 7:36 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Greg, Thanks for your observations / suggestions. Please see my comments inline. I apologize for making them lengthy in the hope that it would trigger more discussions. - Venkat On Feb 7, 2008 1:33 AM, Greg Dritschler [EMAIL PROTECTED] wrote: I have been looking at the PolicyHandler support for Java implementations and overall I like the direction this is going. I have some comments about it. 1. If a given component/operation has multiple policy sets that are handled by the same PolicyHandler, it appears that one PolicyHandler is created for each such policy set. I wonder if it wouldn't be better to call a given PolicyHandler only once per invocation and give it the full list of policy sets it handles. This may be more efficient depending on the policy (the handler may be able to optimize/combine policies, and it may be able to find conflicts that are beyond the powers of the policy framework). Just to clarify, I did start with PolicyHanlder types classified against the PolicySet name, but later discovered that this is not scalable. Today, the PolicyHandler types are classified against the PolicyModel that they can understand (i.e. WS-Policy or some customer model) and the Intent that they can deal with (i.e authentication or transaction). I feel we might also have to add one more classifier that denotes the QoS infrastructure that the PolicyHandler is capable of working with. While the policy model and intent can be extracted for a PolicySet to find the appropriate PolicyHandler, I am not sure where we can encapsulate this 'specific infrastructure' information. I wasn't suggesting any changes along these lines. I think using model objects and intents is sufficient. So, if it does happen that we have mutliple PolicySets on a wire that point to the same PolicyHandler type, yes it makes sense to do what you suggest. Infact, this turns out to be a necessity for example when we want to configure the Axis2 Config Parameters for binding.ws to say enable authentication AND integrity where each of these could have their own PolicySets. 2. Some intents can be provided without requiring a policy set (these are the intents in the implementation's mayProvides list). Although the PolicyHandler gets registered for an intent, it appears it is only driven if the intent is satisfied by a policy set. It would be nice if it could be driven if the intent appears in the mayProvides list too. +1. At the present moment this is left to how implementation and binding extensions would choose to deal with. I'd prefer that the binding / implementation providers parse the list of required intents and if there are the ones that they 'mayProvide' then suitable PolicySets should be added to the list of PolicySets. Ofcourse the corresponding PolicyHandlers should also be defined and registered. This I feel provide uniformity and extensibility to how policy handling plugs into extensions. Intents in the 'mayProvides' list don't require policy sets. 3. I'm also wondering whether it should be possible to register a PolicyHandler that always gets control regardless of what intents or policy sets are specified. This might be to implement some default behavior. I'm thinking of transactions here. The transaction spec says that the runtime can provide one of the intents by default, but the choice of default is implementation-specific. There's no way to declare the default intent to the policy framework today, so there's no choice but to give control to the transaction handler and let it figure it out. This sounds like something that is left for bindings / implementations to deal with, in the way they might choose to. As I had mentioned in the previous point a cleaner way would be for binding /implementation providers to verify if a default intent needs to be in force and add the corresponding PolicySet to the list of policysets. For example, if an implementation provider parses the requiredIntents and discovers nothing in there related to transaction intent type, then it could add the default transaction PolicySet to the list of policysets. Makes sense or am I missing your point? Intents in the 'mayProvides' list don't require policy sets. 4. The PolicyHandler is provided the target Operation and Message. I wonder if that's enough context. Can the handler works its way up the model (component, etc) if it needs to? I suppose what is 'provided' to the handler depends on the implementation or binding extension and from where it decides to call the handlers. If the handlers are called from the interceptors they can provide any state that is available to them. Or if there is context information that is not going to change across service calls then such information could be
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(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.clinit(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.clinit(ModelFactory.java:41)
at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
at
org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
at
org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.init(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
[jira] Updated: (TUSCANY-1293) SDO does not work with OSGi
[
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.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(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.clinit(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.clinit(ModelFactory.java:41)
at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
at
org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
at
org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.init(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
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
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=620763view=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=620763r1=620762r2=620763view=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 @@
version3.2.1/version
/dependency
+!-- dependencies for OSGi support --
+dependency
+groupIdorg.apache.felix/groupId
+artifactIdorg.apache.felix.main/artifactId
+version1.0.1/version
+/dependency
+
!-- dependencies for test cases --
dependency
groupIdjunit/groupId
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=620763view=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=620763r1=620762r2=620763view=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,
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(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.clinit(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.clinit(ModelFactory.java:41)
at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
at
org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
at
org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.init(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
[jira] Commented: (TUSCANY-1949) import.sdo element is not resolved if it follows a property element
[ https://issues.apache.org/jira/browse/TUSCANY-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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. composite ... component ... property name=p type=xsd:stringXYZZY/property /component dbsdo:import.sdo .../ /composite If I reorder the elements as shown below then the application works. composite ... dbsdo:import.sdo .../ component ... property name=p type=xsd:stringXYZZY/property /component /composite I found the problem in CompositeProcessor. When a property element is found, it calls a method readPropertyValue. This method consumes the property end element so CompositeProcessor won't see it. Since CompositeProcessor does not see the property end element, it does not clear the property method variable. Then when it processes the import.sdo element, it sees the property variable is non-null and mistakenly associates the import.sdo extension with the property instead of with the composite. I was able to work around the problem by clearing the property variable after the readPropertyValue call as shown below. (There are actually two such calls, one for component level and one for composite level, and I cleared it in both cases.) // Read the property value Document value = readPropertyValue(property.getXSDElement(), property.getXSDType(), reader); property.setValue(value); composite.getProperties().add(property); property = null; // **WORKAROUND** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
[ https://issues.apache.org/jira/browse/TUSCANY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[
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.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(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.clinit(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.clinit(ModelFactory.java:41)
at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
at
org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
at
org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.init(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.clinit(HelperProvider.java:69)
at commonj.sdo.helper.XSDHelper.clinit(XSDHelper.java:195)
at
Relax WS support
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
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(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.clinit(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
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(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.clinit(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.clinit(ModelFactory.java:41)
at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
at
org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
at
org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.init(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
[jira] Resolved: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
[ 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
Raymond, Your proposal works for me. On Feb 4, 2008 11:47 AM, Raymond Feng [EMAIL PROTECTED] wrote: Please see my comments below. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Saturday, February 02, 2008 2:09 PM Subject: Re: Adding phase-based ordering support for invokers/interceptors in the InvocationChain Raymond Feng wrote: [snip] As of today, we can add multiple interceptors to the invocation chain, but we cannot control their ordering. Is that a problem? Yes, it's a problem. For example, I had to hack to add the databinding transformation interceptor to be added before the binding/implementation invoker. When more policies are supported, I see a need to provide some simple ordering mechnisim for interceptors. [snip] Do you have a specific use case? Yes. A few: 1) binding/implementation invokers have to be the last one in the invocation chain. 2) for a service wire, service-level policy handlers (such as propategate/suspend transaction) must be called before implementation-level handlers (such as managed/noManagedTransaction, security run-as). 3) if I add a encryption/decryption policy handler, it needs to be invoked after the data transformation interceptor on the client side, and before the data transformation interceptor on the service side. 4) pass-by-value interceptor (if required) should be invoked before the implementation-invoker. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Legacy JMS System suppport
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
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
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 bindingType type=binding.jms 241 alwaysProvides=jms 242 mayProvide=atLeastOnce atMostOnce ordered conversation/ 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]
