SVN Props
The following appear to be missing from etc/svn-props DISCLAIMER = svn:eol-style=native;svn:mime-type=text/plain *.composite = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Rev Date Is there a good reason? If not I'll go add them Simon
Build issue with binding-ejb
I've just checked in some changes to move the sca binding to a separate module and I've messed up the bindng-ejb build in the process. Bear with me for a little while while I sort it out. apologies. Simon
Re: Build issue with binding-ejb
On 8/8/07, Simon Laws [EMAIL PROTECTED] wrote: I've just checked in some changes to move the sca binding to a separate module and I've messed up the bindng-ejb build in the process. Bear with me for a little while while I sort it out. apologies. Simon Ok, so primarily it turned out to be that I have created a runtime dependency on the new binding-sca in a place which should have been a compile time dependency. I've checked in the fix and done a mvn clean, removed the sca artifacts from .m2 and rebuilt and it looks ok now. Sorry about that folks Simon
Re: Distributed SCA Binding
On 8/6/07, Simon Laws [EMAIL PROTECTED] wrote: more comments inline On 8/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Comments inline. Simon Laws wrote: I want to get the distributed version of the SCA Binding up and running again now the new wiring code is done and the SCA Binding is only created when required. We need to create a mechanism to switch off/override the local SCA binding when it's not appropriate and then choose the appropriate distributed binding in place of the local binding. Currently the default SCA Binding model is defined and implemented in o.a.t.s.assembly.The runtime artifacts (providers etc.) for the local SCA Binding are in o.a.t.s.core.runtime. I didn't think that we had two different bindings, distributed and local. I'd like to suggest the following: One SCA binding implementation, packaged as a binding extension, i.e. separate from assembly and core. The assembly module should only retain the SCABinding and SCABindingFactory interfaces. To allow the SCA binding model to be used without dragging its runtime implementation, we'd adopt a layering similar to the WS binding or Java implementation: - binding-sca, the SCA binding model implementation classes - binding-sca-xml, support for reading / writing SCA bindings in SCA assembly XML - binding-sca-xyz, runtime implementation of the SCA binding using technology xyz (axis2, jms, or whatever else we want to use) The SCA binding runtime implementation should be capable of local and remote invocations: - location invocations when the target service exists within the same in memory assembly model - remote invocations when the target service does not exist within the same in memory assembly model because it's in a different classloader, Geronimo module, or even JVM) Finally, I think it would be good if we could start to leverage the WS binding for remote invocations. It'll be more lightweight than JMS and easier to distribute too as it won't rely on a central message queue server. OK, I think this matches with what I want although I hadn't thought of making the model separate from the runtime so I'll go ahead an create binding-sca-xml, binding-sca-axis2, binding-sca-jms to sit alongside the binding-sca and move the current classes to the appropriate places. I'll start to bring up the axis2 code. Not sure about maintaining the JMS support just yet but don't want it to disappear altogether. We need to extend the SCA Binding model to take account of domain topology information. In the current distributed runtime this information is available from the domain but is only dealt with by the CompositeActivator when replacing the SCA Binding with remote bindings when required. I think we can make the SCA Binding a bit smarter and record its local/remote status more directly. The topology information should still be maintained by the domain but it should be accessible by the SCA Binding in a form that, given two components, the SCA Binding can tell whether a local or remote binding is required. I'm planning to make a few small changes to the CompositeBuilder to help with this. The changes will not give you the address of a component/service, but at least will allow you to determine if it's local or remote. I'll post more about this later. I await with bated breath. A remote service SCA Binding needs to advertise the endpoint at which its service is available. Again this is a domain issue and the process for doing this should be managed by the domain through an interface that allows the service name and protocol specific URL to be registered. Yes, I was thinking about a simple address service maintaining: component/service - http://host:port/path Ok, I created an initial interface here a while ago but then went on holiday so haven't done anything with it yet (http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java). I would like the interface implemtation for be invisible from the SCA Binding point of view so the node starts an SCADomain/Runtime with appropriate pointers to the service discovery function. As long as the SCA Binding can see this function it could be implemented as a local file read or a centralized service, or something else, and the SCA Binding won't care but will still be able to access endpoint information. A remote reference SCA Binding need to determine the endpoint at which the remote service is available, by asking the domain for the protocol specific URL given a service name, and configure the physical binding appropriately. If we start with the SCA binding just wrappering the WS binding Axis2 implementation then its easy, we just need to configure it with the
[jira] Commented: (TUSCANY-1512) SCA Binding - Combine local and remote implementations and extend to support ws protocol
[ https://issues.apache.org/jira/browse/TUSCANY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518395 ] Simon Laws commented on TUSCANY-1512: - Following the first step (reorganizing the existing sca binding code) there are some points worth recording I've added a test implementation of SCA binding in assembly-xml to prevent cyclic dependency given the tests that are currently there I Can't get to the BaseArtefactProcessor as it is abstract in assembly-xml so I've copied code for now. There is a separate discussion on this subject [1] I currently maintain two constructors in SCABindingProcessor as somethings required the old form. This is a todo SCA Binding - Combine local and remote implementations and extend to support ws protocol - Key: TUSCANY-1512 URL: https://issues.apache.org/jira/browse/TUSCANY-1512 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Environment: all Reporter: Simon Laws Assignee: Simon Laws From this thread ( http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21186.html) implement - binding-sca, the SCA binding model implementation classes - binding-sca-xml, support for reading / writing SCA bindings in SCAassembly XML - binding-sca-axis2, runtime implementation of the SCA binding using SOAP - binding-sca-jms, park the current JMS SCA Binding code -- 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]
calculator-distributed doesn't work
Hi, I run calculator-distributed from today's svn code, but found it doesn't work. Since it is very new to Tuscany, I would like asking the designer of distributed runtime if latest design is on the fly. Or it is expecting solution from all the developers. Nice day. - Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
Re: Release management for next release, was: SCA 0.92 release?
+1 for Ant. He did a great job with 0.90. Simon Venkata Krishnan wrote: +1 for Ant taking doing the RM since his seasoned hand will help up get things our quickly given the little time we have. Ant, if you are OK with this count me in for any help you might require in this. Thanks. - Venkat On 8/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents- so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Ant, Thanks for reminding us that time is ticking if we want to get another release out this month :) I'd like to nominate you as release manager, if you're ok with it. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extending all Bindings from AbstractBinding
Hi, I just observed that, not all bindings are extending from AbstractBinding though all implement the interface Binding. The AbstractBinding class provides an implementation for the Binding interface and in my opinion should be used by all bindings to avoid duplication of code that implements the BInding interface. I feel the pinch for this now as I am adding a couple of things for policies and seems a bit odd to go an copy over the same things across a dozen classes. Let me know what people feel about this and I can go and fix all the bindings for this. Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calculator-distributed doesn't work
On 8/8/07, shaoguang geng [EMAIL PROTECTED] wrote: Hi, I run calculator-distributed from today's svn code, but found it doesn't work. Since it is very new to Tuscany, I would like asking the designer of distributed runtime if latest design is on the fly. Or it is expecting solution from all the developers. Nice day. - Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. Hi Yep, we commented out the calculator-distributed test case as we are changing the underlying sca binding implementation (to work with the new wiring model). Having said that if you are interested in getting involved in bringing it back up again then you are more than welcome. I think what we are going to formalize the interfaces that allow the distributed runtime to work (so that we can work from configuration files, as is the case now, or from some more centralized manager) and also allow the sca binding to use web services/soap instead of JMS (which is what it uses now). There has been quite a bit of chat about this recently, for example, [1], [2], [3], and I have been trying to keep up with what people have been saying here [4]. But, while the emphasis is on getting the distributed calculator sample up again with a simple a solution as possible of course there are lots of things we can add so I don't want to give you the impression that it's all a done deal. I.e. plenty of space to get involved if you would like to. Regards Simon [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21263.html [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20810.html [3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20858.html [4] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
using GroboUtils in a maven environment
Can anyone point me to the info for using GroboUtils in a maven environment please? I've googled around and found a couple of change notifications to very old poms that show use of GroboUtils, but they lead me up blind alleys. I guess what I need is the artifactId, groupId and hosting repository of a GroboUtils maven plugin. Regards, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extending all Bindings from AbstractBinding
+1 from me. I think there's a number of places we could do this type of thing and doing so would help with simplifying things and could help with some of the SPI clean up. ...ant On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I just observed that, not all bindings are extending from AbstractBinding though all implement the interface Binding. The AbstractBinding class provides an implementation for the Binding interface and in my opinion should be used by all bindings to avoid duplication of code that implements the BInding interface. I feel the pinch for this now as I am adding a couple of things for policies and seems a bit odd to go an copy over the same things across a dozen classes. Let me know what people feel about this and I can go and fix all the bindings for this. Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extending all Bindings from AbstractBinding
On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I just observed that, not all bindings are extending from AbstractBinding though all implement the interface Binding. The AbstractBinding class provides an implementation for the Binding interface and in my opinion should be used by all bindings to avoid duplication of code that implements the BInding interface. I feel the pinch for this now as I am adding a couple of things for policies and seems a bit odd to go an copy over the same things across a dozen classes. Let me know what people feel about this and I can go and fix all the bindings for this. Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I like the idea but it gives me a problem with the sca binding. Adding it to SCABinding would imply a cyclic dependency as AbstractBinding is implemented in ExtensionHelper (as putting it in the SPI would imply and SPI change I guess) which in turn depends on quite a lot of other stuff. If we could separate out AbstractBinding somehow it would work for me. Maybe needs to wait until our SPI sweep. +1 to using it where ever it can safely be used. Simon
Re: Extending all Bindings from AbstractBinding
The ExtensionHelper module was originally intended as just an interim thing while we were sorting out the SPIs anyway, so if we go ahead with this its fine to move those abstract classes into the SPI module. Just adding something new to the SPI module seems fine to me as its not going to break anything so I'm still +1 on doing this. ...ant On 8/8/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I just observed that, not all bindings are extending from AbstractBinding though all implement the interface Binding. The AbstractBinding class provides an implementation for the Binding interface and in my opinion should be used by all bindings to avoid duplication of code that implements the BInding interface. I feel the pinch for this now as I am adding a couple of things for policies and seems a bit odd to go an copy over the same things across a dozen classes. Let me know what people feel about this and I can go and fix all the bindings for this. Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I like the idea but it gives me a problem with the sca binding. Adding it to SCABinding would imply a cyclic dependency as AbstractBinding is implemented in ExtensionHelper (as putting it in the SPI would imply and SPI change I guess) which in turn depends on quite a lot of other stuff. If we could separate out AbstractBinding somehow it would work for me. Maybe needs to wait until our SPI sweep. +1 to using it where ever it can safely be used. Simon
Re: Extending all Bindings from AbstractBinding
Ant, just what I was wanting to mention - you beat me to it. I really think additions may not be a disturbance to the SPIs. This could be a start to looking at how much of the extension-helper we could start moving into the SPIs. But am a bit curious about where this sort of thing will go into the SPI. Do we intend another package org.apache.tuscany.sca.assembly in the spi module ? Thanks - Venkat On 8/8/07, ant elder [EMAIL PROTECTED] wrote: The ExtensionHelper module was originally intended as just an interim thing while we were sorting out the SPIs anyway, so if we go ahead with this its fine to move those abstract classes into the SPI module. Just adding something new to the SPI module seems fine to me as its not going to break anything so I'm still +1 on doing this. ...ant On 8/8/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I just observed that, not all bindings are extending from AbstractBinding though all implement the interface Binding. The AbstractBinding class provides an implementation for the Binding interface and in my opinion should be used by all bindings to avoid duplication of code that implements the BInding interface. I feel the pinch for this now as I am adding a couple of things for policies and seems a bit odd to go an copy over the same things across a dozen classes. Let me know what people feel about this and I can go and fix all the bindings for this. Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I like the idea but it gives me a problem with the sca binding. Adding it to SCABinding would imply a cyclic dependency as AbstractBinding is implemented in ExtensionHelper (as putting it in the SPI would imply and SPI change I guess) which in turn depends on quite a lot of other stuff. If we could separate out AbstractBinding somehow it would work for me. Maybe needs to wait until our SPI sweep. +1 to using it where ever it can safely be used. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1515) The JavaBeansDataBinding does not provide an exception handler
The JavaBeansDataBinding does not provide an exception handler -- Key: TUSCANY-1515 URL: https://issues.apache.org/jira/browse/TUSCANY-1515 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next Environment: svn revision 563847 Reporter: Matthew Sykes Priority: Minor Fix For: Java-SCA-Next The DefaultDataBindingExtensionPoint does explicitly omits classes that extend java.lang.Throwable from being associated with the JavaBeansDataBinding. Without an association with the JavaBeansDataBinding (or some other default databinding), fault transformations from POJO exceptions to some other databinding do not occur as the transformation chain can't be established. The symptom of this is a new TransformationException(Target fault type cannot be resolved) getting thrown from the DataTransformationInterceptor. After removing the code in the DefaultDataBindingExtensionPoint that explicitly omits java.lang.Throwable classes from being associated with the JavaBeansDataBinding, an ExceptionHandler needed to be created for the JavaBeansDataBinding. An initial, naive implementation is attached as a patch. This implementation will simply act as a holder of the original exception and return it on createException. With these changes the Exception2ExceptionTransformer was able to establish a transformation from the JavaBeansDataBinding to a custom DataBinding implementation. Further work may be needed in the exception handler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1515) The JavaBeansDataBinding does not provide an exception handler
[ https://issues.apache.org/jira/browse/TUSCANY-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Sykes updated TUSCANY-1515: --- Attachment: javabeans-exception-handler.diff Patch to allow the JavaBeansDataBinding to be associated with faults when no other databinding is associated. The JavaBeansDataBinding does not provide an exception handler -- Key: TUSCANY-1515 URL: https://issues.apache.org/jira/browse/TUSCANY-1515 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next Environment: svn revision 563847 Reporter: Matthew Sykes Priority: Minor Fix For: Java-SCA-Next Attachments: javabeans-exception-handler.diff The DefaultDataBindingExtensionPoint does explicitly omits classes that extend java.lang.Throwable from being associated with the JavaBeansDataBinding. Without an association with the JavaBeansDataBinding (or some other default databinding), fault transformations from POJO exceptions to some other databinding do not occur as the transformation chain can't be established. The symptom of this is a new TransformationException(Target fault type cannot be resolved) getting thrown from the DataTransformationInterceptor. After removing the code in the DefaultDataBindingExtensionPoint that explicitly omits java.lang.Throwable classes from being associated with the JavaBeansDataBinding, an ExceptionHandler needed to be created for the JavaBeansDataBinding. An initial, naive implementation is attached as a patch. This implementation will simply act as a holder of the original exception and return it on createException. With these changes the Exception2ExceptionTransformer was able to establish a transformation from the JavaBeansDataBinding to a custom DataBinding implementation. Further work may be needed in the exception handler. -- 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-1006) ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe
[ https://issues.apache.org/jira/browse/TUSCANY-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518496 ] Kelvin Goodson commented on TUSCANY-1006: - Before we get too far down the line with using the backport ConcurrentHashMap I have finally been able to access a page that refers to a license and I think there may be an issue Info from http://www.mvnrepository.com/artifact/backport-util-concurrent/backport-util-concurrent/3.0 maven artifacts are available from maven repo at http://ibiblio.org/pub/packages/maven2/backport-util-concurrent/backport-util-concurrent/ the jars there do not contain license files but the web page says the license is http://creativecommons.org/licenses/publicdomain this license isn't directly mentioned in http://people.apache.org/~cliffs/3party.html and the discussion in http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200610.mbox/[EMAIL PROTECTED] doesn't lead me to a firm conclusion either, but it certainly doesn't give me a warm feeling ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe -- Key: TUSCANY-1006 URL: https://issues.apache.org/jira/browse/TUSCANY-1006 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-beta1 Environment: Sun JDK 1.4.2_11, 2-CPU server Reporter: Ron Gavlin Priority: Critical Fix For: Java-SDO-beta1 I have an application in which multiple threads access a shared ChangeSummaryImpl. Each thread invokes ChangeSummaryImpl.getOldValues() repeatedly. This causes one or more of the threads to enter an infinite while (true) - loop in HashMap.get(Object) with the following stack trace: HashMap.get(Object) line: 323 ChangeSummaryImpl.getOldValues(DataObject) line: 481 ... I suspect this occurs because the access to HashMap cachedSDOObjectChanges is not synchronized. I have been unable as of yet to create a simple test case that demonstrates the problem. In the meantime, I will try to implement a short-term fix by changing line 93 of ChangeSummaryImpl from protected HashMap cachedSDOObjectChanges = new HashMap(); to protected Map cachedSDOObjectChanges = Collections.synchronizedMap(new HashMap()); I will let you know if that fixes the problem. Any insight or assistance you can offer concerning this problem is appreciated. This is a show-stopper problem for us. Regards, - Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer
[
https://issues.apache.org/jira/browse/TUSCANY-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Yoder updated TUSCANY-1376:
---
Attachment: TUSCANY-1376v2.txt
Updated patch to address windows compilation issue.
C++ SDO spec portability: RefCountingPointer
Key: TUSCANY-1376
URL: https://issues.apache.org/jira/browse/TUSCANY-1376
Project: Tuscany
Issue Type: Bug
Components: C++ SDO, C++ Specification
Affects Versions: Cpp-M3
Environment: all platforms
Reporter: Michael Yoder
Fix For: Cpp-Next
Attachments: TUSCANY-1376.txt, TUSCANY-1376v2.txt
Tuscany C++ SDO class RefCounting pointer has the member function:
operator T*() {return pointee;}
which expose the raw dumb pointer for SDO classes (for the common use of
smart pointers). This member function is used by SCA, and raises undesirable
object lifetime and allowed operation issues. The member function should be
replaced with a safe (referenced in the below -email thread) conversion to
bool member function.
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Friday, June 22, 2007 6:16 AM
To: tuscany-dev@ws.apache.org
Subject: Re: C++ SDO spec portability: RefCountingPointer
Michael, I strongly suspect that the operator T*() ws put in for a good
reason. It may be a good idea to remove this but it may be non-trivial.
The ostream operator is very useful and there is a default implementation
in RefCountingObject so that objects inheriting from RefCounting object do
not need to implement anything... but they can if appropriate.
You are raising a lot if issues which is great and it would be excellent to
get Tuscany SDO up to 2.1 spec level. I suspect there will be hundreds of
issues some of which may require large re-writes/refactoring of the Tuscany
SDO Code!! Raising these as Jiras is the best thing to do so we can track
them. Helping fix them by submitting patches would be even better ;-)
Cheers,
On 22/06/07, Michael Yoder [EMAIL PROTECTED] wrote:
Hi,
In looking at C++ SDO portabilty, we found the the Tuscany C++ SDO
class RefCountingPointer has functions used externally by SCA:
operator T*() {return pointee;}
friend std::ostream operator (std::ostream os, const
RefCountingPointerT ptr)
It looks like the conversion to T* function may have been put in
originally as a porting alternative to a member function template, but
may not be needed any more since the member template is now included
outside the #ifdef.
Exposing the dumb pointer is undesirable since it raises object
lifetime issues and allows other unwanted operations. Having a
conversion to bool is convenient however, and can be implemented
safely using a member function pointer trick (see:
http://www.artima.com/cppsource/safebool.html).
The shift operator also seems undesireable since it places a burden on
all classes which use smart pointers to implement toString
functionality.
How does it sound to raise a Jira to have these member functions
removed?
Thanks,
Michael Yoder
Rogue Wave Software - [EMAIL PROTECTED] Software Developer -
HydraSDO
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
--
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]
FW: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer
Hi Pete,
I uploaded an updated patch for TUSCANY-1376 to address the windows
compilation issue.
Michael
Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
HydraSDO
-Original Message-
From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 08, 2007 9:43 AM
To: tuscany-dev@ws.apache.org
Subject: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability:
RefCountingPointer
[
https://issues.apache.org/jira/browse/TUSCANY-1376?page=com.atlassian.ji
ra.plugin.system.issuetabpanels:all-tabpanel ]
Michael Yoder updated TUSCANY-1376:
---
Attachment: TUSCANY-1376v2.txt
Updated patch to address windows compilation issue.
C++ SDO spec portability: RefCountingPointer
Key: TUSCANY-1376
URL:
https://issues.apache.org/jira/browse/TUSCANY-1376
Project: Tuscany
Issue Type: Bug
Components: C++ SDO, C++ Specification
Affects Versions: Cpp-M3
Environment: all platforms
Reporter: Michael Yoder
Fix For: Cpp-Next
Attachments: TUSCANY-1376.txt, TUSCANY-1376v2.txt
Tuscany C++ SDO class RefCounting pointer has the member function:
operator T*() {return pointee;}
which expose the raw dumb pointer for SDO classes (for the common use
of smart pointers). This member function is used by SCA, and raises
undesirable object lifetime and allowed operation issues. The member
function should be replaced with a safe (referenced in the below -email
thread) conversion to bool member function.
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Friday, June 22, 2007 6:16 AM
To: tuscany-dev@ws.apache.org
Subject: Re: C++ SDO spec portability: RefCountingPointer Michael, I
strongly suspect that the operator T*() ws put in for a good reason.
It may be a good idea to remove this but it may be non-trivial.
The ostream operator is very useful and there is a default
implementation in RefCountingObject so that objects inheriting from
RefCounting object do not need to implement anything... but they can if
appropriate.
You are raising a lot if issues which is great and it would be
excellent to get Tuscany SDO up to 2.1 spec level. I suspect there
will be hundreds of issues some of which may require large
re-writes/refactoring of the Tuscany SDO Code!! Raising these as Jiras
is the best thing to do so we can track them. Helping fix them by
submitting patches would be even better ;-) Cheers, On 22/06/07, Michael
Yoder [EMAIL PROTECTED] wrote:
Hi,
In looking at C++ SDO portabilty, we found the the Tuscany C++ SDO
class RefCountingPointer has functions used externally by SCA:
operator T*() {return pointee;}
friend std::ostream operator (std::ostream os, const
RefCountingPointerT ptr)
It looks like the conversion to T* function may have been put in
originally as a porting alternative to a member function template,
but may not be needed any more since the member template is now
included outside the #ifdef.
Exposing the dumb pointer is undesirable since it raises object
lifetime issues and allows other unwanted operations. Having a
conversion to bool is convenient however, and can be implemented
safely using a member function pointer trick (see:
http://www.artima.com/cppsource/safebool.html).
The shift operator also seems undesireable since it places a burden
on all classes which use smart pointers to implement toString
functionality.
How does it sound to raise a Jira to have these member functions
removed?
Thanks,
Michael Yoder
Rogue Wave Software - [EMAIL PROTECTED] Software Developer -
HydraSDO
- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1438) Change TuscanySCA Native build system to use ant
[ https://issues.apache.org/jira/browse/TUSCANY-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson updated TUSCANY-1438: --- Attachment: README_ANT_INSTALL.txt Uploading a README that explains how to install ANT to compile Tuscany. Change TuscanySCA Native build system to use ant Key: TUSCANY-1438 URL: https://issues.apache.org/jira/browse/TUSCANY-1438 Project: Tuscany Issue Type: Improvement Components: C++ SCA Affects Versions: Cpp-Next Environment: all platforms Reporter: Brady Johnson Priority: Minor Fix For: Cpp-Next Attachments: README_ANT_INSTALL.txt, samples.CppBigBank.build.xml, tuscany_patch_update2_jira1438, tuscany_patch_update3_jira1438, tuscany_patch_update4_jira1438, tuscany_patch_update5_jira1438, tuscany_patch_update6_jira1438, tuscany_patch_update7_jira1438, tuscany_patch_update8_jira1438, TuscanySCANative.ant.display.system, tuscanySCAnative_ant.tar.gz, tuscanySCAnative_ant_update1.tar.gz In an effort to simplify the build process, I would like to propose switching over to use ant instead of automake. It will be much easier to maintain, and is used by many more developers today than automake. Per a request by Pete Robbins to show what the build scripts would look like for cpp/sca/runtime/core, I will attach a patch with the build infrastructure to build, link, and install said library. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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: SCA 0.92 release?
Hi all, could the WSDL on fly generation make it to the next (August) release of Tuscany? It would be very useful for us if it did. Thanks, Radim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1509) Change TuscanySDO Native build system to use ant
[ https://issues.apache.org/jira/browse/TUSCANY-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson updated TUSCANY-1509: --- Attachment: README_ANT_INSTALL.txt Uploading a README that explains how to install ANT to compile Tuscany. Change TuscanySDO Native build system to use ant Key: TUSCANY-1509 URL: https://issues.apache.org/jira/browse/TUSCANY-1509 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-M3 Environment: All platforms Reporter: Brady Johnson Fix For: Cpp-Next Attachments: build.xml, README_ANT_INSTALL.txt, tuscanySDONative_ant.jar In an effort to simplify the build process, I would like to propose switching over to use ant instead of automake. It will be much easier to maintain, and is used by many more developers today than automake. I have already converted most of TuscanySCA to ant. I based this SDO build system on the SCA build system. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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]
[SCA/SDO Native] README for installing ant
Hello all, I uploaded an ant install readme for the SCA and SDO JIRA that deal with ant for Tuscany Native. https://issues.apache.org/jira/browse/TUSCANY-1438(SCA) https://issues.apache.org/jira/browse/TUSCANY-1509(SDO) Can someone please submit that to the SCA and SDO code bases please. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1006) ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe
[ https://issues.apache.org/jira/browse/TUSCANY-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518509 ] Kelvin Goodson commented on TUSCANY-1006: - Thanks Ron, I'll take a look at the attributions in their LICENSE files. ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe -- Key: TUSCANY-1006 URL: https://issues.apache.org/jira/browse/TUSCANY-1006 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-beta1 Environment: Sun JDK 1.4.2_11, 2-CPU server Reporter: Ron Gavlin Priority: Critical Fix For: Java-SDO-beta1 I have an application in which multiple threads access a shared ChangeSummaryImpl. Each thread invokes ChangeSummaryImpl.getOldValues() repeatedly. This causes one or more of the threads to enter an infinite while (true) - loop in HashMap.get(Object) with the following stack trace: HashMap.get(Object) line: 323 ChangeSummaryImpl.getOldValues(DataObject) line: 481 ... I suspect this occurs because the access to HashMap cachedSDOObjectChanges is not synchronized. I have been unable as of yet to create a simple test case that demonstrates the problem. In the meantime, I will try to implement a short-term fix by changing line 93 of ChangeSummaryImpl from protected HashMap cachedSDOObjectChanges = new HashMap(); to protected Map cachedSDOObjectChanges = Collections.synchronizedMap(new HashMap()); I will let you know if that fixes the problem. Any insight or assistance you can offer concerning this problem is appreciated. This is a show-stopper problem for us. Regards, - Ron -- 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: FW: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer
Patch applied. Thanks for that... and for taking care of the affected
SCA source.
Cheers,
On 08/08/2007, Michael Yoder [EMAIL PROTECTED] wrote:
Hi Pete,
I uploaded an updated patch for TUSCANY-1376 to address the windows
compilation issue.
Michael
Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
HydraSDO
-Original Message-
From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 08, 2007 9:43 AM
To: tuscany-dev@ws.apache.org
Subject: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability:
RefCountingPointer
[
https://issues.apache.org/jira/browse/TUSCANY-1376?page=com.atlassian.ji
ra.plugin.system.issuetabpanels:all-tabpanel ]
Michael Yoder updated TUSCANY-1376:
---
Attachment: TUSCANY-1376v2.txt
Updated patch to address windows compilation issue.
C++ SDO spec portability: RefCountingPointer
Key: TUSCANY-1376
URL:
https://issues.apache.org/jira/browse/TUSCANY-1376
Project: Tuscany
Issue Type: Bug
Components: C++ SDO, C++ Specification
Affects Versions: Cpp-M3
Environment: all platforms
Reporter: Michael Yoder
Fix For: Cpp-Next
Attachments: TUSCANY-1376.txt, TUSCANY-1376v2.txt
Tuscany C++ SDO class RefCounting pointer has the member function:
operator T*() {return pointee;}
which expose the raw dumb pointer for SDO classes (for the common use
of smart pointers). This member function is used by SCA, and raises
undesirable object lifetime and allowed operation issues. The member
function should be replaced with a safe (referenced in the below -email
thread) conversion to bool member function.
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Friday, June 22, 2007 6:16 AM
To: tuscany-dev@ws.apache.org
Subject: Re: C++ SDO spec portability: RefCountingPointer Michael, I
strongly suspect that the operator T*() ws put in for a good reason.
It may be a good idea to remove this but it may be non-trivial.
The ostream operator is very useful and there is a default
implementation in RefCountingObject so that objects inheriting from
RefCounting object do not need to implement anything... but they can if
appropriate.
You are raising a lot if issues which is great and it would be
excellent to get Tuscany SDO up to 2.1 spec level. I suspect there
will be hundreds of issues some of which may require large
re-writes/refactoring of the Tuscany SDO Code!! Raising these as Jiras
is the best thing to do so we can track them. Helping fix them by
submitting patches would be even better ;-) Cheers, On 22/06/07, Michael
Yoder [EMAIL PROTECTED] wrote:
Hi,
In looking at C++ SDO portabilty, we found the the Tuscany C++ SDO
class RefCountingPointer has functions used externally by SCA:
operator T*() {return pointee;}
friend std::ostream operator (std::ostream os, const
RefCountingPointerT ptr)
It looks like the conversion to T* function may have been put in
originally as a porting alternative to a member function template,
but may not be needed any more since the member template is now
included outside the #ifdef.
Exposing the dumb pointer is undesirable since it raises object
lifetime issues and allows other unwanted operations. Having a
conversion to bool is convenient however, and can be implemented
safely using a member function pointer trick (see:
http://www.artima.com/cppsource/safebool.html).
The shift operator also seems undesireable since it places a burden
on all classes which use smart pointers to implement toString
functionality.
How does it sound to raise a Jira to have these member functions
removed?
Thanks,
Michael Yoder
Rogue Wave Software - [EMAIL PROTECTED] Software Developer -
HydraSDO
- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy Attachments Resolution in the Assembly Model
[snip] Venkata Krishnan wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks Here's a simple change to make this cleaner: Instead of URLArtifactProcessor.getType() returning .composite for *.composite files definition.xml for definition.xml files URLArtifactProcessor.getType() could return *.composite for *.composites files definitions.xml for definition.xml Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy Attachments Resolution in the Assembly Model
Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Not sure i got this right, but are you asking for the ability to register artifactProcessors by fileName as well as extension ? On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks - Venkat On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Now that I have the basic policy model in place I am trying to link up this with the assembly model now. The policy intents and policy sets applicable for a domain are defined in the definitions.xml. There is a SCADefinitions processor that deals with reading and resolving the intents and policysets in the definitions.xml. The SCADefinitions processor has a model resolver into which the the various policy intents and policy sets that are read get added. All of this is a part of the policy-xml module. Now looking into the aspect of dealing with the 'attachments' of policy intents and policy sets into various SCA constructs, I see there is a need to resolve the intents and policysets with those that have been read from the definitions.xml. This means an artifact processor such as the CompositeProcessor needs to be passed a resolver that has the various policy intents and policy sets in it. Now the question is, do we assume that we use the same resolver that is used to add up the read sca contructs is used to also add the policy intents and policysets ? or... Going by the discussion in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I am given to understand that its best to keep all of the things related to policies - the processor, the resolver etc. separate from those that we have for the assembly model. If this is the case then the CompositeProcessor, the ConstrainingType Processor etc. all have to be set with the instance of a SCADefinitionsResolver that will be used to resolve to policy related things. Could somebody please help me with some perspectives on which one of the above two is better to follow? Thanks - Venkat I think we can follow the same pattern as implementations, bindings, etc: - In CompositeProcessor.resolve(model, resolver), call resolver.resolveModel(policyToResolve) to resolve an unresolved policy model object, then attach the resolved policy to the composite. - In your policy-xml module, provide a PolicyModelResolver and register it in the ModelResolverExtensionPoint. PolicyModelResolver will handle the resolution of Policy model objects (by qname I guess). Look for CompositeModelResolver for an example of a ModelResolver. -- 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] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
+1 for Ant On 8/8/07, Simon Nash [EMAIL PROTECTED] wrote: +1 for Ant. He did a great job with 0.90. Simon Venkata Krishnan wrote: +1 for Ant taking doing the RM since his seasoned hand will help up get things our quickly given the little time we have. Ant, if you are OK with this count me in for any help you might require in this. Thanks. - Venkat On 8/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents- so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Ant, Thanks for reminding us that time is ticking if we want to get another release out this month :) I'd like to nominate you as release manager, if you're ok with it. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
+1 for the nomination of Ant as the RM. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, August 07, 2007 11:10 AM Subject: Release management for next release, was: SCA 0.92 release? ant elder wrote: On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents- so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Ant, Thanks for reminding us that time is ticking if we want to get another release out this month :) I'd like to nominate you as release manager, if you're ok with it. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
On 8/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92 ? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Ant, Thanks for reminding us that time is ticking if we want to get another release out this month :) I'd like to nominate you as release manager, if you're ok with it. Thoughts? -- Jean-Sebastien Yes I'm ok with it, thanks for all the support. So any advance on the name being 0.95 and the branch being cut end of next week? ...ant
Re: Propose to create a new Tuscany malling list
On 8/7/07, Luciano Resende [EMAIL PROTECTED] wrote: Currently we have couple places that can generate e-mail notification : - Apache Continuum build notifications (sucess/failure) - Traffic stats for Apache Tuscany Blog (daily/weekly) - Traffic stats for Apache Tuscany website (daily/weekly) - etc I don't want to pollute the dev or committ list with these notifications, and thus would like to propose creation of a notification list to forward all these e-mails, and the interested people would subscribe (or look into the archives) and have access to these information. If people are OK with this, I'd contact infra@ and ask for the creation of the new notification list. I'm not sure I understand the need for a new list for this, whats wrong with sending these to the dev or commit lists? Other projects do this, gump notifications generally always go to the dev list. If there's information that could be considered confidential on the analytics reports maybe it should just go to the private list, would be good to at least have the Google Analytics userid/pswd sent to the private list so all ppmc members have access to it. ...ant
Java2WSDL/WSDL2Java tools
Our Java2WSDL and WSDL2Java tools have been a bit neglected and thats starting to get a few comments, so what should we do with these? Is the intention that these are specifically for SDO or should they be more general tools with options to be compatible with all the data binding's that Tuscany SCA supports? The ws binding generating wsdl on the fly seems related to Java2WSDL, do we expect the wsdl be identical whether generated on the fly or from java2wsdl? Should the on the fly generation and java2wsdl tool share any common code? There's also the java/xsd tools on the SDO project, should any of that code get used by the SCA tools when using SDOs? ...ant
Re: Release management for next release, was: SCA 0.92 release?
Comments inline. - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 08, 2007 11:12 AM Subject: Re: Release management for next release, was: SCA 0.92 release? On 8/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92 ? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Ant, Thanks for reminding us that time is ticking if we want to get another release out this month :) I'd like to nominate you as release manager, if you're ok with it. Thoughts? -- Jean-Sebastien Yes I'm ok with it, thanks for all the support. So any advance on the name being 0.95 and the branch being cut end of next week? Thank you for take the responsibility. I believe we are all behind you if you need any help :-). For the release name, I think it should be a 1.0 as discussed on the thread that Sebastien started. Cutting a branch by the end of next week may be too short to contain all the features we desire to have in the 1.0 release. I suggest two options to be explored: 1) Try the maven-release-plugin in sandbox to better understand how it can help reduce the overhead of releasing. 2) We could branch for the 1.0 release to contain the candidate modules and keep doing 1.0 developement in the branch and merge them into the trunk. I'm not sure how feasible it is. Thanks, Raymond ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1516) Possible promotion problem with Tuscany
Possible promotion problem with Tuscany --- Key: TUSCANY-1516 URL: https://issues.apache.org/jira/browse/TUSCANY-1516 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Hasan Muhammad I am experiencing a testcase failure in case of the scenario where a composite file is embedded in another and from the embedded composite we promote a service. I have attached composite files. In the testcases, if we locate a service as such and obtain the location property, the value is correct and is Durham myServiceAnother = context.locateService(MyService.class, MySimpleServiceInRecursiveAnother/MyServiceNew1); assertEquals(Durham,myServiceAnother.getLocation()); But if we locate another service from the parent composite directly as such and obtain the location property, the value is incorrect and is again Durham. myTotalServiceNew= context.locateService(MyTotalService.class, MyTotalServiceNewComponent); assertEquals(Raleigh,myTotalServiceNew.getLocation()); Shouldnt it be Raleigh in the second case since we are accessing the component/service defined in the parent component and not the promoted one from the embedded composite? I dont know where to look but is this a potential wiring problem? I will be attaching the composite files and test case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1516) Possible promotion problem with Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hasan Muhammad updated TUSCANY-1516: Attachment: MyTotalServiceTest.java mySimpleService.composite default.composite Possible promotion problem with Tuscany --- Key: TUSCANY-1516 URL: https://issues.apache.org/jira/browse/TUSCANY-1516 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Hasan Muhammad Attachments: default.composite, mySimpleService.composite, MyTotalServiceTest.java I am experiencing a testcase failure in case of the scenario where a composite file is embedded in another and from the embedded composite we promote a service. I have attached composite files. In the testcases, if we locate a service as such and obtain the location property, the value is correct and is Durham myServiceAnother = context.locateService(MyService.class, MySimpleServiceInRecursiveAnother/MyServiceNew1); assertEquals(Durham,myServiceAnother.getLocation()); But if we locate another service from the parent composite directly as such and obtain the location property, the value is incorrect and is again Durham. myTotalServiceNew= context.locateService(MyTotalService.class, MyTotalServiceNewComponent); assertEquals(Raleigh,myTotalServiceNew.getLocation()); Shouldnt it be Raleigh in the second case since we are accessing the component/service defined in the parent component and not the promoted one from the embedded composite? I dont know where to look but is this a potential wiring problem? I will be attaching the composite files and test case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1516) Possible promotion problem with Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hasan Muhammad updated TUSCANY-1516: Attachment: MyServiceImpl.java MyTotalServiceImpl.java MyTotalService.java I have attached the test interface and implementation classes as well Possible promotion problem with Tuscany --- Key: TUSCANY-1516 URL: https://issues.apache.org/jira/browse/TUSCANY-1516 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Hasan Muhammad Attachments: default.composite, MyServiceImpl.java, mySimpleService.composite, MyTotalService.java, MyTotalServiceImpl.java, MyTotalServiceTest.java I am experiencing a testcase failure in case of the scenario where a composite file is embedded in another and from the embedded composite we promote a service. I have attached composite files. In the testcases, if we locate a service as such and obtain the location property, the value is correct and is Durham myServiceAnother = context.locateService(MyService.class, MySimpleServiceInRecursiveAnother/MyServiceNew1); assertEquals(Durham,myServiceAnother.getLocation()); But if we locate another service from the parent composite directly as such and obtain the location property, the value is incorrect and is again Durham. myTotalServiceNew= context.locateService(MyTotalService.class, MyTotalServiceNewComponent); assertEquals(Raleigh,myTotalServiceNew.getLocation()); Shouldnt it be Raleigh in the second case since we are accessing the component/service defined in the parent component and not the promoted one from the embedded composite? I dont know where to look but is this a potential wiring problem? I will be attaching the composite files and test case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
The policy framework spec says the @name attribute is a QName and even gives an example where the namespace prefix is used: intent name=acme:messageProtection constrains=sca:binding requires=confidentiality integrity description Protect messages from unauthorized reading or modification. /description /intent It is ambiguous to me whether 'acme' can refer to a different namespace than the targetNamespace. However in my mind it seems conceptually wrong to construct a definitions.xml file with a given targetNamespace and then make definitions for another namespace. I don't think there's a clear way to define qualifiers in one namespace that extend intents in another namespace.
Cross-jvm locate service
I am interested in extending the current locate service capability to support the location of services that may be running within the same domain but a separate jvm. The most straightforward approach may be to dynamically create and return a service reference using the same Tuscany runtime elements that now create service references for injection in support of the @reference annotation. Any thoughts or pointers would be appreciated. Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
UnsupportedClassVersionError from sca/itest
I'm seeing an UnsupportedClassVersoinError when I attempt to run the tests in sca/itest. Has anybody seen something similar? (I have revision 563991.) The result is the same whether I attempt to execute mvn from sca/itest or import the project into Eclipse and Run As Junit Test. (I imported into Eclipse as a first trouble shooting measure - I attempted to get around the problem by altering the Java Compiler version for the project.) Some parts of the build are pulled in from repositories. Is it possible that some of those parts were built with an unsuitable version of Java? _ [INFO] Surefire report directory: C:\shonuff\SDO\SourceTrees\Tuscany563514\sca\odules\interface\target\surefire-reports org.apache.maven.surefire.booter.SurefireExecutionException: (org/apache/tuscan/sca/interfacedef/impl/ContractCompatibilityTestCase) bad major version at offst=6; nested exception is java.lang.UnsupportedClassVersionError: (org/apache/tucany/sca/interfacedef/impl/ContractCompatibilityTestCase) bad major version at offset=6 java.lang.UnsupportedClassVersionError: (org/apache/tuscany/sca/interfacedef/iml/ContractCompatibilityTestCase) bad major version at offset=6 at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:228) at java.security.SecureClassLoader.defineClass( SecureClassLoader.java:18)
Re: Tuscany Subproject News Bulletin? Would it be useful?
Thank you all for the good ideas. Trying to summarize this thread. 1) Blogging is an important communication tool - We should all attempt to do this more often. The type of interesting information for blogs would be things that we'd want to communicate instantly. Cool features that are becoming available, actual user use cases, 2) There seems to be a set of things that fall into important information to communicate, but does not quite fit the blog profile (Jeff also points to this). These are things that give a high level view of f where things are and heading to in the project without digging into tons of mail, etc. For example, high level roadmap, pointer to current release discussion, pointer to use cases Mathew suggests a weekly news digest. Although a great idea, it requires a dedicated person on an ongoing basis (since everyone will rely on this ;). What I was proposing is simpler. It is a bulletin board where everyone posts information of type (2) above. I am not sure if we are agreeing that a news bulletin per subproject is worth the effort or not given all the new ideas that were shared on this thread. I could go ahead and start this as an experiment, but its content is dependent on input from everyone. We can try it for a while and evaluate if it is useful or should be removed. I'll wait another day for feedback before I proceed. Thanks, Haleh On 8/7/07, Luciano Resende [EMAIL PROTECTED] wrote: On 8/6/07, Robert Burrell Donkin [EMAIL PROTECTED] wrote: snip i believe now that blog aggregation is the best structure for news. for this to be effective does require a consensus that committers are going to spend a little time regularly blogging about new features. +1, we could have a Tuscany aggregation (e.g individual committers would aggregate into a planetTuscany) plus planetApache aggregation. More technical committer, involved in specific feature, would probably blog around what's going on, new enhancements, etc... Release Managers would probably blog about what's being planned for the release, other could write a weekly summary as Haleh proposed. As for the notification part, or basically to be aware of new items posted, Google Alert is one way to get notified. You could also use other options such as google/ig, feed readers, etc On 8/7/07, Anderson, Jeff T (CA - Toronto) [EMAIL PROTECTED] wrote: I agree that this is a useful feature, you can never put enough effort into making information more accessible, as for the type of information, everything that you've mentioned below is appropriate -plus actual case studies of usage -high-level roadmap items etc., etc. From: haleh mahbod [mailto:[EMAIL PROTECTED] Sent: Mon 2007-08-06 15:31 To: tuscany-dev; Tuscany Users Subject: Tuscany Subproject News Bulletin? Would it be useful? Hi Tuscan Contributors and Users, I have been thinking about how we can further enhance the flow of information in Tuscany. New interesting things happen on regular basis and information is either embedded in an email, in code/commit log, embedded in a webpage on TuscanyWiki or the website. Users of Tuscany may have interesting information to share, but not have a place to share this information. A new person coming to Tuscany may not be able to easily find the information in archive since they don't know what to look for. Users who are tracking the project may not have time to read the details of each email and would probably appreciate finding information quickly. Note that this is not a particular characteristic of Tuscany. It is just the nature of open source projects. Lots of good information to dig into in svn, in mailing list, on websites, etc. Here is a proposal. How about a news bulletin for each subproject that resides on TuscanyWiki and gets linked into from Tuscany website download page. This is a live page, contributed to by all. It is not a replacement for any of the existing communication mechanism. It is a quick pointer to information that will help people find the latest news. For example the SCA bulletin could be: Development bulletin board - Community is working on the next release of project. You can participate in this thread of discussion ML thread if interested.. - There is a quick guide to getting started link here - Major efforts in progress, example OSGI , Integration with Geronimo, . . Use your imagination... Anything that can be shared with the community to help them understand what's going on Users bulletin board - Here is a scenario that SCA is used in and here are some examples to share link to a page that the data is . Use your imagination Anything that can be shared with the community Questions: Do you agree that we should spend effort on further enhancing information flow or there is enough already? If yes, What type
RE: Java2WSDL/WSDL2Java tools
I thought I saw a post recently where someone mentioned that these tools were taken from axis. If so, are we going to maintain a parallel implementation? It might be useful to talk with the axis folks to see if these tools can be refactored in such a way as to easily allow the types of extensions/additions that Tuscany will be doing, thus avoiding duplicate code. On another note: Has anyone ever seen the same tools for C++? If not, maybe we could open another thread to discuss implementing them for TuscanySCA Native. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 08, 2007 12:47 PM To: tuscany-dev Subject: Java2WSDL/WSDL2Java tools Our Java2WSDL and WSDL2Java tools have been a bit neglected and thats starting to get a few comments, so what should we do with these? Is the intention that these are specifically for SDO or should they be more general tools with options to be compatible with all the data binding's that Tuscany SCA supports? The ws binding generating wsdl on the fly seems related to Java2WSDL, do we expect the wsdl be identical whether generated on the fly or from java2wsdl? Should the on the fly generation and java2wsdl tool share any common code? There's also the java/xsd tools on the SDO project, should any of that code get used by the SCA tools when using SDOs? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Subproject News Bulletin? Would it be useful?
On 8/8/07, haleh mahbod [EMAIL PROTECTED] wrote: snip I am not sure if we are agreeing that a news bulletin per subproject is worth the effort or not given all the new ideas that were shared on this thread. I could go ahead and start this as an experiment, but its content is dependent on input from everyone. We can try it for a while and evaluate if it is useful or should be removed. FWIW (in summary) i believe that news is definitely worth the effort but it's easy to underestimate the energy required... MOTWYW - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Propose to create a new Tuscany malling list
ant elder wrote: On 8/7/07, Luciano Resende [EMAIL PROTECTED] wrote: Currently we have couple places that can generate e-mail notification : - Apache Continuum build notifications (sucess/failure) - Traffic stats for Apache Tuscany Blog (daily/weekly) - Traffic stats for Apache Tuscany website (daily/weekly) - etc I don't want to pollute the dev or committ list with these notifications, and thus would like to propose creation of a notification list to forward all these e-mails, and the interested people would subscribe (or look into the archives) and have access to these information. If people are OK with this, I'd contact infra@ and ask for the creation of the new notification list. I'm not sure I understand the need for a new list for this, whats wrong with sending these to the dev or commit lists? Other projects do this, gump notifications generally always go to the dev list. If there's information that could be considered confidential on the analytics reports maybe it should just go to the private list, would be good to at least have the Google Analytics userid/pswd sent to the private list so all ppmc members have access to it. ...ant +1 to what Ant is saying, I'd like to suggest the following: - build notifications go to either the commit or dev list (I have a slight preference for the commit list but am ok with either one) - private stuff goes to the private list -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
I don't think we will be ready to cut a branch for the SCA 1.0 release at the end of next week. However, there's quite a bit of new function that has been added to trunk since we cut the branch for 0.91, so I think having a release quite soon to deliver these improvements is a good idea. I suggest we make the upcoming release a 1.0 beta, with the final 1.0 release following on as the next release after that. Simon Raymond Feng wrote: Comments inline. - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 08, 2007 11:12 AM Subject: Re: Release management for next release, was: SCA 0.92 release? On 8/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92 ? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Ant, Thanks for reminding us that time is ticking if we want to get another release out this month :) I'd like to nominate you as release manager, if you're ok with it. Thoughts? -- Jean-Sebastien Yes I'm ok with it, thanks for all the support. So any advance on the name being 0.95 and the branch being cut end of next week? Thank you for take the responsibility. I believe we are all behind you if you need any help :-). For the release name, I think it should be a 1.0 as discussed on the thread that Sebastien started. Cutting a branch by the end of next week may be too short to contain all the features we desire to have in the 1.0 release. I suggest two options to be explored: 1) Try the maven-release-plugin in sandbox to better understand how it can help reduce the overhead of releasing. 2) We could branch for the 1.0 release to contain the candidate modules and keep doing 1.0 developement in the branch and merge them into the trunk. I'm not sure how feasible it is. Thanks, Raymond ...ant - 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: Cross-jvm locate service
Kevin Williams wrote: I am interested in extending the current locate service capability to support the location of services that may be running within the same domain but a separate jvm. The most straightforward approach may be to dynamically create and return a service reference using the same Tuscany runtime elements that now create service references for injection in support of the @reference annotation. Any thoughts or pointers would be appreciated. Thanks, --Kevin This sounds good to me. I guess you're talking about SCADomain.getService(targetComponentName/targetServiceName). We've been flip-flopping between locateService/getService a few times :) ... Here are a few more thoughts. First here's how SCADomain.getService() currently works: 1. look for the target component model object in the in-memory domain composite kept in SCADomain 2. look for the target service on that component 3. find on that component the self-reference created for that service (these self-references are automatically created by CompositeBuilder for each service provided by a component) 4. create a CallableReference for that self-reference 5. get a proxy to the service from the CallableReference Some pointers to code: [1] and [2] - org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getServiceReference() [3] and [4] - org.apache.tuscany.sca.core.component.ComponentContextImpl.createSelfReference() [5] - org.apache.tuscany.sca.core.component.CallableReferenceImpl Now, when the target component/service runs in a different JVM, you won't have an in-memory model object representing it :( but that's not a big issue :) ... As you suggested you can simply create a local reference and bind it to the target service (assuming you know its binding type and endpoint URI), then proceed to get a CallableReference and a proxy for it as usual. This gives us the following steps: 1. determine the binding type and endpoint URI of the target component/service you're looking for (I won't get into the details of how to do that here, as I think Simon is covering it in his distributed binding implementation) 2. dynamically create a reference for your target service and configure it with that binding and endpoint URI 3. perform steps [4] and [5] from above. For step 2, org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.createSelfReference() shows how to create a reference from a service. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SVN doesn't build.
I've used maven 2.0.5 to build today svn archive and when it does the tests, I have: --- T E S T S --- Running org.apache.tuscany.sca.contribution.services.ContributionMetadataDocumentProcessorTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.038 sec Running org.apache.tuscany.sca.contribution.processor.FolderContributionPackageProcessorTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.136 sec Running org.apache.tuscany.sca.contribution.services.PackageTypeDescriberImplTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.144 sec Running org.apache.tuscany.sca.contribution.resolver.ExtensibleArtifactResolverTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 sec Running org.apache.tuscany.sca.contribution.resolver.ArtifactResolverTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.tuscany.sca.contribution.processor.JarContributionPackageProcessorTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec Running org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.067 sec FAILURE! testStore(org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase) Time elapsed: 0.05 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:158) at org.apache.tuscany.sca.contribution.service.impl.ContributionRepositoryImpl.init(ContributionRepositoryImpl.java:93) at org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase.setUp(ContributionRepositoryTestCase.java:37) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) testRemove(org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase) Time elapsed: 0.001 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:158) at org.apache.tuscany.sca.contribution.service.impl.ContributionRepositoryImpl.init(ContributionRepositoryImpl.java:93) at org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase.setUp(ContributionRepositoryTestCase.java:37) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at
Re: Release management for next release, was: SCA 0.92 release?
We've started talking about an 0.92 release way back on June 30th saying it would be in August. To make this happen takes a minimum of two 3 day votes, past releases show we always need at least 2 release candidates, so to ensure we get a release out in August we need the first RC by about August 22nd, though to be certain this happens in August i'd be more comfortable with allowing time for the possibility of a third RC which means the weekend of 17th/18th - ie. the end of next week. We've said we'd have an August release so i think we should try to make this happen, doesn't matter so much what we call it. What do others think - should we aim for an August release or let it slip a bit to allow more things to get done? ...ant On 8/8/07, Simon Nash [EMAIL PROTECTED] wrote: I don't think we will be ready to cut a branch for the SCA 1.0 release at the end of next week. However, there's quite a bit of new function that has been added to trunk since we cut the branch for 0.91, so I think having a release quite soon to deliver these improvements is a good idea. I suggest we make the upcoming release a 1.0 beta, with the final 1.0 release following on as the next release after that. Simon Raymond Feng wrote: Comments inline. - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 08, 2007 11:12 AM Subject: Re: Release management for next release, was: SCA 0.92 release? On 8/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92 ? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Ant, Thanks for reminding us that time is ticking if we want to get another release out this month :) I'd like to nominate you as release manager, if you're ok with it. Thoughts? -- Jean-Sebastien Yes I'm ok with it, thanks for all the support. So any advance on the name being 0.95 and the branch being cut end of next week? Thank you for take the responsibility. I believe we are all behind you if you need any help :-). For the release name, I think it should be a 1.0 as discussed on the thread that Sebastien started. Cutting a branch by the end of next week may be too short to contain all the features we desire to have in the 1.0 release. I suggest two options to be explored: 1) Try the maven-release-plugin in sandbox to better understand how it can help reduce the overhead of releasing. 2) We could branch for the 1.0 release to contain the candidate modules and keep doing 1.0 developement in the branch and merge them into the trunk. I'm not sure how feasible it is. Thanks, Raymond ...ant - 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: Release management for next release, was: SCA 0.92 release?
Some thoughts inline. ant elder wrote: We've started talking about an 0.92 release way back on June 30th saying it would be in August. To make this happen takes a minimum of two 3 day votes, past releases show we always need at least 2 release candidates, so to ensure we get a release out in August we need the first RC by about August 22nd, though to be certain this happens in August i'd be more comfortable with allowing time for the possibility of a third RC which means the weekend of 17th/18th - ie. the end of next week. +1 for cutting a branch on the 18th We've said we'd have an August release so i think we should try to make this happen, doesn't matter so much what we call it. What do others think - should we aim for an August release or let it slip a bit to allow more things to get done? ...ant +1 for aiming for an August release On 8/8/07, Simon Nash [EMAIL PROTECTED] wrote: I don't think we will be ready to cut a branch for the SCA 1.0 release at the end of next week. However, there's quite a bit of new function that has been added to trunk since we cut the branch for 0.91, so I think having a release quite soon to deliver these improvements is a good idea. I suggest we make the upcoming release a 1.0 beta, with the final 1.0 release following on as the next release after that. Simon +1 for 1.0-beta, I don't think we're ready for a 1.0 final but with everything we've added and fixed recently, 1.0-beta is about right IMO. Raymond Feng wrote: [snip] 1) Try the maven-release-plugin in sandbox to better understand how it can help reduce the overhead of releasing. +1 I'm not a Maven expert but if I remember correctly it has been mentioned several times, so I think we should try. 2) We could branch for the 1.0 release to contain the candidate modules and keep doing 1.0 developement in the branch and merge them into the trunk. I'm not sure how feasible it is. +1 I think it's feasible if doing 1.0 development is about stabilizing the 1.0 release branch, which I guess a release branch is for :) That means: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1496) Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side
[ https://issues.apache.org/jira/browse/TUSCANY-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1496: Attachment: patch1 I am attaching the first stage patch for this change. With this patch, callbacks no longer use callback runtime wires that connect references on the service client side to services on the service provider side, running in parallel with regular runtime wire connections. Instead, callbacks are treated like forward calls and are made using regular runtime wires connecting pseudo-references on the service provider side to pseudo-services on the service client side. This change is compatible with existing bindings that support callbacks (the SCA binding provider and the Web Service binding provider). Beacuse callback wires have been eliminated from the runtime, only the forward call path through these bindings is now executed. I had to make a one-line change to the Web Service binding to make the new code path work. This patch is not the final implementation but a base on which the final implementation can be built. The following work is still needed to complete the callback support: 1. Fix some limitations and bugs that are present in the current code. 2. Remove old code that is no longer needed now that callback wires have been eliminated. As soon as this patch is committed, I will continue with this further work. Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side -- Key: TUSCANY-1496 URL: https://issues.apache.org/jira/browse/TUSCANY-1496 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Attachments: patch1 Please see the ML thread @ http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20555.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1496) Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side
[ https://issues.apache.org/jira/browse/TUSCANY-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1496: Patch Info: [Patch Available] Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side -- Key: TUSCANY-1496 URL: https://issues.apache.org/jira/browse/TUSCANY-1496 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Attachments: patch1 Please see the ML thread @ http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20555.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
Comment inline. Simon Jean-Sebastien Delfino wrote: Some thoughts inline. ant elder wrote: We've started talking about an 0.92 release way back on June 30th saying it would be in August. To make this happen takes a minimum of two 3 day votes, past releases show we always need at least 2 release candidates, so to ensure we get a release out in August we need the first RC by about August 22nd, though to be certain this happens in August i'd be more comfortable with allowing time for the possibility of a third RC which means the weekend of 17th/18th - ie. the end of next week. +1 for cutting a branch on the 18th We've said we'd have an August release so i think we should try to make this happen, doesn't matter so much what we call it. What do others think - should we aim for an August release or let it slip a bit to allow more things to get done? ...ant +1 for aiming for an August release On 8/8/07, Simon Nash [EMAIL PROTECTED] wrote: I don't think we will be ready to cut a branch for the SCA 1.0 release at the end of next week. However, there's quite a bit of new function that has been added to trunk since we cut the branch for 0.91, so I think having a release quite soon to deliver these improvements is a good idea. I suggest we make the upcoming release a 1.0 beta, with the final 1.0 release following on as the next release after that. Simon +1 for 1.0-beta, I don't think we're ready for a 1.0 final but with everything we've added and fixed recently, 1.0-beta is about right IMO. Raymond Feng wrote: [snip] 1) Try the maven-release-plugin in sandbox to better understand how it can help reduce the overhead of releasing. +1 I'm not a Maven expert but if I remember correctly it has been mentioned several times, so I think we should try. 2) We could branch for the 1.0 release to contain the candidate modules and keep doing 1.0 developement in the branch and merge them into the trunk. I'm not sure how feasible it is. +1 I think it's feasible if doing 1.0 development is about stabilizing the 1.0 release branch, which I guess a release branch is for :) That means: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. How soon would we be moving into this mode? I presume it would be after we have released 1.0-beta. Does anyone think it would be sooner than that? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
[snip] Simon Nash wrote: Raymond Feng wrote: [snip] 2) We could branch for the 1.0 release to contain the candidate modules and keep doing 1.0 developement in the branch and merge them into the trunk. I'm not sure how feasible it is. +1 I think it's feasible if doing 1.0 development is about stabilizing the 1.0 release branch, which I guess a release branch is for :) That means: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. How soon would we be moving into this mode? I presume it would be after we have released 1.0-beta. Does anyone think it would be sooner than that? Simon I'm probably missing something in your question :). What I'm describing here is in response to Raymond's question about doing 1.0 development in the branch. The branch in question is the 1.0-beta release branch, used to release 1.0-beta, i.e. *before* it is released. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1 more new component instance per request?
Today, I found in respond to each request, Tuscany instantiate new one class for each. I tried binding.ws, it works as well. SCA1.0 does not specify instance management of a component, but I remember J2EE does not mentioned such things for EJB and servlet, it should be managed by the containers. So here comes my question: is it a good idea to make a great deal of component instances in Tuscany, or we might control it to act as singleton? - Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.
[jira] Created: (TUSCANY-1517) If serviceImpl is pointing to wrong service in @Service annotation, error message should point out to exact problem with serviceImpl/service/operation
If serviceImpl is pointing to wrong service in @Service annotation, error
message should point out to exact problem with serviceImpl/service/operation
---
Key: TUSCANY-1517
URL: https://issues.apache.org/jira/browse/TUSCANY-1517
Project: Tuscany
Issue Type: Bug
Components: Java SCA Problem Determination
Reporter: Rashmi Hunt
If user makes error in service impl, pointing to a wrong service interface
in @Service annotation, during composite startup, Tuscany tries to introspect
the
impl and tries to match to service operation and fails with below exception.
Even though it's user error, with this exception message, user can not
figure out what is the problem with the composite. Exception message should be
clear
enough to point to exact error with details about which
serviceImpl/service/operation.
Example serviceimpl for this defect
@Service(HelloWorld3Service.class)
public class HelloWorldImpl implements HelloWorldService {
}
Exception:
Caused by: java.lang.IllegalArgumentException:
org.apache.tuscany.sca.implementation.java.context.TargetMethodNotFoundException:
Target method not found for operation
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInvoker(JavaImplementationProvider.java:134)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.addImplementationInterceptor(CompositeActivatorImpl.java:647)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createWires(CompositeActivatorImpl.java:520)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createRuntimeWires(CompositeActivatorImpl.java:376)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:781)
... 39 more
Caused by:
org.apache.tuscany.sca.implementation.java.context.TargetMethodNotFoundException:
Target method not found for operation
at
org.apache.tuscany.sca.implementation.java.invocation.JavaComponentInfo.createTargetInvoker(JavaComponentInfo.java:399)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInvoker(JavaImplementationProvider.java:132)
... 43 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1518) Insufficient error message, Pass-by-value not allowed on this object
Insufficient error message, Pass-by-value not allowed on this object --- Key: TUSCANY-1518 URL: https://issues.apache.org/jira/browse/TUSCANY-1518 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Reporter: Rashmi Hunt Insufficient error message by Tuscany, Pass-by-value not allowed on this object On a remotable service interface, if user makes a mistake of passing a java type as parameter which is not serializable, Tuscany throws an exception Pass-by-value not allowed on this object. This message is insufficient since user will not be able to understand that the real issue is parameter is not a serilizable type. Better message could be Paramater xxx is not serializable. Pass-by-value not allowed on this object This exception is thrown from org.apache.tuscany.sca.databinding.javabeans.copy() method , line number 78 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1518) Insufficient error message, Pass-by-value not allowed on this object
[ https://issues.apache.org/jira/browse/TUSCANY-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rashmi Hunt updated TUSCANY-1518: - Description: Insufficient error message by Tuscany, Pass-by-value not allowed on this object On a remotable service interface, if user makes a mistake of passing a java type as parameter which is not serializable, Tuscany throws an exception Pass-by-value not allowed on this object. This message is insufficient since user will not be able to understand that the real issue is parameter is not a serilizable type. Better message could be Paramater xxx is not serializable. Pass-by-value not allowed on this object This exception is thrown from org.apache.tuscany.sca.databinding.javabeans.JavaBeansDataBinding.copy() method , line number 78 was: Insufficient error message by Tuscany, Pass-by-value not allowed on this object On a remotable service interface, if user makes a mistake of passing a java type as parameter which is not serializable, Tuscany throws an exception Pass-by-value not allowed on this object. This message is insufficient since user will not be able to understand that the real issue is parameter is not a serilizable type. Better message could be Paramater xxx is not serializable. Pass-by-value not allowed on this object This exception is thrown from org.apache.tuscany.sca.databinding.javabeans.copy() method , line number 78 Insufficient error message, Pass-by-value not allowed on this object --- Key: TUSCANY-1518 URL: https://issues.apache.org/jira/browse/TUSCANY-1518 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Reporter: Rashmi Hunt Insufficient error message by Tuscany, Pass-by-value not allowed on this object On a remotable service interface, if user makes a mistake of passing a java type as parameter which is not serializable, Tuscany throws an exception Pass-by-value not allowed on this object. This message is insufficient since user will not be able to understand that the real issue is parameter is not a serilizable type. Better message could be Paramater xxx is not serializable. Pass-by-value not allowed on this object This exception is thrown from org.apache.tuscany.sca.databinding.javabeans.JavaBeansDataBinding.copy() method , line number 78 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1519) NullPointerException, if name of the component service in SCDL, doesn't match the service name which is specified in @Service annotation,
NullPointerException, if name of the component service in SCDL, doesn't match
the service name which is specified in @Service annotation,
--
Key: TUSCANY-1519
URL: https://issues.apache.org/jira/browse/TUSCANY-1519
Project: Tuscany
Issue Type: Bug
Components: Java SCA Problem Determination
Reporter: Rashmi Hunt
If name of the component service in SCDL, doesn't match the service name which
is specified in @Service annotation, Tuscany throws NullPointerException.
User will not be able to figure out with below exception what's really wrong
with the SCDL. Error message should point to exact problem in SCDL instead
of NullPointer
Sample SCDL:
component name=ClientComponent
service name=ClientService
..
/service
component
ServiceImpl:
@Service(ServiceInterface.class)
public class BVTClientComponent implements ServiceInterface {
}
Stack Dump = java.lang.NullPointerException
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createWires(CompositeActivatorImpl.java:363)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createRuntimeWires(CompositeActivatorImpl.java:269)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:580)
at
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain$DomainCompositeHelper.addComposite(EmbeddedSCADomain.java:124)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1520) IndexOutOfBoundsException if XSD namespace is omitted in SCDL
IndexOutOfBoundsException if XSD namespace is omitted in SCDL -- Key: TUSCANY-1520 URL: https://issues.apache.org/jira/browse/TUSCANY-1520 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Reporter: Rashmi Hunt In a SCDL definition if user forgets to put the XSD namespace definition at the top of a composite definition. For example if you forget the XSD namespace definition (xmlns:xsd=http://www.w3.org/2001/XMLSchema;) in a composite definition like this: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:wsdli=http://www.w3.org/2006/01/wsdl-instance; name=helloworldwsinstance0 component property name=instanceId type=xsd:int1/property property name=instanceName type=xsd:stringinstanceName/property /component . /composite If the XSD namespace is omitted (as above) you will get a runtime failure, from Tuscany without indicating what is the the problem with the SCDL. Need an error message which points out to exact problem in SCDL instead of IndexOutOfBoundsException java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:572) at java.util.ArrayList.get(ArrayList.java:347) at org.apache.tuscany.core.property.PropertyObjectFactoryImpl$ObjectFactoryImpl.getInstance(PropertyObjectFactoryImpl.java:125) at org.apache.tuscany.core.injection.MethodInjector.inject(MethodInjector.java:46) at org.apache.tuscany.core.implementation.PojoAtomicComponent.createInstance(PojoAtomicComponent.java:140) at org.apache.tuscany.core.component.scope.CompositeScopeContainer.getInstanceWrapper(CompositeScopeContainer.java:131) at org.apache.tuscany.core.component.scope.AbstractScopeContainer.getInstance(AbstractScopeContainer.java:99) at org.apache.tuscany.core.implementation.PojoAtomicComponent.getTargetInstance(PojoAtomicComponent.java:129) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.getInstance(JavaTargetInvoker.java:128) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:75) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(SynchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(SynchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(SynchronousBridgingInterceptor.java:41) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1521) Error message should indicate operation in question, if Java interface of a POJO and the WSDL interface for a composite service over a WS binding are mismatched
Error message should indicate operation in question, if Java interface of a POJO and the WSDL interface for a composite service over a WS binding are mismatched Key: TUSCANY-1521 URL: https://issues.apache.org/jira/browse/TUSCANY-1521 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Reporter: Rashmi Hunt If a Java interface of a POJO and the WSDL interface for a composite service that exposes the component over a WS binding are mismatched, the resulting error message at runtime should include more detail about the specific operation that is the problem. It would help to have more information about what operation was not found on the target. Exception: org.apache.tuscany.spi.wire.IncompatibleServiceContractException: Operation not found on target at org.apache.tuscany.core.wire.WireServiceExtension.checkCompatibility(WireServiceExtension.java:233) at org.apache.tuscany.core.builder.ConnectorImpl.checkIfWireable(ConnectorImpl.java:496) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:440) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:349) at org.apache.tuscany.core.builder.ConnectorImpl.handleService(ConnectorImpl.java:556) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:93) at org.apache.tuscany.spi.extension.CompositeComponentExtension.prepare(CompositeComponentExtension.java:388) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:126) at org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(LauncherImpl.java:233) -- 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: Policy Attachments Resolution in the Assembly Model
Yes Luciano, that's what I am suggesting. - Venkat On 8/8/07, Luciano Resende [EMAIL PROTECTED] wrote: Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Not sure i got this right, but are you asking for the ability to register artifactProcessors by fileName as well as extension ? On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks - Venkat On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Now that I have the basic policy model in place I am trying to link up this with the assembly model now. The policy intents and policy sets applicable for a domain are defined in the definitions.xml. There is a SCADefinitions processor that deals with reading and resolving the intents and policysets in the definitions.xml. The SCADefinitions processor has a model resolver into which the the various policy intents and policy sets that are read get added. All of this is a part of the policy-xml module. Now looking into the aspect of dealing with the 'attachments' of policy intents and policy sets into various SCA constructs, I see there is a need to resolve the intents and policysets with those that have been read from the definitions.xml. This means an artifact processor such as the CompositeProcessor needs to be passed a resolver that has the various policy intents and policy sets in it. Now the question is, do we assume that we use the same resolver that is used to add up the read sca contructs is used to also add the policy intents and policysets ? or... Going by the discussion in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I am given to understand that its best to keep all of the things related to policies - the processor, the resolver etc. separate from those that we have for the assembly model. If this is the case then the CompositeProcessor, the ConstrainingType Processor etc. all have to be set with the instance of a SCADefinitionsResolver that will be used to resolve to policy related things. Could somebody please help me with some perspectives on which one of the above two is better to follow? Thanks - Venkat I think we can follow the same pattern as implementations, bindings, etc: - In CompositeProcessor.resolve(model, resolver), call resolver.resolveModel(policyToResolve) to resolve an unresolved policy model object, then attach the resolved policy to the composite. - In your policy-xml module, provide a PolicyModelResolver and register it in the ModelResolverExtensionPoint. PolicyModelResolver will handle the resolution of Policy model objects (by qname I guess). Look for CompositeModelResolver for an example of a ModelResolver. -- 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] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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]
New dependencies on binding-sca? was: svn commit: r563787 - in /incubator/tuscany/java/sca/modules: binding-ejb/pom.xml core-spring/pom.xml host-embedded/pom.xml
I'm not sure what required these dependency changes: - binding-ejb now depending on host-embedded? - host-embedded now depending on binding-sca-xml? Could you please help me understand? Thanks. [EMAIL PROTECTED] wrote: Author: slaws Date: Wed Aug 8 01:29:54 2007 New Revision: 563787 URL: http://svn.apache.org/viewvc?view=revrev=563787 Log: TUSCANY-1512 Correct some binding-sca dependencies that I missed on the last checkin Modified: incubator/tuscany/java/sca/modules/binding-ejb/pom.xml incubator/tuscany/java/sca/modules/core-spring/pom.xml incubator/tuscany/java/sca/modules/host-embedded/pom.xml Modified: incubator/tuscany/java/sca/modules/binding-ejb/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/binding-ejb/pom.xml?view=diffrev=563787r1=563786r2=563787 == --- incubator/tuscany/java/sca/modules/binding-ejb/pom.xml (original) +++ incubator/tuscany/java/sca/modules/binding-ejb/pom.xml Wed Aug 8 01:29:54 2007 @@ -38,6 +38,12 @@ artifactIdtuscany-extension-helper/artifactId version1.0-incubating-SNAPSHOT/version /dependency + +dependency +groupIdorg.apache.tuscany.sca/groupId +artifactIdtuscany-host-embedded/artifactId +version1.0-incubating-SNAPSHOT/version +/dependency dependency groupIdorg.apache.geronimo.specs/groupId Modified: incubator/tuscany/java/sca/modules/core-spring/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/core-spring/pom.xml?view=diffrev=563787r1=563786r2=563787 == --- incubator/tuscany/java/sca/modules/core-spring/pom.xml (original) +++ incubator/tuscany/java/sca/modules/core-spring/pom.xml Wed Aug 8 01:29:54 2007 @@ -100,8 +100,8 @@ groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-binding-sca/artifactId version1.0-incubating-SNAPSHOT/version -scopetest/scope -/dependency +/dependency + /dependencies /project Modified: incubator/tuscany/java/sca/modules/host-embedded/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-embedded/pom.xml?view=diffrev=563787r1=563786r2=563787 == --- incubator/tuscany/java/sca/modules/host-embedded/pom.xml (original) +++ incubator/tuscany/java/sca/modules/host-embedded/pom.xml Wed Aug 8 01:29:54 2007 @@ -45,14 +45,12 @@ groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-binding-sca/artifactId version1.0-incubating-SNAPSHOT/version -scoperuntime/scope /dependency dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-binding-sca-xml/artifactId version1.0-incubating-SNAPSHOT/version -scoperuntime/scope /dependency dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
