Import.resource and jars, was Fwd: svn commit: r634629 - in /incubator/tuscany/java/sca/tutorial/store/uiservices: ./ store.html
Hi Sebastien
What issues were you experiencing when using Import.resources with
jars ? Are there any specific steps to reproduce it ?
Thanks
-- Forwarded message --
From: [EMAIL PROTECTED]
Date: Fri, Mar 7, 2008 at 4:04 AM
Subject: svn commit: r634629 - in
/incubator/tuscany/java/sca/tutorial/store/uiservices: ./ store.html
To: [EMAIL PROTECTED]
Author: jsdelfino
Date: Fri Mar 7 04:04:38 2008
New Revision: 634629
URL: http://svn.apache.org/viewvc?rev=634629view=rev
Log:
Add store.html to the store module for now as import.resource does
not seem to work properly with JARs.
Added:
incubator/tuscany/java/sca/tutorial/store/uiservices/
incubator/tuscany/java/sca/tutorial/store/uiservices/store.html
(with props)
Added: incubator/tuscany/java/sca/tutorial/store/uiservices/store.html
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/tutorial/store/uiservices/store.html?rev=634629view=auto
==
--- incubator/tuscany/java/sca/tutorial/store/uiservices/store.html (added)
+++ incubator/tuscany/java/sca/tutorial/store/uiservices/store.html
Fri Mar 7 04:04:38 2008
@@ -0,0 +1,138 @@
+!--
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* License); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+--
+html
+head
+titleStore/title
+
+script type=text/javascript src=store.js/script
+
+script language=JavaScript
+
+ //@Reference
+ var catalog = new Reference(catalog);
+
+ //@Reference
+ var shoppingCart = new Reference(shoppingCart);
+
+ //@Reference
+ var shoppingTotal = new Reference(shoppingTotal);
+
+ var catalogItems;
+
+ function catalog_getResponse(items) {
+ var catalog = ;
+ for (var i=0; iitems.length; i++) {
+ var item = items[i].name + ' - ' + items[i].price;
+ catalog += 'input name=items
type=checkbox value=' +
+ item + '' + item + ' br';
+ }
+ document.getElementById('catalog').innerHTML=catalog;
+ catalogItems = items;
+ }
+
+ function shoppingCart_getResponse(feed) {
+ if (feed != null) {
+ var entries = feed.getElementsByTagName(entry);
+ var list = ;
+ for (var i=0; ientries.length; i++) {
+ var content =
entries[i].getElementsByTagName(content)[0];
+ var name =
content.getElementsByTagName(name)[0].firstChild.nodeValue;
+ var price =
content.getElementsByTagName(price)[0].firstChild.nodeValue;
+ list += name + ' - ' + price + ' br';
+ }
+
document.getElementById(shoppingCart).innerHTML = list;
+
+ if (entries.length != 0) {
+
shoppingTotal.getTotal(shoppingTotal_getTotalResponse);
+ }
+ }
+ }
+
+ function shoppingTotal_getTotalResponse(total) {
+ document.getElementById('total').innerHTML = total;
+ }
+
+ function shoppingCart_postResponse(entry) {
+ shoppingCart.get(, shoppingCart_getResponse);
+ }
+
+ function addToCart() {
+ var items = document.catalogForm.items;
+ var j = 0;
+ for (var i=0; iitems.length; i++)
+ if (items[i].checked) {
+ var entry = 'entry
xmlns=http://www.w3.org/2005/Atom;titleitem/titlecontent
type=text/xml' +
+ 'Item xmlns=http://services/;' +
+ 'name xmlns=' + catalogItems[i].name +
'/name' + 'price xmlns=' + catalogItems[i].price + '/price' +
+ '/Item' + '/content/entry';
+ shoppingCart.post(entry,
shoppingCart_postResponse);
+ items[i].checked = false;
+ }
+ }
+ function checkoutCart() {
+
Re: [Spec Related] 'provides' attribute in PolicySet
Ok, I am going to fix this as follows : - - am keeping the name in the PolicyIntent and PolicySet model as QName and assign for the namespaceURI, the targetNamespace specified for the defintions.xml in question - elsewhere in the definitions.xml where the intents defined here are referenced, such as in Profile Intents or PolicySets, the intent names will be used in qualified form with an appropriate prefix that points to the targetnamespace. - Venkat On Sat, Mar 8, 2008 at 3:40 AM, Greg Dritschler [EMAIL PROTECTED] wrote: See below. On Fri, Mar 7, 2008 at 12:11 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Thinking a bit futher about this, I am wondering what would we expect for 'requires' attribute of a ProfileIntent. Do we assume that the intents required by the Profile Intent should also belong to the same namespace as the Profile Intent ? I guess not. Right. @requires takes a list of QNames so it can be composed of intents in various namespaces. I can see someone wanting to create a profile intent in their own namespace that uses intents in other standard namespaces. How about the case of the 'provides' attribute for PolicySets ? Do we say these must be QNames strictly even if the PolicySet was just about providing for intents in the same namespace ? @provides is also a list of QNames so the usual rules for the prefix should be followed. If there is no prefix, then xmlns is used by default (not targetNamespace). If you want @provides to refer to an intent that's defined in the same definitions.xml, you need to define a namespace prefix for it (with the same value as targetNamespace) and use the prefix appropriately. Am just about trying to understand if the targetnamespace is to be applied only to Intent and PolicySet names and not to where they might be referrred within the same definitions.xml file. - Venkat On Fri, Mar 7, 2008 at 10:09 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Ok. I seemed to have lost the plot down the line. Now that I have re-read Mike's explanation in this thread, it does seem like you have a point. - Venkat On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler [EMAIL PROTECTED] wrote: No. The type of @name is either NCName or QName. It cannot be both. If it is an NCName, then it cannot have a namespace prefix; the namespace is always the targetNamespace. If it is a QName, then it can have a namespace prefix; if it does not have a prefix then it uses the default namespace from xmlns. The spec says @name is a QName, but I thought from the above discussion that we had concluded this is not correct and that it should be an NCName. On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Greg, Yes, it seems that when the PolicySet name is a NCName it does not assume the targetNamespace as its namespace. I shall fix this rightaway. But then, I suppose its ok for a PolicySet name to be a QName when it is desired to have the PolicySet take a namespace other than the targetNamespace. i.e. all policysets in a definitions.xml need not belong to the same namespace. Do you share this thought ? Thanks - Venkat If a PolicySet name does not have a prefix it assumes the targetNamespace. If a On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Venkat, I was trying some stuff with policy sets and noticed the QName resolution wasn't working as I expected. Specifically the targetNameSpace attribute of the definitions.xml document doesn't appear to be used to form the QName of the policy sets within. I recalled we had discussed this in this old thread. PolicySetProcessor does this: policySet.setName(getQName(reader, NAME)); So it is trying to treat the @name attribute as a QName. I thought we had concluded it is an NCName. For comparison CompositeProcessor does this: composite.setName(new QName(getString(reader, TARGET_NAMESPACE), getString(reader, NAME))); This is what I thought would happen based on this discussion. On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards [EMAIL PROTECTED] wrote: Venkat, I was out on vacation when your original question was posted, so here's my contribution. Venkata Krishnan wrote: Thanks Raymond. A few more questions ;-) - The xsd defines the name attribute for PolicyIntent and PolicySet as of type NCName. However we have model these in the model classes QNames. I am assuming that the namespace uri for all intents and
Support for binding config in definitions.xml
I'd like to add support for the request/response Connection attributes of the JMS binding (see lines 119 and 123 of the JMS binding spec) and wondered if the existing code in the policy framework would be able to support this today or if I'd need to extend it with some new SPI or something? These attributes enable defining jms binding configurations in a definitions.xml file and referring to those from the binding in a composite, eg: composite service binding.jms requestConnection=StockQuoteService / /service . . . /composite and definitions binding.jms name=StockQuoteService initialContextFactory= org.apache.activemq.jndi.ActiveMQInitialContextFactory jndiURL=tcp://localhost:61616 destination name=StockQuoteServiceQueue create=never/ connectionFactory name=StockQuoteServiceQCF create=never/ /binding.jms /definitions Does anyone who know the policy code have any comments, suggestions or hints? ...ant
Re: Support for binding config in definitions.xml
Hi Ant, I suppose this is going to simply use the StAX processor that we currently have for jms binding. That being the case I see there is going to be circular dependency issues If this is sorted out, I guess then the definitions processor will just about be able to read this instance of binding.jms and add it to the model resolver. Then the binding instance that is referring to this in the composite should resolve this with the model resolver. Thanks - Venkat On Sat, Mar 8, 2008 at 4:32 PM, ant elder [EMAIL PROTECTED] wrote: I'd like to add support for the request/response Connection attributes of the JMS binding (see lines 119 and 123 of the JMS binding spec) and wondered if the existing code in the policy framework would be able to support this today or if I'd need to extend it with some new SPI or something? These attributes enable defining jms binding configurations in a definitions.xml file and referring to those from the binding in a composite, eg: composite service binding.jms requestConnection=StockQuoteService / /service . . . /composite and definitions binding.jms name=StockQuoteService initialContextFactory= org.apache.activemq.jndi.ActiveMQInitialContextFactory jndiURL=tcp://localhost:61616 destination name=StockQuoteServiceQueue create=never/ connectionFactory name=StockQuoteServiceQCF create=never/ /binding.jms /definitions Does anyone who know the policy code have any comments, suggestions or hints? ...ant
Re: [Spec Related] 'provides' attribute in PolicySet
I have fixed this under r634975. Thanks - Venkat On Sat, Mar 8, 2008 at 3:33 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Ok, I am going to fix this as follows : - - am keeping the name in the PolicyIntent and PolicySet model as QName and assign for the namespaceURI, the targetNamespace specified for the defintions.xml in question - elsewhere in the definitions.xml where the intents defined here are referenced, such as in Profile Intents or PolicySets, the intent names will be used in qualified form with an appropriate prefix that points to the targetnamespace. - Venkat On Sat, Mar 8, 2008 at 3:40 AM, Greg Dritschler [EMAIL PROTECTED] wrote: See below. On Fri, Mar 7, 2008 at 12:11 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Thinking a bit futher about this, I am wondering what would we expect for 'requires' attribute of a ProfileIntent. Do we assume that the intents required by the Profile Intent should also belong to the same namespace as the Profile Intent ? I guess not. Right. @requires takes a list of QNames so it can be composed of intents in various namespaces. I can see someone wanting to create a profile intent in their own namespace that uses intents in other standard namespaces. How about the case of the 'provides' attribute for PolicySets ? Do we say these must be QNames strictly even if the PolicySet was just about providing for intents in the same namespace ? @provides is also a list of QNames so the usual rules for the prefix should be followed. If there is no prefix, then xmlns is used by default (not targetNamespace). If you want @provides to refer to an intent that's defined in the same definitions.xml, you need to define a namespace prefix for it (with the same value as targetNamespace) and use the prefix appropriately. Am just about trying to understand if the targetnamespace is to be applied only to Intent and PolicySet names and not to where they might be referrred within the same definitions.xml file. - Venkat On Fri, Mar 7, 2008 at 10:09 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Ok. I seemed to have lost the plot down the line. Now that I have re-read Mike's explanation in this thread, it does seem like you have a point. - Venkat On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler [EMAIL PROTECTED] wrote: No. The type of @name is either NCName or QName. It cannot be both. If it is an NCName, then it cannot have a namespace prefix; the namespace is always the targetNamespace. If it is a QName, then it can have a namespace prefix; if it does not have a prefix then it uses the default namespace from xmlns. The spec says @name is a QName, but I thought from the above discussion that we had concluded this is not correct and that it should be an NCName. On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Greg, Yes, it seems that when the PolicySet name is a NCName it does not assume the targetNamespace as its namespace. I shall fix this rightaway. But then, I suppose its ok for a PolicySet name to be a QName when it is desired to have the PolicySet take a namespace other than the targetNamespace. i.e. all policysets in a definitions.xml need not belong to the same namespace. Do you share this thought ? Thanks - Venkat If a PolicySet name does not have a prefix it assumes the targetNamespace. If a On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Venkat, I was trying some stuff with policy sets and noticed the QName resolution wasn't working as I expected. Specifically the targetNameSpace attribute of the definitions.xml document doesn't appear to be used to form the QName of the policy sets within. I recalled we had discussed this in this old thread. PolicySetProcessor does this: policySet.setName(getQName(reader, NAME)); So it is trying to treat the @name attribute as a QName. I thought we had concluded it is an NCName. For comparison CompositeProcessor does this: composite.setName(new QName(getString(reader, TARGET_NAMESPACE), getString(reader, NAME))); This is what I thought would happen based on this discussion. On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards [EMAIL PROTECTED] wrote: Venkat, I was out on vacation when your original question was posted, so here's my contribution. Venkata
[jira] Commented: (TUSCANY-2055) ServiceReference.getConversationID() not returning generated conversation IDs
[
https://issues.apache.org/jira/browse/TUSCANY-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576594#action_12576594
]
Simon Nash commented on TUSCANY-2055:
-
This spec ambiguity was raised with the OASIS SCA-J TC as issue JAVA-31. The
resolution interprets the spec in the way that Simon Laws has suggested and was
as follows. All line numbers and section numbers refer to the current OASIS
working draft of the Java Common Annotations and APIs spec dated 2/28/08.
- - - - - begin OASIS resolution - - - - -
Replace lines 363-367 with the following:
Whether the conversation ID is chosen by the user or is generated by the
system, the client
may access the conversation ID by calling getConversationID() on the current
conversation object.
Replace lines 780-781 with the following:
getConversationID() - Returns the id supplied by the user that will be
associated with
future conversations initiated through this reference, or null if no ID has
been set by the user.
Replace lines 782-785 (section 7.4 ServiceReference) with the following:
setConversationID(Object conversationId) - Set an ID, supplied by the user, to
associate with any future conversation
started through this reference. If the value supplied is null then the id will
be generated
by the implementation. Throws an IllegalStateException if a conversation is
currently
associated with this reference.
ServiceReference.getConversationID() not returning generated conversation IDs
-
Key: TUSCANY-2055
URL: https://issues.apache.org/jira/browse/TUSCANY-2055
Project: Tuscany
Issue Type: Bug
Components: Specification
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams
Assignee: Simon Laws
Fix For: Java-SCA-Next
ServiceReference.getConversationID() returns null unless the Conversation ID
is set by the user.
This is the current implementaiton:
public Object getConversationID() {
return conversationID;
}
It seems that that if the cached ID is null, and there is a valid related
Converasation object then the impl should return the related
Conversation.getConversationID.
--
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-2069) Missing serialization in DirectedGraph
Missing serialization in DirectedGraph -- Key: TUSCANY-2069 URL: https://issues.apache.org/jira/browse/TUSCANY-2069 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0.1 Reporter: Greg Dritschler I have a service with a web service binding that processes its input using an SDO. The service works fine with one client. It also works fine if it is driven once by one client and then driven by multiple clients. But if it is driven initially by multiple clients (2 is enough), various failures occur in org.apache.tuscany.sca.databinding.impl.DirectedGraph. It appears there is a lack of synchronization in this class. Failure 1 - NPE java.lang.NullPointerException at org.apache.tuscany.sca.databinding.impl.DirectedGraph$Node.access$400(DirectedGraph.java:188) at org.apache.tuscany.sca.databinding.impl.DirectedGraph.getShortestPath(DirectedGraph.java:314) at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint.getTransformerChain(DefaultTransformerExtensionPoint.java:302) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:162) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:76) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:183) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:59) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:88) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:192) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:89) at com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.invokeNextInterceptor(RuntimeExtensionManager.java:211) at com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.processMessage(RuntimeExtensionManager.java:96) at com.ibm.ws.soa.sca.runtime.impl.RuntimeTuscanyInterceptor.invoke(RuntimeTuscanyInterceptor.java:154) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTarget(Axis2ServiceProvider.java:852) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:119) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:42) at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:147) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275) Failure 2 - timeout (code is probably looping) WTRN0124I: When the timeout occurred the thread with which the transaction is, or was most recently, associated was Thread[WebContainer : 0,5,main]. The stack trace of this thread when the timeout occurred was: java.util.HashMap.findNonNullKeyEntry(Unknown Source) java.util.HashMap.putImpl(Unknown Source) java.util.HashMap.put(Unknown Source) org.apache.tuscany.sca.databinding.impl.DirectedGraph.getShortestPath(DirectedGraph.java:296) org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint.getTransformerChain(DefaultTransformerExtensionPoint.java:302) org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:162) org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:76) org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:183) org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:59) org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:88) org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:192) org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:89) com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.invokeNextInterceptor(RuntimeExtensionManager.java:211) com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.processMessage(RuntimeExtensionManager.java:96) com.ibm.ws.soa.sca.runtime.impl.RuntimeTuscanyInterceptor.invoke(RuntimeTuscanyInterceptor.java:154)
Re: Import.resource and jars, was Fwd: svn commit: r634629 - in /incubator/tuscany/java/sca/tutorial/store/uiservices: ./ store.html
Luciano Resende wrote: Hi Sebastien What issues were you experiencing when using Import.resources with jars ? Are there any specific steps to reproduce it ? Thanks I was using the tutorial/store module and the resource resolver was not able to find the HTML file in tutorial/assets. To reproduce the problem, do the following: 1) in tutorial/domain start LaunchTutorialAdmin. 2) point your Web browser to http://localhost:9990/ui/workspace to make sure it started ok. 3) in tutorial/store start LaunchStore. If you run into the same issue as me, you will see some warnings with the Widget component if uiservices/store.html is in tutorial/assets instead of tutorial/store (because store.html can't be found). -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
