Re: [VOTE] Release Tuscany Java SCA 2.0-M1 (RC3)
It all looks ok to me so +1 on RC3. ...ant On Thu, Feb 12, 2009 at 5:44 AM, Luciano Resende luckbr1...@gmail.comwrote: Please review and vote on the 2.0-M1 release artifacts of Tuscany SCA for Java. The artifacts are available for review at: http://people.apache.org/~lresende/tuscany/2.0-M1-RC3/http://people.apache.org/%7Elresende/tuscany/2.0-M1-RC3/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. The release tag is available at : http://svn.apache.org/repos/asf/tuscany/tags/java/sca/2.0-M1-RC3/ Looks OK to me, here is my +1. -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
[jira] Updated: (TUSCANY-2839) Remove the need to have a ConnectionFactory in case of oneway invocation path on the service side
[ https://issues.apache.org/jira/browse/TUSCANY-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-2839: --- Component/s: Java SCA JMS Binding Extension Remove the need to have a ConnectionFactory in case of oneway invocation path on the service side - Key: TUSCANY-2839 URL: https://issues.apache.org/jira/browse/TUSCANY-2839 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Rashmi Hunt This is an issue in the case of oneway where Tuscany code path needs Connection Factory where it's not necessary to have one as there is no response in case of oneway. When a oneway message is received at the service, TransportServiceInterceptor.invoke() method calls invokeRequest() before calling invokeResponse(). TransportServiceInterceptor.invokeRequest() is trying to create JMS connection/session by calling context.setJmsSession(context.getJmsResourceFactory().createSession()), The session created here later gets used in various xxxMessageProcessor.createJMSMessage() to create a JMS message. The issue here is JmsResourceFactory().createSession(), tries to create a connection and there is no Connection Factory defined in SCDL for the service and there is no need to have default connectionFactory, 'ConnectionFactory' either. This call ends up in connectionfactory not found exception since the jndi lookup fails. In oneway case, why there is a need to call 'context.setJmsSession(context.getJmsResourceFactory().createSession())' in TransportServiceInterceptor.invokeRequest() method? since there is no need to create a message using this jms session as there is no response. Trying to comment this call causes issues in downstream classes like xxxMessageProcessor classes. This entire invocation path should understand oneway pattern and right now there isn't way to clearly seperate. Sample SCDL for reference and service for this issue reference name=component_2 interface.java interface=test.sca.binding.sca.oneway.Component_2/ binding.jms destination name=jms/oneway/ connectionFactory name=jms/oneway_cf/ /binding.jms /reference component name=Component_2 implementation.java class=test.sca.binding.sca.oneway.Component_2Impl/ service name=Component_2 binding.jms destination name=jms/oneway/ activationSpec name=jms/SCA_JMS_AS/ /binding.jms /service reference name=component_3 target=Component_3/ /component -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Tuscany Maven Eclipse Compiler 1.0
On Tue, Feb 10, 2009 at 9:52 AM, ant elder ant.el...@gmail.com wrote: Please vote on releasing the Tuscany Maven Eclipse Compiler module. The tag for the release is: https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/maven-eclipse-compiler-1.0/ the Maven staging repository is: http://people.apache.org/~antelder/tuscany/maven-eclipse-compiler-1.0/http://people.apache.org/%7Eantelder/tuscany/maven-eclipse-compiler-1.0/ ...ant Adding my vote to remind people this is pending still. +1 Also, in case the location of the tag is bothering anyone we can put the tag anywhere we like and can rename and move the tag after the release vote as we do with the SCA releases, eg i've just copied it to https://svn.apache.org/repos/asf/tuscany/tags/java/maven-eclipse-compiler-1.0/ ...ant
[jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
[ https://issues.apache.org/jira/browse/TUSCANY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673226#action_12673226 ] ant elder commented on TUSCANY-2845: I've added an itest to test various exceptions: https://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/itest/jms-nonscaclient-exceptions/ That has two SCA services, one using JMS text xml messages the other using JMS Object messages, which throw different types of exceptions, and the services are invoked by non-SCA clients. Presently the Text message tests are commentted out till we work out what the response messages should look like. The Object message ones are enabled and seem like the jms binidng is doing the ok thing. Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException -- Key: TUSCANY-2845 URL: https://issues.apache.org/jira/browse/TUSCANY-2845 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in binding.ws would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate exception from the fault. True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow? Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[1.x][2.x] Over zealous PBV handler insertion
Around line 155 of DataBindingRuntimeWireProcessor there is the code
// assume pass-by-values copies are required if interfaces
are remotable and there is no data binding
// transformation, i.e. a transformation will result in a
copy so another pass-by-value copy is unnecessary
if (!isOnMessage(targetOperation) isRemotable(chain,
sourceOperation, targetOperation)) {
interceptor =
new PassByValueInterceptor(dataBindings,
faultExceptionMapper, chain, targetOperation);
}
We should only be doing this if binding.sca is being used.
TUSCANY-2586 records this problem but there seems to be some question as to
the solution. Why can't we check here what type of binding is being used?
Iassuming that that approach was discounted.
Simon
[jira] Updated: (TUSCANY-2840) Issues in usage of @XmlJavaTypeAdapter annotation in service methods
[ https://issues.apache.org/jira/browse/TUSCANY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2840: - Attachment: TUSCANY-2840-Part1.patch Part1 of the patch is Committed at revision 744091 for 1.x. Will keep this JIRA to also check-in some samples to demonstrate the usage of JAXB annotations. Issues in usage of @XmlJavaTypeAdapter annotation in service methods Key: TUSCANY-2840 URL: https://issues.apache.org/jira/browse/TUSCANY-2840 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-Next Environment: Windows XP, SP2, IBM JDK 1.5 Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next Attachments: TUSCANY-2840-Part1.patch Here I like to talk about the options to support org.apache.axiom.om.OMElement datatype in our databinding scope Since OMElement is an interface, the JAXB runtime throws the following exception org.apache.axiom.om.OMElement is an interface, and JAXB can't handle interfaces. this problem is related to the following location: at org.apache.axiom.om.OMElement at protected org.apache.axiom.om.OMElement org.apache.tuscany.sca.binding.ws.axis2.itests.mtom.jaxws.UploadOMElementFile.arg0 at org.apache.tuscany.sca.binding.ws.axis2.itests.mtom.jaxws.UploadOMElementFile JAXB recommends to use an XMLAdapter to solve this issue, by creating an XMLAdapter for your interfaces (OMElement) and by using @XmlJavaTypeAdapter in the service method as shown below. @XmlJavaTypeAdapter(value=OMElementXmlAdapter.class, type=OMElement.class) public String uploadOMElementFile(OMElement attachment) throws Exception; Using @XmlJavaTypeAdapter in the service method, throws the following exception. java.lang.IllegalArgumentException: value class org.apache.tuscany.sca.binding.ws.axis2.itests.mtom.OMElementXmlAdapter at org.objectweb.asm.ClassWriter.a(Unknown Source) at org.objectweb.asm.AnnotationWriter.visit(Unknown Source) at org.apache.tuscany.sca.interfacedef.java.jaxws.BaseBeanGenerator.declareField(BaseBeanGenerator.java:250) at org.apache.tuscany.sca.interfacedef.java.jaxws.BaseBeanGenerator.declareProperty(BaseBeanGenerator.java:195) at org.apache.tuscany.sca.interfacedef.java.jaxws.BaseBeanGenerator.defineClass(BaseBeanGenerator.java:153) at org.apache.tuscany.sca.interfacedef.java.jaxws.BaseBeanGenerator.generate(BaseBeanGenerator.java:437) at org.apache.tuscany.sca.interfacedef.java.jaxws.WrapperBeanGenerator.generateResponseWrapper(WrapperBeanGenerator.java:190) at org.apache.tuscany.sca.interfacedef.java.jaxws.GeneratedDataTypeImpl.getPhysical(GeneratedDataTypeImpl.java:101) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.findClasses(JAXBContextHelper.java:230) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:210) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:89) at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:52) at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:40) at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:200) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:81) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:190) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:81) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:208) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:97) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:310) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:163) at $Proxy19.uploadOMElementFile(Unknown Source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Update on Databinding Scope Issues
Hi Raymond, I have a difficulty in understanding your comment here, Please help me understand by elaborating a bit more. Thanks. On Thu, Feb 12, 2009 at 12:08 AM, Raymond Feng enjoyj...@gmail.com wrote: Hi, Do we want to generalize the fix a bit to have a XmlJavaTypeAdapter backed by the databinding framework to deal with XML-friendly types that are not JAXB? The only difficulty is that the adapter has to access the databinding framework statically (for example, from a static variable or some context on the thread) as the instance will be instantiated by the JAXB runtime. Thanks, Raymond *From:* Ramkumar R ramkumar...@gmail.com *Sent:* Wednesday, February 11, 2009 10:10 AM *To:* dev@tuscany.apache.org *Subject:* Re: Update on Databinding Scope Issues Hi All, I am planning to fix the data binding issue with OMElement as described in https://issues.apache.org/jira/browse/TUSCANY-2664, by creating a pre-defined XMLAdapter called OMElementXMLAdapter.java as we have done for CallableReferences earlier. Please let me know if any one has issues in this fix. By fixing TUSCANY-2664, we can now claim that we have a complete support for Axis2 MTOM. I have opened a seperate JIRA TUSCANY-2840 to track the issue around the usage of @XmlJavaTypeAdapter in service methods. On Wed, Feb 11, 2009 at 5:11 PM, Ramkumar R ramkumar...@gmail.com wrote: Hi Simon, You are right, by configuring our databinding framework to know about the types that JAXB struggles, its possible that we will get rid of this issue. In fact as I mentioned earlier, By adding XMLAdapter's in DataBindingModuleActivator.java, (as how we do for CallableReferences too) as shown below. XMLAdapterExtensionPoint xmlAdapterExtensionPoint = registry.getExtensionPoint(XMLAdapterExtensionPoint.class); xmlAdapterExtensionPoint.addAdapter(Exception.class, ExceptionXMLAdapter.class); resolves the issue. I believe this solution holds good for some critical data types like OMElement that we like to support for Axis2 MTOM. But looking at the broader picture, there might me quite a lot of java defined interfaces that the user might want to use as a parameter types (for example java.lang.Exception), so in such cases it would be good we allow the users to define their own XMLAdapter's and allow them to use with our databinding framework, rather than we develop pre-defined XMLAdapter for possible interfaces that can be use. Please let me know, if you have any comments/sugggestion. Thanks. On Mon, Feb 9, 2009 at 6:47 PM, Simon Laws simonsl...@googlemail.comwrote: On Mon, Feb 9, 2009 at 12:20 PM, Ramkumar R ramkumar...@gmail.comwrote: As mentioned earlier, since JAXB can't handle interfaces like org.apache.axiom.om.OMElement OR java.lang.Exception one way to make this interfaces work with JAXB is to write an XMLAdapter to convert these data types to the known JAXB data types. Defining @XmlJavaTypeAdapter annotation with the XMLAdapter as value in the service method does not seem to work in Tuscany as I mentioned earlier. So I tried adding XMLAdapter's in DataBindingModuleActivator.java, as shown below. XMLAdapterExtensionPoint xmlAdapterExtensionPoint = registry.getExtensionPoint(XMLAdapterExtensionPoint.class); xmlAdapterExtensionPoint.addAdapter(Exception.class, ExceptionXMLAdapter.class); This seem to be work fine for me, and now I am able to pass these interfaces as parameter through JAXB. Just wanted to make sure, if anyone have tried using @XmlJavaTypeAdapter annotations with the service methods, if not I can open JIRA to fix this issue. On Fri, Feb 6, 2009 at 5:49 PM, Ramkumar R ramkumar...@gmail.comwrote: The DataBinding Scope wiki page http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope is now updated with the databinding scope for Axis2 MTOM support. Just wanted to update everyone that, the standard type javax.activation.DataHandler is now fully supported, more details can be viewed from TUSCANY-2451. Currently we have 2 outstanding issue that needs to be resolved... 1. Support for javax.xml.transform.Source data type, raised as TUSCANY-2386, TUSCANY-2387 and TUSCANY-2452. 2. Support for org.apache.axiom.om.OMElement, raised as TUSCANY-2664 Here I like to talk about the options to support org.apache.axiom.om.OMElement datatype in our databinding scope Since OMElement is an interface, the JAXB runtime throws the following exception org.apache.axiom.om.OMElement is an interface, and JAXB can't handle interfaces. this problem is related to the following location: at org.apache.axiom.om.OMElement at protected org.apache.axiom.om.OMElement org.apache.tuscany.sca.binding.ws.axis2.itests.mtom.jaxws.UploadOMElementFile.arg0 at org.apache.tuscany.sca.binding.ws.axis2.itests.mtom.jaxws.UploadOMElementFile JAXB recommends to use an XMLAdapter to solve this issue, by creating an
[jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
[ https://issues.apache.org/jira/browse/TUSCANY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673235#action_12673235 ] Simon Laws commented on TUSCANY-2845: - As the code stands the exception format will follow the wire format however the exception will always be returned in a JMS Object message. There is no way to control the format of the exception independently. So in the case of wireFormat.textXML (currently the default format) the databinding is set up to do our standard JAXWS based data tranfsformations and hence you get wrapped exceptions. For other wireFormats the data just flows directly to the JMS binding without transformation and hence you see the native faults. Still as Object messages thought. So a couple of thoughts. We need to... Decide what formats and message types should be used to transfer faults for each wire format including the default one. Just a string in a Text message Unwrapped exception in an Object message Talk to the spec people about control of fault format. Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException -- Key: TUSCANY-2845 URL: https://issues.apache.org/jira/browse/TUSCANY-2845 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in binding.ws would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate exception from the fault. True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow? Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [1.x][2.x] Over zealous PBV handler insertion
Simon Laws wrote:
Around line 155 of DataBindingRuntimeWireProcessor there is the code
// assume pass-by-values copies are required if
interfaces are remotable and there is no data binding
// transformation, i.e. a transformation will result in
a copy so another pass-by-value copy is unnecessary
if (!isOnMessage(targetOperation) isRemotable(chain,
sourceOperation, targetOperation)) {
interceptor =
new PassByValueInterceptor(dataBindings,
faultExceptionMapper, chain, targetOperation);
}
We should only be doing this if binding.sca is being used.
TUSCANY-2586 records this problem but there seems to be some question as
to the solution. Why can't we check here what type of binding is being
used? Iassuming that that approach was discounted.
Simon
It isn't safe to assume that all bindings other than binding.sca
force copies to be made. A user could write binding.foo that
works similarly to binding.sca in that it doesn't do copies on
local invocations.
The solution proposed in the discussion of TUSCANY-2586 solves
this problem by making every binding responsible for deciding
whether the copying needs to be done.
Simon
Re: [1.x][2.x] Over zealous PBV handler insertion
On Fri, Feb 13, 2009 at 12:19 PM, Simon Nash n...@apache.org wrote:
Simon Laws wrote:
Around line 155 of DataBindingRuntimeWireProcessor there is the code
// assume pass-by-values copies are required if interfaces
are remotable and there is no data binding
// transformation, i.e. a transformation will result in a
copy so another pass-by-value copy is unnecessary
if (!isOnMessage(targetOperation) isRemotable(chain,
sourceOperation, targetOperation)) {
interceptor =
new PassByValueInterceptor(dataBindings,
faultExceptionMapper, chain, targetOperation);
}
We should only be doing this if binding.sca is being used.
TUSCANY-2586 records this problem but there seems to be some question as
to the solution. Why can't we check here what type of binding is being used?
Iassuming that that approach was discounted.
Simon
It isn't safe to assume that all bindings other than binding.sca
force copies to be made. A user could write binding.foo that
works similarly to binding.sca in that it doesn't do copies on
local invocations.
The solution proposed in the discussion of TUSCANY-2586 solves
this problem by making every binding responsible for deciding
whether the copying needs to be done.
Simon
Ok, good point. My thought was also rubbish as binding.sca doesn't always
need the PBV interceptor:-(
So we need a new binding operation to ask the question whether a copy is
required. In the binding.sca case it needs to take account of whether it's
operating in local or remote mode.
Simon
Re: [VOTE] Release Tuscany Java SCA 2.0-M1 (RC3)
On Feb 13, 2009, at 12:15 AM, Luciano Resende wrote: I noted that Kevan was +0, Are we going to need a new RC ? Not in my opinion. If I thought one was needed, I'd have voted -1... ;-) I think it's best to get the release out and keep moving. I'll see if I can figure out what's going on with Java 6. --kevan
Re: [VOTE] Release Tuscany Java SCA 2.0-M1 (RC3)
On Feb 13, 2009, at 12:09 AM, Raymond Feng wrote: Hi, 1) I fixed the SAX2DOM ASL header. Thanks 2) I'm using JDK 6 on both Windows and Linux and I don't see any problems. OK. Good to know. 3) For the tools.jar issue, Kevan had a patch for http://issues.apache.org/jira/browse/TUSCANY-2594 . It should fix the same problem too. I'm trying to use maven profile to control if the tools.jar should be included. I'll check it in after I verify the result. Heh. How quickly I forget... I'll see if I can get that working again. --kevan
[jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
[ https://issues.apache.org/jira/browse/TUSCANY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673239#action_12673239 ] ant elder commented on TUSCANY-2845: Based on what Simon just said I've updated the JMS binding wireFormat.textXML to unwrap the jaxws exception and set it as xml in a jms text message. I've updated the jms-nonscaclient-exceptions so that it tests this for both object and text xml messages. We still need to clarify what we think it really needs to do based on what the spec says, but i think what it does now is close to whats been asked for and its easier to see what it does looking at the jms-nonscaclient-exceptions itest and we can update as necessary. Another remaining thing is what to to for unchecked exceptions? Currently even with wireFormat.textXML they get returned as a JMS Object message containing a org.osoa.sca.ServiceRuntimeException Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException -- Key: TUSCANY-2845 URL: https://issues.apache.org/jira/browse/TUSCANY-2845 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in binding.ws would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate exception from the fault. True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow? Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [2.x] Java SCA 2.0 next milestones release
On Wed, Feb 11, 2009 at 5:05 PM, Raymond Feng enjoyj...@gmail.com wrote: Please see my comments inline. Thanks, Raymond *From:* ant elder ant.el...@gmail.com *Sent:* Wednesday, February 11, 2009 7:06 AM *To:* dev@tuscany.apache.org *Subject:* Re: [2.x] Java SCA 2.0 next milestones release On Mon, Feb 9, 2009 at 10:49 PM, Luciano Resende luckbr1...@gmail.comwrote: On Mon, Feb 9, 2009 at 2:35 PM, Simon Laws simonsl...@googlemail.com wrote: What do you mean by short? Monthly? Six weekly? I think it should be down at this sort of order. I was thinking on something around 4 weeks or less. Not sure we explicitly have to alternate but I like the idea of themes. Maybe this results in the same thing but I wouldn't want to pre-judge it. I just want to avoid loosing focus, and having multiple people going in multiple directions. Alternating focus between OASIS spec items and Tuscany infrastructure/extensions would allow us to get the right balance, and would allow active collaboration towards a common goal and I hope better results at the end. +1 on not loosing focus, but i think we may need to have multiple people going in multiple directions if we're to get this done in time. Remember the date we're aiming for 2.0 is June, just three and a bit months away so not much time. Doing a release takes time away from other work so too short a release cycle will impact productivity, a release every few weeks is too often IMHO, it might work with the point releases we've done to fix bugs in 1.x.x type releases but for this type of milestone development it would mean an unnecessarily high percentage of our available time gets sucked up in release work. 6 weeks seems more realistic to me and that could give an M2 at end of March, M3 end of April, perhaps beta1 end of May and then 2.0 final tracks the OASIS date. A 6-week cycle sounds reasonable. So fitting the work and themes into into those three releases could be: M2 - port as much as possible from 1.x to 2.x IMO, it is probably too early to do this in M2. Porting non-OASIS extensions won't help the OASIS compliance and I'm afraid that we will have to do it again as the core and SPIs will change quite a bit. We need to adjust the XSDs, models and processors for the assembly, policy and other OASIS bindings/implementations so that the Tuscany runtime can consume the OASIS composites. We should try to get some of the key infrastructures such as Endpoint and Policy in place first. (The policy work can be spanning over two milestones) We can start with the extensions that are defined by OASIS specs and defer other extensions to a later stage. When will the Domain/Node story to be completed? M3 - work on OASIS compliance We should try to pass all of the OASIS compliance tests. Beta1 - stabilize all functional changes I think it's the time that we port non-OASIS extensions to 2.x and stabilize the code. and then only bug fixes in a 2.0 branch till the 2.0 final release Let's try to dump out the all the items toward an OASIS-compliant SCA runtime first and then plug them into the milestones. I think we're on similar pages. The contents of M2 is still a bit hazy but i think thats fine, these are themes not rules so we can work it out as we go along. I don't think we should restrict things to only spec defined items though, there are also other things we do need to do such as the Node story and webapp integration we need to get done and they're not defined in any specs, bringing up non OASIS extensions will help verify SPIs, provide opportunities for people to help and get involved in the 2.x code, and they provide a easier entry point to learning 2.x than diving right in to something like implementation.bpel. We've also the results from the user survey that shows us what people are using so that can help prioritize work. Agree with that last point, we've the 2.0 draft release notes and 2.x JIRA lists we've started on the other threads about this to help guide us, if we keep adding JIRAs as we thing of things then it will help see what needs to be done ...ant
Re: [2.x] Java SCA 2.0 next milestones release
Let me try and summarize this thread There's a lot to do here so we need to find things that people want to do that can happen in parallel. I think we logically need an M4. A guide rather than a plan set in concrete. M2 – Assembly compliance (based on extensions we already have in trunk) XSD/API Processors Assembly compliance tests Policy Endpoint Domain/Node + Any other infrastructure fixes we come across required for OASIS compliance M3 – Policy/Extension compliance Ws compliance tests Java compliance tests More policy work + Policy compliance tests More Domain/node work + Assembly compliance tests relating to domain Bring in remaining OASIS specific extension on upgraded infrastructure, e.g. JMS, JEE, BPEL, EJB binding, Spring (is there anything else) + compliance tests M4 On top of beta compliance bring in any Tuscany specific extensions we think we need? Beta Lock down and prep for branch Simon
Re: [2.x] Java SCA 2.0 next milestones release
On Fri, Feb 13, 2009 at 1:27 PM, Simon Laws simonsl...@googlemail.comwrote: Let me try and summarize this thread There's a lot to do here so we need to find things that people want to do that can happen in parallel. I think we logically need an M4. A guide rather than a plan set in concrete. M2 – Assembly compliance (based on extensions we already have in trunk) XSD/API Processors Assembly compliance tests Policy Endpoint Domain/Node + Any other infrastructure fixes we come across required for OASIS compliance M3 – Policy/Extension compliance Ws compliance tests Java compliance tests More policy work + Policy compliance tests More Domain/node work + Assembly compliance tests relating to domain Bring in remaining OASIS specific extension on upgraded infrastructure, e.g. JMS, JEE, BPEL, EJB binding, Spring (is there anything else) + compliance tests M4 On top of beta compliance bring in any Tuscany specific extensions we think we need? Beta Lock down and prep for branch Simon Touche Ant! This is just my summary of this thread. A guide with OASIS compliance squarely in the frame but not a concrete plan and I would hope it's treated in that spirit. If someone wants to bring up, say host-webapp, or whatever much earlier then that's great I'm certainly not going to complain. In fact webapp would be a good one as users want it and helps get out sample testing thing complete with this tricky case. Maybe we should add that explicitly to the list. Anyhow, I'd like us to move on from this thread. Add the list to the roadmap, create appropriate JIRAS, adjust as we see fit as we move forward and declare victory. Simon
[jira] Updated: (TUSCANY-2779) The problem of catch spring implementation's Exception
[
https://issues.apache.org/jira/browse/TUSCANY-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhulei updated TUSCANY-2779:
Fix Version/s: (was: Java-SCA-1.4)
The problem of catch spring implementation's Exception
--
Key: TUSCANY-2779
URL: https://issues.apache.org/jira/browse/TUSCANY-2779
Project: Tuscany
Issue Type: Bug
Components: Java SCA Spring Implementation Extension
Affects Versions: Java-SCA-1.4
Environment: SuSE Linux 10.3 for PPC IBM JDK 1.6
Reporter: zhulei
I find that I can not catch the Exception message when I test the spring
implementation recently.
I try to recode the source code as It's very important for me. I find a bug
in it and revise it. I success.
the code of
org.apache.tuscany.sca.implementation.spring.SpringInvoker.doInvoke
befor changed :
} catch (InvocationTargetException e) {
throw new SpringInvocationException(Spring invoker invoke method
'+ theMethod.getName()+' error.,e);
changed and tested:
} catch (InvocationTargetException e) {
throw new SpringInvocationException(Spring invoker invoke method
'+ theMethod.getName()+' error.,e.getCaus());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r743992 - /tuscany/java/sca/itest/distribution/bin-distro-unzip/pom.xml
On Fri, Feb 13, 2009 at 5:29 AM, rf...@apache.org wrote: Author: rfeng Date: Fri Feb 13 05:29:32 2009 New Revision: 743992 URL: http://svn.apache.org/viewvc?rev=743992view=rev Log: Add profiles to control if tools.jar should be listed as a system dependency. tools.jar doesn't exist on Mac OS. This actually breaks it in my default environment which is i think what other people might get from a vanilla Java install on windows. I can fix it by changing java home but it would be nice if we could find a more reliable way to make this work: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An Ant BuildException has occured: The following error occurred while executing this line: C:\Tuscany\SVN\trunk\itest\distribution\binding-ws-calculator\build.xml:36: The following error occurred while executing this line: C:\Tuscany\SVN\trunk\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT-dir\tuscany-sca-2.0-SNAPSHOT\samples\bi nding-ws-calculator\build.xml:37: Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. ...ant
Re: [VOTE] Release Tuscany Maven Eclipse Compiler 1.0
On Fri, Feb 13, 2009 at 2:29 PM, Simon Laws simonsl...@googlemail.comwrote: On Fri, Feb 13, 2009 at 11:33 AM, ant elder ant.el...@gmail.com wrote: On Tue, Feb 10, 2009 at 9:52 AM, ant elder ant.el...@gmail.com wrote: Please vote on releasing the Tuscany Maven Eclipse Compiler module. The tag for the release is: https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/maven-eclipse-compiler-1.0/ the Maven staging repository is: http://people.apache.org/~antelder/tuscany/maven-eclipse-compiler-1.0/http://people.apache.org/%7Eantelder/tuscany/maven-eclipse-compiler-1.0/ ...ant Adding my vote to remind people this is pending still. +1 Also, in case the location of the tag is bothering anyone we can put the tag anywhere we like and can rename and move the tag after the release vote as we do with the SCA releases, eg i've just copied it to https://svn.apache.org/repos/asf/tuscany/tags/java/maven-eclipse-compiler-1.0/ ...ant Just ran a build from the staging repo. Didn't get a clean build but I don't think that's this plugin's fault. B.t.w. For anyone wishing to actually test this you'll need to change the dependency in sca/pom.xml around line 461... dependencies dependency groupIdorg.apache.tuscany.maven.plugins/groupId artifactIdmaven-eclipse-compiler/artifactId version1.0/version scopeprovided/scope /dependency /dependencies The LICENSE/NOTICES are at the top level and signatures verify. I do notice that the artifact name is a little inconsistent re. how these things usually appear, e.g. it should really be artifactIdmaven-eclipse-compiler-plugin/artifactId? However it's not bothered me before otherwise I would have raised if on the original thread. Not bothering me enought to -1 this vote unless someone finds another reason to respin. +1 Simon Thanks for voting! Re the artifactid, i think thats as this isn't actually a maven plugin module its a compiler. Our other modules that are proper maven plugins do end in plugin, eg tools\maven\maven-bundle-plugin. ...ant
[jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
[ https://issues.apache.org/jira/browse/TUSCANY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673265#action_12673265 ] ant elder commented on TUSCANY-2845: Turns out that breaks exceptions for SCA clients, looking at this now... Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException -- Key: TUSCANY-2845 URL: https://issues.apache.org/jira/browse/TUSCANY-2845 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in binding.ws would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate exception from the fault. True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow? Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [1.x][2.x] Over zealous PBV handler insertion
I agree that PBV should be the responsibility of binding/implementation
providers. IMO, binding.sca should not be handled specically. binding.sca
should be the one that sets up the PBV interceptor if necessary.
Thanks,
Raymond
From: Simon Laws
Sent: Friday, February 13, 2009 4:35 AM
To: dev@tuscany.apache.org
Subject: Re: [1.x][2.x] Over zealous PBV handler insertion
On Fri, Feb 13, 2009 at 12:19 PM, Simon Nash n...@apache.org wrote:
Simon Laws wrote:
Around line 155 of DataBindingRuntimeWireProcessor there is the code
// assume pass-by-values copies are required if interfaces
are remotable and there is no data binding
// transformation, i.e. a transformation will result in a
copy so another pass-by-value copy is unnecessary
if (!isOnMessage(targetOperation) isRemotable(chain,
sourceOperation, targetOperation)) {
interceptor =
new PassByValueInterceptor(dataBindings,
faultExceptionMapper, chain, targetOperation);
}
We should only be doing this if binding.sca is being used.
TUSCANY-2586 records this problem but there seems to be some question as to
the solution. Why can't we check here what type of binding is being used?
Iassuming that that approach was discounted.
Simon
It isn't safe to assume that all bindings other than binding.sca
force copies to be made. A user could write binding.foo that
works similarly to binding.sca in that it doesn't do copies on
local invocations.
The solution proposed in the discussion of TUSCANY-2586 solves
this problem by making every binding responsible for deciding
whether the copying needs to be done.
Simon
Ok, good point. My thought was also rubbish as binding.sca doesn't always need
the PBV interceptor:-(
So we need a new binding operation to ask the question whether a copy is
required. In the binding.sca case it needs to take account of whether it's
operating in local or remote mode.
Simon
[jira] Created: (TUSCANY-2848) Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format
Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format - Key: TUSCANY-2848 URL: https://issues.apache.org/jira/browse/TUSCANY-2848 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-Next Reporter: ant elder Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format. It looks like the databinding framework is not including the cause information when converting from the checked exception to XML in an OMElement -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2848) Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format
[ https://issues.apache.org/jira/browse/TUSCANY-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673284#action_12673284 ] ant elder commented on TUSCANY-2848: See commented out assertions in itest/jms ExceptionsTestCase referencing this JIRA Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format - Key: TUSCANY-2848 URL: https://issues.apache.org/jira/browse/TUSCANY-2848 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-Next Reporter: ant elder Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format. It looks like the databinding framework is not including the cause information when converting from the checked exception to XML in an OMElement -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Tuscany Maven Eclipse Compiler 1.0
Looks good to me, +1 On Fri, Feb 13, 2009 at 6:35 AM, ant elder antel...@apache.org wrote: On Fri, Feb 13, 2009 at 2:29 PM, Simon Laws simonsl...@googlemail.com wrote: On Fri, Feb 13, 2009 at 11:33 AM, ant elder ant.el...@gmail.com wrote: On Tue, Feb 10, 2009 at 9:52 AM, ant elder ant.el...@gmail.com wrote: Please vote on releasing the Tuscany Maven Eclipse Compiler module. The tag for the release is: https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/maven-eclipse-compiler-1.0/ the Maven staging repository is: http://people.apache.org/~antelder/tuscany/maven-eclipse-compiler-1.0/ ...ant Adding my vote to remind people this is pending still. +1 Also, in case the location of the tag is bothering anyone we can put the tag anywhere we like and can rename and move the tag after the release vote as we do with the SCA releases, eg i've just copied it to https://svn.apache.org/repos/asf/tuscany/tags/java/maven-eclipse-compiler-1.0/ ...ant Just ran a build from the staging repo. Didn't get a clean build but I don't think that's this plugin's fault. B.t.w. For anyone wishing to actually test this you'll need to change the dependency in sca/pom.xml around line 461... dependencies dependency groupIdorg.apache.tuscany.maven.plugins/groupId artifactIdmaven-eclipse-compiler/artifactId version1.0/version scopeprovided/scope /dependency /dependencies The LICENSE/NOTICES are at the top level and signatures verify. I do notice that the artifact name is a little inconsistent re. how these things usually appear, e.g. it should really be artifactIdmaven-eclipse-compiler-plugin/artifactId? However it's not bothered me before otherwise I would have raised if on the original thread. Not bothering me enought to -1 this vote unless someone finds another reason to respin. +1 Simon Thanks for voting! Re the artifactid, i think thats as this isn't actually a maven plugin module its a compiler. Our other modules that are proper maven plugins do end in plugin, eg tools\maven\maven-bundle-plugin. ...ant -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
[jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
[ https://issues.apache.org/jira/browse/TUSCANY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673286#action_12673286 ] ant elder commented on TUSCANY-2845: SCA Clients are working now except chained exceptions are getting lost, see TUSCANY-2848 Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException -- Key: TUSCANY-2845 URL: https://issues.apache.org/jira/browse/TUSCANY-2845 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in binding.ws would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate exception from the fault. True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow? Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
[ https://issues.apache.org/jira/browse/TUSCANY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673288#action_12673288 ] Scott Kurz commented on TUSCANY-2845: - Without a spec, I can't think of a better thing to do for now for throwing unchecked exceptions over a binding.jms service than to always use an ObjectMessage, but I think we should do it in a way such that we don't require any SCA or Tuscany code on the client. To do this, we're going to have to accept that we're going to accept that we'll lose the chain of exceptions we may have in the service-side container and simply throw a new java.lang.RuntimeException (and not ServiceRuntimeException), possibly reusing a chained exception's message (or maybe not even). So the non-SCA programming model for dealing with this becomes: // listen for a response if (responseMsg is ObjectMessage) look for RuntimeException in message and deal with this somehow else handle normally the message of=f expected message type (depending on wireFormat) And for an SCA reference we would have to do the same for every wireFormat on the reference side, (and dealing with the RuntimeExc would translate into throwing ServiceRuntimeException). Thoughts? Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException -- Key: TUSCANY-2845 URL: https://issues.apache.org/jira/browse/TUSCANY-2845 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in binding.ws would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate exception from the fault. True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow? Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Update on Databinding Scope Issues
Hi,
In Tuscany, we support a set of XML-friendly databindings such as SDO,
XmlBeans, AXIOM, JAXB, and DOM. If we want to ALLOW (I'm questioning it too)
them to work with JAX-WS/JAXB (a method that takes a mixture of JAXB objects
and other data types), we need to use XmlJavaTypeAdapter to handle the XML/Java
conversion for non-JAXB types. Tuscany databinding framework knows how to
transform the data based on the types. Instead of providing individual
adapters, I'm wondering if we can have a generic one that covers any known
databinding.
The static issue I pointed out was due to the fact that adapters are
instantiated by JAXB runtime using the default constructor. So the adapter is
stateless. To make it work with our databinding framework, the databinding
related extension points are required. I'm not sure if we can inject these
extension points to the generic adapter using a static method. For example,
public class AnyTypeAdapter extends XmlAdapter {
private static DataBindingExtensionPoint databindings;
public static void setDataBindingExtensionPoint(DataBindingExtensionPoint
dbs) {
databindings = dbs;
}
}
Thanks,
Raymond
From: Ramkumar R
Sent: Friday, February 13, 2009 4:12 AM
To: dev@tuscany.apache.org
Subject: Re: Update on Databinding Scope Issues
Hi Raymond,
I have a difficulty in understanding your comment here, Please help me
understand by elaborating a bit more. Thanks.
On Thu, Feb 12, 2009 at 12:08 AM, Raymond Feng enjoyj...@gmail.com wrote:
Hi,
Do we want to generalize the fix a bit to have a XmlJavaTypeAdapter backed by
the databinding framework to deal with XML-friendly types that are not JAXB?
The only difficulty is that the adapter has to access the databinding framework
statically (for example, from a static variable or some context on the thread)
as the instance will be instantiated by the JAXB runtime.
Thanks,
Raymond
From: Ramkumar R
Sent: Wednesday, February 11, 2009 10:10 AM
To: dev@tuscany.apache.org
Subject: Re: Update on Databinding Scope Issues
Hi All,
I am planning to fix the data binding issue with OMElement as described in
https://issues.apache.org/jira/browse/TUSCANY-2664,
by creating a pre-defined XMLAdapter called OMElementXMLAdapter.java as we
have done for CallableReferences earlier.
Please let me know if any one has issues in this fix.
By fixing TUSCANY-2664, we can now claim that we have a complete support for
Axis2 MTOM.
I have opened a seperate JIRA TUSCANY-2840 to track the issue around the
usage of @XmlJavaTypeAdapter in service methods.
On Wed, Feb 11, 2009 at 5:11 PM, Ramkumar R ramkumar...@gmail.com wrote:
Hi Simon,
You are right, by configuring our databinding framework to know about the
types that JAXB struggles, its possible that we will get rid of this issue.
In fact as I mentioned earlier, By adding XMLAdapter's in
DataBindingModuleActivator.java, (as how we do for CallableReferences too) as
shown below.
XMLAdapterExtensionPoint xmlAdapterExtensionPoint =
registry.getExtensionPoint(XMLAdapterExtensionPoint.class);
xmlAdapterExtensionPoint.addAdapter(Exception.class,
ExceptionXMLAdapter.class);
resolves the issue. I believe this solution holds good for some critical
data types like OMElement that we like to support for Axis2 MTOM.
But looking at the broader picture, there might me quite a lot of java
defined interfaces that the user might want to use as a parameter
types (for example java.lang.Exception), so in such cases it would be good
we allow the users to define their own XMLAdapter's and allow them to use with
our databinding framework, rather than we develop pre-defined XMLAdapter
for possible interfaces that can be use.
Please let me know, if you have any comments/sugggestion. Thanks.
On Mon, Feb 9, 2009 at 6:47 PM, Simon Laws simonsl...@googlemail.com
wrote:
On Mon, Feb 9, 2009 at 12:20 PM, Ramkumar R ramkumar...@gmail.com wrote:
As mentioned earlier, since JAXB can't handle interfaces like
org.apache.axiom.om.OMElement OR java.lang.Exception
one way to make this interfaces work with JAXB is to write an
XMLAdapter to convert these data types to the known JAXB data types.
Defining @XmlJavaTypeAdapter annotation with the XMLAdapter as value in
the service method does not seem to work in Tuscany
as I mentioned earlier.
So I tried adding XMLAdapter's in DataBindingModuleActivator.java, as
shown below.
XMLAdapterExtensionPoint xmlAdapterExtensionPoint =
registry.getExtensionPoint(XMLAdapterExtensionPoint.class);
xmlAdapterExtensionPoint.addAdapter(Exception.class,
ExceptionXMLAdapter.class);
This seem to be work fine for me, and now I am able to pass these
interfaces as parameter through JAXB.
Just wanted to make sure, if anyone have tried using
@XmlJavaTypeAdapter annotations with
Re: svn commit: r743992 - /tuscany/java/sca/itest/distribution/bin-distro-unzip/pom.xml
Hi,
Does your JAVA_HOME point to a JRE instead of JDK and there is no tools.jar
under ${java.home}? If that's case, I'm surprised that the previous pom.xml
could work. Please clarify.
Thanks,
Raymond
From: ant elder
Sent: Friday, February 13, 2009 6:24 AM
To: dev@tuscany.apache.org
Subject: Re: svn commit: r743992 -
/tuscany/java/sca/itest/distribution/bin-distro-unzip/pom.xml
On Fri, Feb 13, 2009 at 5:29 AM, rf...@apache.org wrote:
Author: rfeng
Date: Fri Feb 13 05:29:32 2009
New Revision: 743992
URL: http://svn.apache.org/viewvc?rev=743992view=rev
Log:
Add profiles to control if tools.jar should be listed as a system dependency.
tools.jar doesn't exist on Mac OS.
This actually breaks it in my default environment which is i think what other
people might get from a vanilla Java install on windows. I can fix it by
changing java home but it would be nice if we could find a more reliable way to
make this work:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An Ant BuildException has occured: The following error occurred while
executing this line:
C:\Tuscany\SVN\trunk\itest\distribution\binding-ws-calculator\build.xml:36: The
following error occurred while executing
this line:
C:\Tuscany\SVN\trunk\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT-dir\tuscany-sca-2.0-SNAPSHOT\samples\bi
nding-ws-calculator\build.xml:37: Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
...ant
Re: svn commit: r743992 - /tuscany/java/sca/itest/distribution/bin-distro-unzip/pom.xml
On Fri, Feb 13, 2009 at 4:41 PM, Raymond Feng enjoyj...@gmail.com wrote:
Hi,
Does your JAVA_HOME point to a JRE instead of JDK and there is no
tools.jar under ${java.home}? If that's case, I'm surprised that the
previous pom.xml could work. Please clarify.
Something is setting it to point at a JRE during the build run, here's a
complete log output:
C:\Tuscany\SVN\trunk\itest\distributionset JAVA_HOME
JAVA_HOME=\Java\jdk6_07
C:\Tuscany\SVN\trunk\itest\distributionmvn clean install -o
[INFO]
NOTE: Maven is executing in offline mode. Any artifacts not already in your
local
repository will be inaccessible.
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Apache Tuscany SCA Distribution Integration Tests
[INFO] Apache Tuscany SCA Bin Distro Unzip
[INFO] Apache Tuscany SCA Distribution itest binding-ws-calculator
[INFO] Apache Tuscany SCA Distribution itest calculator-rmi
[INFO] Apache Tuscany SCA Distribution itest
implementation-java-calculator
[INFO]
[INFO] Building Apache Tuscany SCA Distribution Integration Tests
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing C:\Tuscany\SVN\trunk\itest\distribution\pom.xml to
C:\Documents and Settings\Administrator\.m2\reposit
ory\org\apache\tuscany\sca\itest-distribution\2.0-SNAPSHOT\itest-distribution-2.0-SNAPSHOT.pom
[INFO]
[INFO] Building Apache Tuscany SCA Bin Distro Unzip
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
C:\Tuscany\SVN\trunk\itest\distribution\bin-distro-unzip\target
[INFO] [resources:resources]
[WARNING] File encoding has not been set, using platform encoding Cp1252,
i.e. build is platform dependent!
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
C:\Tuscany\SVN\trunk\itest\distribution\bin-distro-unzip\src\main\resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
C:\Tuscany\SVN\trunk\itest\distribution\bin-distro-unzip\src\test\resources
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar:
C:\Tuscany\SVN\trunk\itest\distribution\bin-distro-unzip\target\itest-bin-distro-unzip-2.0-SNAPSHOT
.jar
[INFO] [antrun:run {execution: run-samples}]
[INFO] Executing tasks
unzip:
[unzip] Expanding:
C:\Tuscany\SVN\trunk\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT.zip
into C:\Tusc
any\SVN\trunk\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT-dir
[INFO] Executed tasks
[INFO] [install:install]
[INFO] Installing
C:\Tuscany\SVN\trunk\itest\distribution\bin-distro-unzip\target\itest-bin-distro-unzip-2.0-SNAPSHOT.ja
r to C:\Documents and
Settings\Administrator\.m2\repository\org\apache\tuscany\sca\itest-bin-distro-unzip\2.0-SNAPSHOT\i
test-bin-distro-unzip-2.0-SNAPSHOT.jar
[INFO]
[INFO] Building Apache Tuscany SCA Distribution itest binding-ws-calculator
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
C:\Tuscany\SVN\trunk\itest\distribution\binding-ws-calculator\target
[INFO] [resources:resources]
[WARNING] File encoding has not been set, using platform encoding Cp1252,
i.e. build is platform dependent!
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
C:\Tuscany\SVN\trunk\itest\distribution\binding-ws-calculator\src\main\resour
ces
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
C:\Tuscany\SVN\trunk\itest\distribution\binding-ws-calculator\src\test\resour
ces
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar:
C:\Tuscany\SVN\trunk\itest\distribution\binding-ws-calculator\target\itest-distribution-binidng-ws-
calculator-2.0-SNAPSHOT.jar
[INFO] [antrun:run {execution: run-samples}]
[INFO] Executing
[jira] Commented: (TUSCANY-2848) Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format
[ https://issues.apache.org/jira/browse/TUSCANY-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673304#action_12673304 ] Scott Kurz commented on TUSCANY-2848: - I don't think we necessarily need to fix this. If we follow the binding.ws example, which uses the JAX-WS spec mapping between an exception in the Java runtime and the platform-neutral, schema-mappable fault carried by the exception, then we just need to worry about serializing the fault, and not the chained exceptions. This puts a burden on the bottom-up, interface.java programmer to understand this pattern when using checked Java exceptions with the text/xml wireformat. The alternatives would be to either start from WSDL, top-down, and generate the exception/fault, OR to use a different wireFormat, like wireFormat.jmsObject, in which Java serialization will be used and chained exceptions will be preserved (Of course that last alternative assumes a certain spec interpretation which hasn't been agreed upon, but I guess you could say that across the board). Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format - Key: TUSCANY-2848 URL: https://issues.apache.org/jira/browse/TUSCANY-2848 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-Next Reporter: ant elder Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format. It looks like the databinding framework is not including the cause information when converting from the checked exception to XML in an OMElement -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [1.x][2.x] Over zealous PBV handler insertion
Simon Laws wrote:
On Fri, Feb 13, 2009 at 12:19 PM, Simon Nash n...@apache.org
mailto:n...@apache.org wrote:
Simon Laws wrote:
Around line 155 of DataBindingRuntimeWireProcessor there is the code
// assume pass-by-values copies are required if
interfaces are remotable and there is no data binding
// transformation, i.e. a transformation will
result in a copy so another pass-by-value copy is unnecessary
if (!isOnMessage(targetOperation)
isRemotable(chain, sourceOperation, targetOperation)) {
interceptor =
new PassByValueInterceptor(dataBindings,
faultExceptionMapper, chain, targetOperation);
}
We should only be doing this if binding.sca is being used.
TUSCANY-2586 records this problem but there seems to be some
question as to the solution. Why can't we check here what type
of binding is being used? Iassuming that that approach was
discounted.
Simon
It isn't safe to assume that all bindings other than binding.sca
force copies to be made. A user could write binding.foo that
works similarly to binding.sca in that it doesn't do copies on
local invocations.
The solution proposed in the discussion of TUSCANY-2586 solves
this problem by making every binding responsible for deciding
whether the copying needs to be done.
Simon
Ok, good point. My thought was also rubbish as binding.sca doesn't
always need the PBV interceptor:-(
So we need a new binding operation to ask the question whether a copy is
required. In the binding.sca case it needs to take account of whether
it's operating in local or remote mode.
Simon
It's already possible for bindings to add an interceptor to the
chain. If the binding needs a copy, it can add the interceptor.
The binding might also need to consult the provider implementation
to see if @AllowsPassByReference is set.
Simon
Re: [jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
Without a spec, I can't think of a better thing to do for now for throwing unchecked exceptions over a binding.jms service than to always use an ObjectMessage, but I think we should do it in a way such that we don't require any SCA or Tuscany code on the client. At the moment the chosen wireFormat has a bearing on the format of the exception as it's thrown across the (JMS) wire. So in the default/textXML case the exception is passed back over the wire as an XML document. With Ant's latest changes it's arguably better than it was before. We pass back a Text message with the exception XML in it. Intead of a Object message with and Axiom object in it. In the case of Object format you would expect the exception to be in an Object message. If you get into more esoteric wire formats I guess you have to document how exceptions will be passed so that you can pick them up in the non-SCA case. The alternative is to always throw exceptions in the same format. To do this, we're going to have to accept that we're going to accept that we'll lose the chain of exceptions we may have in the service-side container and simply throw a new java.lang.RuntimeException (and not ServiceRuntimeException), possibly reusing a chained exception's message (or maybe not even). So the non-SCA programming model for dealing with this becomes: // listen for a response if (responseMsg is ObjectMessage) look for RuntimeException in message and deal with this somehow else handle normally the message of=f expected message type (depending on wireFormat) We would need to look inside the return message to see what is in there as it might or might not be an exception. And for an SCA reference we would have to do the same for every wireFormat on the reference side, (and dealing with the RuntimeExc would translate into throwing ServiceRuntimeException). Thoughts?
Re: [VOTE] Release Tuscany Maven Eclipse Compiler 1.0
+1 here. Looks good. Luciano Resende wrote: Looks good to me, +1 On Fri, Feb 13, 2009 at 6:35 AM, ant elder antel...@apache.org wrote: On Fri, Feb 13, 2009 at 2:29 PM, Simon Laws simonsl...@googlemail.com wrote: On Fri, Feb 13, 2009 at 11:33 AM, ant elder ant.el...@gmail.com wrote: On Tue, Feb 10, 2009 at 9:52 AM, ant elder ant.el...@gmail.com wrote: Please vote on releasing the Tuscany Maven Eclipse Compiler module. The tag for the release is: https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/maven-eclipse-compiler-1.0/ the Maven staging repository is: http://people.apache.org/~antelder/tuscany/maven-eclipse-compiler-1.0/ ...ant Adding my vote to remind people this is pending still. +1 Also, in case the location of the tag is bothering anyone we can put the tag anywhere we like and can rename and move the tag after the release vote as we do with the SCA releases, eg i've just copied it to https://svn.apache.org/repos/asf/tuscany/tags/java/maven-eclipse-compiler-1.0/ ...ant Just ran a build from the staging repo. Didn't get a clean build but I don't think that's this plugin's fault. B.t.w. For anyone wishing to actually test this you'll need to change the dependency in sca/pom.xml around line 461... dependencies dependency groupIdorg.apache.tuscany.maven.plugins/groupId artifactIdmaven-eclipse-compiler/artifactId version1.0/version scopeprovided/scope /dependency /dependencies The LICENSE/NOTICES are at the top level and signatures verify. I do notice that the artifact name is a little inconsistent re. how these things usually appear, e.g. it should really be artifactIdmaven-eclipse-compiler-plugin/artifactId? However it's not bothered me before otherwise I would have raised if on the original thread. Not bothering me enought to -1 this vote unless someone finds another reason to respin. +1 Simon Thanks for voting! Re the artifactid, i think thats as this isn't actually a maven plugin module its a compiler. Our other modules that are proper maven plugins do end in plugin, eg tools\maven\maven-bundle-plugin. ...ant -- Thanks, Dan Becker
Re: svn commit: r743992 - /tuscany/java/sca/itest/distribution/bin-distro-unzip/pom.xml
It seems that java.home property is not propagated from maven into ant. Can you
try to add a line before the ant ... in the pom.xml?
configuration
tasks
property name=java.home
value=${java.home}/
ant antfile=./build.xml /
/tasks
/configuration
From: ant elder
Sent: Friday, February 13, 2009 8:52 AM
To: dev@tuscany.apache.org
Subject: Re: svn commit: r743992 -
/tuscany/java/sca/itest/distribution/bin-distro-unzip/pom.xml
On Fri, Feb 13, 2009 at 4:41 PM, Raymond Feng enjoyj...@gmail.com wrote:
Hi,
Does your JAVA_HOME point to a JRE instead of JDK and there is no tools.jar
under ${java.home}? If that's case, I'm surprised that the previous pom.xml
could work. Please clarify.
Something is setting it to point at a JRE during the build run, here's a
complete log output:
C:\Tuscany\SVN\trunk\itest\distributionset JAVA_HOME
JAVA_HOME=\Java\jdk6_07
C:\Tuscany\SVN\trunk\itest\distributionmvn clean install -o
[INFO]
NOTE: Maven is executing in offline mode. Any artifacts not already in your
local
repository will be inaccessible.
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Apache Tuscany SCA Distribution Integration Tests
[INFO] Apache Tuscany SCA Bin Distro Unzip
[INFO] Apache Tuscany SCA Distribution itest binding-ws-calculator
[INFO] Apache Tuscany SCA Distribution itest calculator-rmi
[INFO] Apache Tuscany SCA Distribution itest implementation-java-calculator
[INFO]
[INFO] Building Apache Tuscany SCA Distribution Integration Tests
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing C:\Tuscany\SVN\trunk\itest\distribution\pom.xml to
C:\Documents and Settings\Administrator\.m2\reposit
ory\org\apache\tuscany\sca\itest-distribution\2.0-SNAPSHOT\itest-distribution-2.0-SNAPSHOT.pom
[INFO]
[INFO] Building Apache Tuscany SCA Bin Distro Unzip
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
C:\Tuscany\SVN\trunk\itest\distribution\bin-distro-unzip\target
[INFO] [resources:resources]
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e.
build is platform dependent!
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
C:\Tuscany\SVN\trunk\itest\distribution\bin-distro-unzip\src\main\resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
C:\Tuscany\SVN\trunk\itest\distribution\bin-distro-unzip\src\test\resources
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar:
C:\Tuscany\SVN\trunk\itest\distribution\bin-distro-unzip\target\itest-bin-distro-unzip-2.0-SNAPSHOT
.jar
[INFO] [antrun:run {execution: run-samples}]
[INFO] Executing tasks
unzip:
[unzip] Expanding:
C:\Tuscany\SVN\trunk\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT.zip
into C:\Tusc
any\SVN\trunk\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT-dir
[INFO] Executed tasks
[INFO] [install:install]
[INFO] Installing
C:\Tuscany\SVN\trunk\itest\distribution\bin-distro-unzip\target\itest-bin-distro-unzip-2.0-SNAPSHOT.ja
r to C:\Documents and
Settings\Administrator\.m2\repository\org\apache\tuscany\sca\itest-bin-distro-unzip\2.0-SNAPSHOT\i
test-bin-distro-unzip-2.0-SNAPSHOT.jar
[INFO]
[INFO] Building Apache Tuscany SCA Distribution itest binding-ws-calculator
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
C:\Tuscany\SVN\trunk\itest\distribution\binding-ws-calculator\target
[INFO] [resources:resources]
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e.
build is platform dependent!
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
C:\Tuscany\SVN\trunk\itest\distribution\binding-ws-calculator\src\main\resour
ces
[INFO] Copying 0
[jira] Commented: (TUSCANY-2848) Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format
[ https://issues.apache.org/jira/browse/TUSCANY-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673313#action_12673313 ] ant elder commented on TUSCANY-2848: Yes that sounds reasonable to me too. One thing though is we'll be breaking backward compatibility which users may be relying on, we did have a user complain when we changed this area in 1.4 - http://apache.markmail.org/message/diehalz27tklk2gd and we had to fix it for them, not sure if they were relying on using chained exceptions, i'll try to find out Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format - Key: TUSCANY-2848 URL: https://issues.apache.org/jira/browse/TUSCANY-2848 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-Next Reporter: ant elder Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format. It looks like the databinding framework is not including the cause information when converting from the checked exception to XML in an OMElement -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [1.x][2.x] Over zealous PBV handler insertion
On Fri, Feb 13, 2009 at 5:08 PM, Simon Nash n...@apache.org wrote:
Simon Laws wrote:
On Fri, Feb 13, 2009 at 12:19 PM, Simon Nash n...@apache.org mailto:
n...@apache.org wrote:
Simon Laws wrote:
Around line 155 of DataBindingRuntimeWireProcessor there is the
code
// assume pass-by-values copies are required if
interfaces are remotable and there is no data binding
// transformation, i.e. a transformation will
result in a copy so another pass-by-value copy is unnecessary
if (!isOnMessage(targetOperation)
isRemotable(chain, sourceOperation, targetOperation)) {
interceptor =
new PassByValueInterceptor(dataBindings,
faultExceptionMapper, chain, targetOperation);
}
We should only be doing this if binding.sca is being used.
TUSCANY-2586 records this problem but there seems to be some
question as to the solution. Why can't we check here what type
of binding is being used? Iassuming that that approach was
discounted.
Simon
It isn't safe to assume that all bindings other than binding.sca
force copies to be made. A user could write binding.foo that
works similarly to binding.sca in that it doesn't do copies on
local invocations.
The solution proposed in the discussion of TUSCANY-2586 solves
this problem by making every binding responsible for deciding
whether the copying needs to be done.
Simon
Ok, good point. My thought was also rubbish as binding.sca doesn't always
need the PBV interceptor:-(
So we need a new binding operation to ask the question whether a copy is
required. In the binding.sca case it needs to take account of whether it's
operating in local or remote mode.
Simon
It's already possible for bindings to add an interceptor to the
chain. If the binding needs a copy, it can add the interceptor.
The binding might also need to consult the provider implementation
to see if @AllowsPassByReference is set.
Simon
Yes, you can add it manually as it were. But the point I'm pushing on is
whether we need an SPI to explicitly give binding providers a place where
they can add invokers to the wire chains. We have added such a place for the
binding wire work and we could look at rationalizing that if this fits
there.
Simon
Re: [VOTE] Release Tuscany Maven Eclipse Compiler 1.0
+1. Thanks, Raymond From: ant elder Sent: Friday, February 13, 2009 3:33 AM To: dev@tuscany.apache.org Subject: Re: [VOTE] Release Tuscany Maven Eclipse Compiler 1.0 On Tue, Feb 10, 2009 at 9:52 AM, ant elder ant.el...@gmail.com wrote: Please vote on releasing the Tuscany Maven Eclipse Compiler module. The tag for the release is: https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/maven-eclipse-compiler-1.0/ the Maven staging repository is: http://people.apache.org/~antelder/tuscany/maven-eclipse-compiler-1.0/ ...ant Adding my vote to remind people this is pending still. +1 Also, in case the location of the tag is bothering anyone we can put the tag anywhere we like and can rename and move the tag after the release vote as we do with the SCA releases, eg i've just copied it to https://svn.apache.org/repos/asf/tuscany/tags/java/maven-eclipse-compiler-1.0/ ...ant
Re: [jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
Simon, Right, though I just wanted to clarify my proposal involved treating checked and unchecked exceptions differently. I like the idea of handling the checked exception with a wireFormat-specific means (e.g. for object WF just serialize the exc into an ObjectMessage and for dflt text/xml only serialize the fault obtained from the exception per JAX-WS like we do for binding.ws). For the unchecked exceptions, I just threw out there the idea that we construct a java.lang.RuntimeException and send back an ObjectMessage in all cases. An alternative would be to come up with an equivalent representation of RuntimeException for each wireFormat. The latter would seem to be more in the spirit of defining specific wireFormats for specific services. My suggestion has the advantage of there being less to document (and maybe less to code) to explain how this all works. Not sure... Scott On Fri, Feb 13, 2009 at 12:06 PM, Simon Laws simonsl...@googlemail.comwrote: Without a spec, I can't think of a better thing to do for now for throwing unchecked exceptions over a binding.jms service than to always use an ObjectMessage, but I think we should do it in a way such that we don't require any SCA or Tuscany code on the client. At the moment the chosen wireFormat has a bearing on the format of the exception as it's thrown across the (JMS) wire. So in the default/textXML case the exception is passed back over the wire as an XML document. With Ant's latest changes it's arguably better than it was before. We pass back a Text message with the exception XML in it. Intead of a Object message with and Axiom object in it. In the case of Object format you would expect the exception to be in an Object message. If you get into more esoteric wire formats I guess you have to document how exceptions will be passed so that you can pick them up in the non-SCA case. The alternative is to always throw exceptions in the same format. To do this, we're going to have to accept that we're going to accept that we'll lose the chain of exceptions we may have in the service-side container and simply throw a new java.lang.RuntimeException (and not ServiceRuntimeException), possibly reusing a chained exception's message (or maybe not even). So the non-SCA programming model for dealing with this becomes: // listen for a response if (responseMsg is ObjectMessage) look for RuntimeException in message and deal with this somehow else handle normally the message of=f expected message type (depending on wireFormat) We would need to look inside the return message to see what is in there as it might or might not be an exception. And for an SCA reference we would have to do the same for every wireFormat on the reference side, (and dealing with the RuntimeExc would translate into throwing ServiceRuntimeException). Thoughts?
[1.x] Widget enhancements
While our current Widget extension provides good functionality to allow Web 2.0 applications easy access to SCA Services, we have some issues around browser support, JavaScript code optimization, etc. I want to start some prototyping around this area to create some extension points that would allow different bindings to plug it's own version of the JavaScript Proxy used by JavaScript SCA References. With this, we could use specialized frameworks, such as Dojo, and leverage the strengths of such framework and it's native support for things like json-rpc, atom, etc in the Widget Implementation. For now, I'll try to make this optional, but once I start making progress, we could evaluate if we want to continue maintaining our own set of JavaScript, or we are comfortable migrating to use a spcific framework to give us the necessary support. Also, as Dojo already have native support for json-rpc and atom, I'll start playing with that in my prototypes. Thoughts ? -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
