[jira] Assigned: (TUSCANY-1482) CompositeProcessor does not write out Property objects completely
[ https://issues.apache.org/jira/browse/TUSCANY-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkatakrishnan reassigned TUSCANY-1482: Assignee: Venkatakrishnan CompositeProcessor does not write out Property objects completely - Key: TUSCANY-1482 URL: https://issues.apache.org/jira/browse/TUSCANY-1482 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Reporter: Brent Daniel Assignee: Venkatakrishnan Fix For: Java-SCA-1.0 CompositeProcessor will write out a Property with its name, but will ignore other attributes such as source, many, or must supply. This is true of both component properties and composite properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RDB DAS] Consistent use of Parameters in Config
Thanks Kevin, for correcting the example, I actually meant what you have
assumed :)
Also, another question in JDK5 context, the code will be very precise and
type checking/assumptions about types can be avoided in many places in DAS
using JDK5 generics. Other features from JDK5 can be used too. So, I am just
curious to know the different
pros and cons about using JDK1.4 vs. using JDK5.
Regards,
Amita
On 8/30/07, Kevin Williams [EMAIL PROTECTED] wrote:
This sounds good to me since programming model consistency is so very
important. I agree that partial index specification should *not* be
supported. I was concerned by your example:
Parameters
Parameter name=ID index=1/ -- rest of the attributes optional
Parameter name=LASTNAME / -- rest of the attributes optional
Parameter name=ADDRESS / -- rest of the attributes optional
/Parameters
But, i assume you meant
Parameters
Parameter name=ID index=1/ -- rest of the attributes optional
Parameter name=LASTNAME index=2/ -- rest of the
attributes optional
Parameter name=ADDRESS index=3/ -- rest of the attributes
optional
/Parameters
--Kevin
On 8/29/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Below is one of the use cases where user will get some benefit:-
USE CASE:
bigtable{col1, col2,col50}
SIMPLEST CLIENT CODE: WITH NAMED PARAM SUPPORT
Command insertAdhoc = das.createCommand(insert into bigtable values (?,
?,
?...50 times));
insertAdhoc.setParameter(ID, new Integer(6));
insertAdhoc.setParameter(LASTNAME, MyLastName);
insertAdhoc.setParameter(ADDRESS, MyLastAddress);
...
insertAdhoc.setParameter(Param50, Value50);
COMPARE WITH EXISTING WAY: WITHOUT NAMED PARAM SUPPORT
Command insertAdhoc = das.createCommand(insert into bigtable values (?,
?,
?...50 times));
insertAdhoc.setParameter(1, new Integer(6));
insertAdhoc.setParameter(2, MyLastName);
insertAdhoc.setParameter(3, MyLastAddress);
...
insertAdhoc.setParameter(50, Value50);
Summary of previous discussion and main intention of this JIRA is to
support
the below features:-
1) Add attribute Name to parameter for user convenience/readability
2) Support command.setParameter(name, value) for user
convenience/readability
3) Preserve existing ways of using parameters - e.g.
A
Continue supporting -
Table tableName=CUSTOMER
create sql=insert into customer values (?, ?, ?)
Parameters List=ID LASTNAME ADDRESS /Parameters
/create
/Table
But also support -
Table tableName=CUSTOMER
create sql=insert into customer values (?, ?, ?)
Parameters
Parameter name=ID index=1/ -- rest of the attributes
optional
Parameter name=LASTNAME / -- rest of the attributes optional
Parameter name=ADDRESS / -- rest of the attributes optional
/Parameters
/create
/Table
Note: if +ve index is specified in Parameter, it is used, else
auto-increment similar to A is used. As List is an ordered collection,
the
sequence appearing in the cofig file will be maintained. Partially
specifying indexes is not supported (i.e. give index for 2 out of 3
params
and leave one without it, is not supported)
B
Continue supporting -
cmd.setParameter(1, new Integer(1)); cmd.getParameter(1);
But also support -
cmd.setParameter(BOOKS.BOOK_ID, new Integer(1));
cmd.getParameter(BOOKS.BOOK_ID);
C
Continue supporting -
Command...
Parameter/
Parameter/
/Command
And
Command..No Params in Config, but directly
setParameter(idx/name,
value) in program
/Command
But also support
Command insertAdhoc = das.createCommand(insert into CUSTOMER values (?,
?,
?));
insertAdhoc.setParameter(ID, new Integer(6));
insertAdhoc.setParameter(LASTNAME, MyLastName);
insertAdhoc.setParameter(ADDRESS, MyLastAddress);
Note: Convention over config is followed, if Parameters are not defined
in
config, the sequence
should match the table columns [convention],else user should specify
params
on command in config and specify index attributes in them [config]
4) This JIRA code will benefit a lot by use of JDK5 generics, but as DAS
is
still at JDK1.4 level current code does not use generics.
5) Changes in config -
xsd:complexType name=Create
xsd:sequence
xsd:element maxOccurs=1 minOccurs=0 name=Parameters
type=config:Parameters/
/xsd:sequence
xsd:attribute name=sql type=xsd:string/
/xsd:complexType
Similar for Update and Delete.
xsd:complexType name=Parameter
xsd:attribute name=name type=xsd:string/
xsd:attribute name=columnType type=xsd:string/
xsd:attribute name=direction type=xsd:string default=IN/
xsd:attribute name=index type=xsd:int/
/xsd:complexType
Re: Generating Eclipse WTP Web Projects for our Webapp samples
On 8/30/07, haleh mahbod [EMAIL PROTECTED] wrote: done On 8/29/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] haleh mahbod wrote: Should this be added to this guide? http://incubator.apache.org/tuscany/sca-java-development-guide.html If yes, I'll add it in. Yes I think it'll be useful. Thanks :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Sebastien Have added it as a FAQ entry also. Simon
Re: Tuscany plugin for Geronimo moved from Geronimo sandbox to Geronimo Plugins
I'm getting a compile error building this as one of the Tuscany interfaces has been changed recently. Is it intended to be used with the Tuscany trunk or with a particular release of Tuscany? ...ant On 8/29/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have moved the Tuscany Plugin for Geronimo from sandbox to Geronimo Plugins. The svn URL is https://svn.apache.org/repos/asf/geronimo/plugins/tuscany . I had to add a few additional repositories to the parent pom so that the plugin can be built successfully with a clean m2 local repository. The plugin can be installed on Geronimo 2.0.1. There is a version of the plugin for Geronimo Tomcat distribution and another for Geronimo Jetty distribution. There are a few samples in Geronimo sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/samplesthat can be used with the plugin. Thanks and regards, Vamsi
[jira] Updated: (TUSCANY-1500) Many callback tests don't run
[ https://issues.apache.org/jira/browse/TUSCANY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1500: Attachment: ImplementationProvider2.java This file is part of patch 4. It must be added to the repository before applying the clanges in the patch4 file. Many callback tests don't run - Key: TUSCANY-1500 URL: https://issues.apache.org/jira/browse/TUSCANY-1500 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-1.0 Attachments: ImplementationProvider2.java, patch1, patch2, patch3 The following itests are currently disabled in the build. If they are enabled by changing the name of the test class from xxxTest to xxxTestCase, they fail with various errors. callback-api callback-complex-type callback-id callback-set-callback callback-set-conversation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementation.osgi and SCA annotations
Haleh, At the moment implementation.osgi/ looks like this: tuscany:implementation.osgi bundle=supplychain.Customer bundleLocation=file:target/factory/Customer.jar scope=STATELESS allowsPassByReference=supplychain.OSGiCustomerImpl / The bundle location is in implementation.osgi/ temporarily and will eventually come from the contribution. The other attributes correspond to equivalent annotations in SCA Java implementation (@Scope and @AllowsPassByReference in the example). OSGi bundles are not introspected by implementation.osgi. Interfaces exposed through SCA services have to be provided outside the bundle since Tuscany needs to read them (and because they can be potentially used by non-OSGi implementation types in SCA). Hence annotations from interfaces are processed - so @Remotable is processed as an annotation and does not have an equivalent implementation.osgi/ attribute. Since the implementation.osgi/ attributes are non-standard and inconsistent with Java, we would like to remove these and instead introduce annotation support for OSGi implementation classes (@Scope and @AllowsPassByReference will be processed from the implementation classes contained in the OSGi bundle). With this change, we would also be able to support property injection through the use of @Property annotations, which is not currently supported. Thank you... Regards, Rajini On 8/30/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi Rajini, This may be clear to many, but I am trying to catch up and understand what we are doing in this space. Can you please explain which scenarios are working and what is not working and how your suggestion relates to those scenarios. Thanks Haleh On 8/29/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, We would like to start supporting SCA annotations in implementation classes used inside OSGi bundles to make implementation.osgi consistent with implementation.java. In the current implementation, SCA annotations are only supported for annotations used in interfaces, since we were keen on supporting existing OSGi bundles without any change. This meant that additional SCA properties like @AllowsPassByReference had to be supported through additional attributes on the implementation.osgi/ element. But since these properties do not have an OSGi equivalent, they cannot be used with existing OSGi bundles, and for new implementations which support these properties, we would like to support SCA annotations to make the OSGi implementation consistent with the Java implementation. This is a fairly big change in implementation.osgi, and I would like your views on whether this is a good time to make the change, so that the implementation will reflect the long-term strategy in the next release. I can submit a patch early next week if it can be integrated before the release. Thank you... Regards, Rajini
Re: implementation.osgi and SCA annotations
On 8/29/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, We would like to start supporting SCA annotations in implementation classes used inside OSGi bundles to make implementation.osgi consistent with implementation.java. In the current implementation, SCA annotations are only supported for annotations used in interfaces, since we were keen on supporting existing OSGi bundles without any change. This meant that additional SCA properties like @AllowsPassByReference had to be supported through additional attributes on the implementation.osgi/ element. But since these properties do not have an OSGi equivalent, they cannot be used with existing OSGi bundles, and for new implementations which support these properties, we would like to support SCA annotations to make the OSGi implementation consistent with the Java implementation. This is a fairly big change in implementation.osgi, and I would like your views on whether this is a good time to make the change, so that the implementation will reflect the long-term strategy in the next release. I can submit a patch early next week if it can be integrated before the release. If you think it can be done in time then I think you should go for it, i'd commit any patches for you. The next release is 1.0 with the branch for that being taken around the 14th of September. If you can get patches submitted by at least a few days before then and the testcases and samples are working after the changes then I can't see any problem with going ahead now. Just to confirm one thing, are the changes going to be backward compatible, i.e. would SCDL that works today keep on working after the changes are done? ...ant
Re: Is there value in keeping download links for old releases?
The Eclipse STP project isn't using M2 because they accidentally downloaded the wrong release, its what was current at the time and they haven't migrated to a newer release yet. I think its good to keep old releases to (1) show the release history, and (2) have historical downloads available for people working on back level systems. No problem with rearranging the website if it makes the current release more obvious but i don't think old ones should just be deleted or hidden. ...ant On 8/30/07, haleh mahbod [EMAIL PROTECTED] wrote: I'd like to bring this message back to life. A few users posted to the ML recently and asked about M2. Immediate response has been to use the latest since M2 is very old (IMHO makes sense). This email thread was suggesting to remove the download link of very old releases to avoid confusion. We can leave the release history in place to show that there was a release, but remove the link for download to avoid confusion. If everyone agrees, when does a link get removed, in other words, how old the release should be? For starter, M2 is based on an older version of the spec. Should we remove the download link? On 8/10/07, ant elder [EMAIL PROTECTED] wrote: On 8/10/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, The latest release for each subproject is the preferred release to download. Does it make sense to keep links to download for old releases on the download page? This can give a wrong impression that these are also OK to download. For example, for Java SCA there are still links to M1 and M2 from last year. Architecture has changed since then. Does it make sense to have the latest release and the previous release as an option for download and leave everything else under history or remove them? Haleh I think yes we should keep them. One of the first things I look at when coming across an open source project is the release history as it gives you a good indication of how much life there is in the project. Maybe from that we don't need actual links to the download artifacts, but something clearly showing we do regular releases and have been doing so for years is a Good Thing IMHO. Another reason is if someone is debugging some old system with a back level release they may need access to the source distro to debug the code. ...ant
Re: implementation.osgi and SCA annotations
Ant, Thank you. I was planning to remove the support for implementation.osgi/ attributes, making it not backward compatible. That was one of the reasons I wanted to introduce the change before 1.0. Is that a problem? Thank you... Regards, Rajini On 8/30/07, ant elder [EMAIL PROTECTED] wrote: On 8/29/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, We would like to start supporting SCA annotations in implementation classes used inside OSGi bundles to make implementation.osgi consistent with implementation.java. In the current implementation, SCA annotations are only supported for annotations used in interfaces, since we were keen on supporting existing OSGi bundles without any change. This meant that additional SCA properties like @AllowsPassByReference had to be supported through additional attributes on the implementation.osgi/ element. But since these properties do not have an OSGi equivalent, they cannot be used with existing OSGi bundles, and for new implementations which support these properties, we would like to support SCA annotations to make the OSGi implementation consistent with the Java implementation. This is a fairly big change in implementation.osgi, and I would like your views on whether this is a good time to make the change, so that the implementation will reflect the long-term strategy in the next release. I can submit a patch early next week if it can be integrated before the release. If you think it can be done in time then I think you should go for it, i'd commit any patches for you. The next release is 1.0 with the branch for that being taken around the 14th of September. If you can get patches submitted by at least a few days before then and the testcases and samples are working after the changes then I can't see any problem with going ahead now. Just to confirm one thing, are the changes going to be backward compatible, i.e. would SCDL that works today keep on working after the changes are done? ...ant
Re: implementation.osgi and SCA annotations
If thats the way to go then doing it now would be better than after 1.0 is out. But why can't the SCDL attributes be kept as well as supporting annotations and doesn't supporting both then mean non-SCA aware OSGi bundles can still be used with Tuscany? (not particularly concerned about this,would just like to understand) ...ant On 8/30/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Ant, Thank you. I was planning to remove the support for implementation.osgi/ attributes, making it not backward compatible. That was one of the reasons I wanted to introduce the change before 1.0. Is that a problem? Thank you... Regards, Rajini On 8/30/07, ant elder [EMAIL PROTECTED] wrote: On 8/29/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, We would like to start supporting SCA annotations in implementation classes used inside OSGi bundles to make implementation.osgi consistent with implementation.java. In the current implementation, SCA annotations are only supported for annotations used in interfaces, since we were keen on supporting existing OSGi bundles without any change. This meant that additional SCA properties like @AllowsPassByReference had to be supported through additional attributes on the implementation.osgi/ element. But since these properties do not have an OSGi equivalent, they cannot be used with existing OSGi bundles, and for new implementations which support these properties, we would like to support SCA annotations to make the OSGi implementation consistent with the Java implementation. This is a fairly big change in implementation.osgi, and I would like your views on whether this is a good time to make the change, so that the implementation will reflect the long-term strategy in the next release. I can submit a patch early next week if it can be integrated before the release. If you think it can be done in time then I think you should go for it, i'd commit any patches for you. The next release is 1.0 with the branch for that being taken around the 14th of September. If you can get patches submitted by at least a few days before then and the testcases and samples are working after the changes then I can't see any problem with going ahead now. Just to confirm one thing, are the changes going to be backward compatible, i.e. would SCDL that works today keep on working after the changes are done? ...ant
Re: [SDO Java] What shall we do next?
Hi Amita, I'm not aware of anyone planning to fix 761. There were a couple of possible approaches, either or both of which could be developed. Ron Gavlin painted a scenario in the JIRA where dropping of individual types from a namespace would be the right thing to do. There's also discussion of dropping whole HelperContexts, which raises again the question of how we might establish dependencies between HelperContexts. This could be a useful discussion to open up and get a design in place for. As to your scenario of changing a type, it would be good to check through the scenarios you envisage. The current Tuscany API implementations permit alteration of Types after they have been used, whereas the SDO API implementations freeze the types at creation time. Depending on which scenarios we support the user would have to take care to ensure certain preconditions before calling a method such as createOrReplaceType(). My guess is that this method would end up as a simple convenience method, involving calls to the type dropping and creation methods. Here are some attributes of scenarios that we might want to consider in order to see which combinations we support/exclude. Note, exclusion doesn't necessarily imply enforcement by the SDO implementation and this kind of area clearly contains hazards - a Type is removed from a scope (HelperContext) when no DataObjects reference it - a Type is removed from a scope while still referenced by DataObjects - a Type is replaced in a scope while DataObjects still reference the displaced Type instance - a Type is replaced in a scope only when no DataObjects reference the displaced Type instance - Properties are added to a Type after instances of the Type have been created - an instance of a Type is otherwise updated when still referenced by DataObjects (expand ...) - multiple instances of HelperContexts are used to manage multiple instances of Types with the same name and in the same namespace Kelvin. On 30/08/2007, Amita Vadhavkar [EMAIL PROTECTED] wrote: What is the plan for JIRA-761(Support the ability to unregister all the SDO Types in a namespace) Also, I am just trying to understand that in a condition where some Type is defined in using SDOUtil.createType() and later some attributes of it need to change during the same runtime invocation. So user needs SDOUtil.createOrReplaceType() - how this can be done? Regards, Amita On 8/29/07, Fuhwei Lwo [EMAIL PROTECTED] wrote: Hi Kelvin, Based on my observation on opened JIRAs, I agree we definitely should pay attention to the first two items you listed below - test generated static SDO APIs and multi-threaded scenario more easily. I did some investigation on GroboUtils for multi-thread testing and still couldn't find any remote repository hosting the tool so we may need to host the tool ourselves or find an alternative. What do you think? Fuhwei kelvin goodson [EMAIL PROTECTED] wrote: Having released 1.0-incubating, what are the priorities for SDO Java now. I'm just catching up on reading the lists having taken a break. The major things I had in mind before going away were to - rearrange the project structure to permit generation of java classes during maven tests (TUSCANY-1393) - add multi-threaded test cases (TUSCANY-1182) - for the first of the above, while we are in project reorganisation mode it's probably worth fixing TUSCANY-257 to separate out the Java 5 dependencies - It would be great to get some improvement our web pages; and getting some good user documentation together would be really helpful. My brain hasn't completely returned from vacation, so I've probably missed out some obvious things, so please chip in with your opinions, needs and inspirational ideas! Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there value in keeping download links for old releases?
I agree with ant. I had an issue recently with SDO relying on a back-level release that had been removed.So I think the thing to do is to help new users avoid the trip hazard of inadvertently downloading a back level release by structuring our web pages helpfully. Kelvin. On 30/08/2007, ant elder [EMAIL PROTECTED] wrote: The Eclipse STP project isn't using M2 because they accidentally downloaded the wrong release, its what was current at the time and they haven't migrated to a newer release yet. I think its good to keep old releases to (1) show the release history, and (2) have historical downloads available for people working on back level systems. No problem with rearranging the website if it makes the current release more obvious but i don't think old ones should just be deleted or hidden. ...ant On 8/30/07, haleh mahbod [EMAIL PROTECTED] wrote: I'd like to bring this message back to life. A few users posted to the ML recently and asked about M2. Immediate response has been to use the latest since M2 is very old (IMHO makes sense). This email thread was suggesting to remove the download link of very old releases to avoid confusion. We can leave the release history in place to show that there was a release, but remove the link for download to avoid confusion. If everyone agrees, when does a link get removed, in other words, how old the release should be? For starter, M2 is based on an older version of the spec. Should we remove the download link? On 8/10/07, ant elder [EMAIL PROTECTED] wrote: On 8/10/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, The latest release for each subproject is the preferred release to download. Does it make sense to keep links to download for old releases on the download page? This can give a wrong impression that these are also OK to download. For example, for Java SCA there are still links to M1 and M2 from last year. Architecture has changed since then. Does it make sense to have the latest release and the previous release as an option for download and leave everything else under history or remove them? Haleh I think yes we should keep them. One of the first things I look at when coming across an open source project is the release history as it gives you a good indication of how much life there is in the project. Maybe from that we don't need actual links to the download artifacts, but something clearly showing we do regular releases and have been doing so for years is a Good Thing IMHO. Another reason is if someone is debugging some old system with a back level release they may need access to the source distro to debug the code. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementation.osgi and SCA annotations
Ant, The defaults used by implementation.osgi match the default behaviour of OSGi bundles. Scope is set to COMPOSITE, remotable interfaces use pass-by-value, and properties can only be set/read using standard OSGi mechanisms. The attributes provided in implementation.osgi/ which are being replaced by annotations provide support for SCA options in OSGi bundles, but these require changes to the bundle anyway. So it makes sense to add these additional properties in a way that is consistent with SCA, rather than add something which is neither consistent with OSGi nor SCA. Thank you... Regards, Rajini On 8/30/07, ant elder [EMAIL PROTECTED] wrote: If thats the way to go then doing it now would be better than after 1.0 is out. But why can't the SCDL attributes be kept as well as supporting annotations and doesn't supporting both then mean non-SCA aware OSGi bundles can still be used with Tuscany? (not particularly concerned about this,would just like to understand) ...ant On 8/30/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Ant, Thank you. I was planning to remove the support for implementation.osgi/ attributes, making it not backward compatible. That was one of the reasons I wanted to introduce the change before 1.0. Is that a problem? Thank you... Regards, Rajini On 8/30/07, ant elder [EMAIL PROTECTED] wrote: On 8/29/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, We would like to start supporting SCA annotations in implementation classes used inside OSGi bundles to make implementation.osgi consistent with implementation.java. In the current implementation, SCA annotations are only supported for annotations used in interfaces, since we were keen on supporting existing OSGi bundles without any change. This meant that additional SCA properties like @AllowsPassByReference had to be supported through additional attributes on the implementation.osgi/ element. But since these properties do not have an OSGi equivalent, they cannot be used with existing OSGi bundles, and for new implementations which support these properties, we would like to support SCA annotations to make the OSGi implementation consistent with the Java implementation. This is a fairly big change in implementation.osgi, and I would like your views on whether this is a good time to make the change, so that the implementation will reflect the long-term strategy in the next release. I can submit a patch early next week if it can be integrated before the release. If you think it can be done in time then I think you should go for it, i'd commit any patches for you. The next release is 1.0 with the branch for that being taken around the 14th of September. If you can get patches submitted by at least a few days before then and the testcases and samples are working after the changes then I can't see any problem with going ahead now. Just to confirm one thing, are the changes going to be backward compatible, i.e. would SCDL that works today keep on working after the changes are done? ...ant
Re: Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
On 8/30/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Sounds ok to me. In an earlier version of the RMI Binding, I did something like this with the getUri method of Binding class. - Venkat On 8/29/07, ant elder [EMAIL PROTECTED] wrote: I've not yet been able to find any good way to reliably work out the complete service URL in all environments. What i think maybe the best approach is to add a getBaseURI method to the Tuscany ServletHost interface so that can be used by bindings. So then it would be down to each ServletHost impl to set this correctly rather than the Axis2 binding to work it out. So for example for WebappServletHost it would be the webapp url like, http://localhost:8080/helloworld-ws-service-webapp, for the war distro http://localhost:8080/tuscany , for Geronimo http://localhost:8080 etc. Does something like this sound ok or does anyone have any better ideas? ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: One more observation... when the binding URI is http://localhost:8080/hello/HelloWorldService; the service is available at that URL. Only http://localhost:8080/hello/HelloWorldService?wsdl results in an exception. Here is what I did. 1. Deploy the HelloWorld sample with binding URI http://localhost:8080/HelloWorldService . 2. Get the wsdl by accessing http://localhost:8080/HelloWorldService?wsdl; and save to a disk file. 3. Now redeploy HelloWorld sample with binding URI http://localhost:8080/ hello/HelloWorldService. 4. Using WebServices Explorer in Eclipse, and the saved wsdl file from step2, access the service at url in step3. Vamsi On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/26/07, ant elder [EMAIL PROTECTED] wrote: Ok what happens with a uri of http://localhost:8080/HelloWorldService?wsdl http://localhost:8080/hello/HelloWorldService?wsdl I have fixed the problem in plugin code so that it uses a context root / as well. After the fix, I am able to use http://localhost:8080/HelloWorldService?wsdl http://localhost:8080/hello/HelloWorldService?wsdlas uri. And for this uri (that ?wsdl in the uri did not matter), I am able to access the wsdl using http://localhost:8080/HelloWorldService?wsdl http://localhost:8080/hello/HelloWorldService?wsdl (sorry to keep bouncing this back to you, i've not been able to get the Geronimo integration to build locally yet so can't test this myself) Let me see if I can quickly provide the built plugin so that you can install it in Geronimo 2.0.1. ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/26/07, ant elder [EMAIL PROTECTED] wrote: Is /hello the mapping for some Geronimo servlet or application thing? /hello is not mapped to any application. What happens if you change the uri in the SCDL to have binding.wsuri=/HelloWorldService/? In this case, GeronimoServletHost.addServletMapping() is getting invoked with ( http://localhost:8085/HelloWorldService;, Axis2ServiceServlet). Since there is no http connector on 8085, the method is throwing an Exception. Thanks, ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/26/07, ant elder [EMAIL PROTECTED] wrote: So that must mean in the setContextRoot method at line 279 in TuscanyListingAgent that configContext.getContextRoot() is returning http://localhost:8080/hello/ right? configContext.getContextRoot() is returning hello. Can you debug Axis2ServiceServlet on line 230 and see what gets set on th eline configContext.setContextRoot ( request.getContextPath());? request.getContextPath() is evaluating to /hello . Thanks, ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, The URL is http://localhost:8080/hello/HelloWorldService?wsdl; . When I debug the code, I am noticing that in TuscanyListingAgent.processListService () around line 101, the filePart is http://localhost:8080/hello/HelloWorldService and findAxisServiceName() is returning /hello/HelloWorldService. Inside setContextRoot() arounf line 286, mapping = filePart.substring() is getting called with paramters (28, 21) which is resulting in the Exception. That -7 in the exception message is this 21-28. Vamsi On 8/26/07, ant elder [EMAIL PROTECTED] wrote:
[jira] Commented: (TUSCANY-1326) DWR binding should use endpoints as defined in the assembly spec 1.7.2
[ https://issues.apache.org/jira/browse/TUSCANY-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523826 ] ant elder commented on TUSCANY-1326: The main issue would be that the scaDomain.js script is dynamically generated to include initilization statements for each service and reference. If that can still happen with multiple servlets then i guess it shold still work ok. You can see these generated statements by going to the sample SCADomain/scaDomain.js url and they're at the bottom of the returned script. DWR binding should use endpoints as defined in the assembly spec 1.7.2 -- Key: TUSCANY-1326 URL: https://issues.apache.org/jira/browse/TUSCANY-1326 Project: Tuscany Issue Type: Bug Components: Java SCA JSON-RPC Binding Extension Affects Versions: Java-SCA-0.99, Java-SCA-Next Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 The jsonrpc and Ajax bindings currently hardcode the endpoint uri of the services they provide. Instead they should use the algorithm described in the SCA assembly spec section 1.7.2 -- 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]
Writing Composite and Component Properties
Hi, I am working on https://issues.apache.org/jira/browse/TUSCANY-1482 and its mostly done - just the only thing related writing the property values. The Property class has this value as a xml Document already and it would be good if we could simply write that out. Right now I don't see a way to do this from the XMLStreamWriter interface. I am trying to avoid having to parse this document value which is already an XML doc and then write it again as XML which seems a bit absurd. Would it be good to directly make use of the output stream that underlies the XMLStreamWriter ? If so how would the CompositeProcessor's write method avail this ? Are there other alternatives that people can help me with ? Thanks - Venkat
[jira] Assigned: (TUSCANY-1539) The assembly model does not contain the annotated intent information
[
https://issues.apache.org/jira/browse/TUSCANY-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Venkatakrishnan reassigned TUSCANY-1539:
Assignee: Venkatakrishnan
The assembly model does not contain the annotated intent information
Key: TUSCANY-1539
URL: https://issues.apache.org/jira/browse/TUSCANY-1539
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Assembly Model
Environment: r558780
Reporter: Yang Lei
Assignee: Venkatakrishnan
Fix For: Java-SCA-1.0
I am following JavaAnnotationsAndAPIs section 2.3.1 and 2.4 to create an
sample with both intent annotation and SCDL file. I realize no matter I
define intents or not in SCDL, it is alreays the SCDL version get picked up.
I use the following code to load the composite model:
EmbeddedSCADomain domain= new
EmbeddedSCADomain(this.getClass().getClassLoader(),http://+name);
domain.start();
ModelResolver resolver = new ModelResolverImpl(cl);
ContributionService service=
util.getDomain(null).getContributionService();
service.contribute(contributionId, contributionLocation,
resolver, false);
r service.getContribution(contributionId);
I use the following code to display the composite :
Composite composite =null;
for (DeployedArtifact artifact : contribution.getArtifacts()) {
if (artifact.getModel() instanceof Composite) {
if
(artifact.getURI().toString().endsWith(default.composite))
{
composite = ((Composite)artifact.getModel());
break;
}
}
}
if (composite!=null)
{
System.out.println(this is the artifact);
display(composite);
System.out.println(this is the added composite);
domain.getDomainCompositeHelper().addComposite(composite);
display(composite);
System.out.println(this is the started composite);
domain.getDomainCompositeHelper().startComposite(composite);
display(composite);
}
Under all 3 cases, the composite does not contain the annotated intent setting
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
ant elder wrote: I've not yet been able to find any good way to reliably work out the complete service URL in all environments. What i think maybe the best approach is to add a getBaseURI method to the Tuscany ServletHost interface so that can be used by bindings. So then it would be down to each ServletHost impl to set this correctly rather than the Axis2 binding to work it out. So for example for WebappServletHost it would be the webapp url like, http://localhost:8080/helloworld-ws-service-webapp, for the war distro http://localhost:8080/tuscany, for Geronimo http://localhost:8080 etc. Does something like this sound ok or does anyone have any better ideas? ...ant I'm not sure which scenario you have in mind for this, so here are the two use cases I can think of: (1) A binding was configured with a URI like localhost:8080 but will need to tell the world (in generated WSDL, in service endpoint references etc.) the actual endpoint address at which it can be reached, 192.168.1.1:8080 or myhost:8080 for example (2) A binding was configured with a URI, but we are not in a position to provide the service at that exact same URI, because we are running in a Webapp deployed at a different URI for example. I don't really like this use case as I think there's issues with this approach and that we should configure the Web container from the SCA metadata, not the other way around, but I guess we have to live with that for now :) Anyway, in that case as well we need to figure the effective URI of the particular service to put it in service endpoint references for example. For both scenarios, I'd suggest methods like this: ServletHost.getRequestURI(String mapping) - giving you the complete URI that people will have to send requests to or ServletHost.getServletPath(String mapping) - giving you the actual URI at which the particular servlet is available Both methods are modeled after the Servlet API interface, and will give you what you need (assuming I correctly guessed the scenarios you're after) in a simpler way than a getBaseURI() method which would still require the binding to combine that base URI with the rest of the URI that it knows about. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there value in keeping download links for old releases?
ant elder wrote: The Eclipse STP project isn't using M2 because they accidentally downloaded the wrong release, its what was current at the time and they haven't migrated to a newer release yet. I think its good to keep old releases to (1) show the release history, and (2) have historical downloads available for people working on back level systems. No problem with rearranging the website if it makes the current release more obvious but i don't think old ones should just be deleted or hidden. ...ant +1 for keeping links to old releases, but rearranging the download web page to make more obvious that the current release is current and that old releases are old. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
On 8/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: I've not yet been able to find any good way to reliably work out the complete service URL in all environments. What i think maybe the best approach is to add a getBaseURI method to the Tuscany ServletHost interface so that can be used by bindings. So then it would be down to each ServletHost impl to set this correctly rather than the Axis2 binding to work it out. So for example for WebappServletHost it would be the webapp url like, http://localhost:8080/helloworld-ws-service-webapp, for the war distro http://localhost:8080/tuscany, for Geronimo http://localhost:8080 etc. Does something like this sound ok or does anyone have any better ideas? ...ant I'm not sure which scenario you have in mind for this, so here are the two use cases I can think of: (1) A binding was configured with a URI like localhost:8080 but will need to tell the world (in generated WSDL, in service endpoint references etc.) the actual endpoint address at which it can be reached, 192.168.1.1:8080 or myhost:8080 for example (2) A binding was configured with a URI, but we are not in a position to provide the service at that exact same URI, because we are running in a Webapp deployed at a different URI for example. I don't really like this use case as I think there's issues with this approach and that we should configure the Web container from the SCA metadata, not the other way around, but I guess we have to live with that for now :) Anyway, in that case as well we need to figure the effective URI of the particular service to put it in service endpoint references for example. For both scenarios, I'd suggest methods like this: ServletHost.getRequestURI(String mapping) - giving you the complete URI that people will have to send requests to or ServletHost.getServletPath(String mapping) - giving you the actual URI at which the particular servlet is available Both methods are modeled after the Servlet API interface, and will give you what you need (assuming I correctly guessed the scenarios you're after) in a simpler way than a getBaseURI() method which would still require the binding to combine that base URI with the rest of the URI that it knows about. There's also a 3rd case where the binding uses a default or relative uri which the runtime can honour and things like ?wsdl still need to be able to advertise the actual endpoint. Anyway from those three cases it seems like a way to get his from the ServletHost is valid thing to have. From the perspective of whats the simplest way to code this for the ws binding as-is now i suspect a method that returns a complete url from a mapping may not be so easy to use with the current Axis2 code. This area has changed a lot with Axis2 1.3 though so it may depend on if we move up to Axis2 1.3. We'd also have to have all the code to work out the actual ip address or host name for use by the Jetty and Tomcat standalone ServletHosts. How about we just have a ServletHost getContextPath() modeled after the Servlet APIs getContextPath method? ...ant
Re: Tuscany plugin for Geronimo moved from Geronimo sandbox to Geronimo Plugins
The changes are pretty recent, though you might not have seen then unless you use mvn -U. I could give you a patch to get passed the compile error if you like - is this code in the Geronimo JIRA system to raise and attach a patch to? ...ant On 8/30/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: How recent are the changes? I was able to build without errors 24 hrs ago. I have used 1.0-SNAPSHOT. You should be able to build against 0.99-incubating. After your note, I have introduced a tuscanyDasVersion and tuscanySdoVersion in the parent pom, so that the tuscanyVersion can be changed to point to a different version of Tuscany SCA release. Please update the code from svn, try changing tuscanyVersion in parent pom to 0.99-incubating and see if you are able to build successfully. I am travelling for a couple of days and I may not be able to attend to any issues immedaitely as I have very limited connectivity. I will respond as and when possible. Vamsi On 8/30/07, ant elder [EMAIL PROTECTED] wrote: I'm getting a compile error building this as one of the Tuscany interfaces has been changed recently. Is it intended to be used with the Tuscany trunk or with a particular release of Tuscany? ...ant On 8/29/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have moved the Tuscany Plugin for Geronimo from sandbox to Geronimo Plugins. The svn URL is https://svn.apache.org/repos/asf/geronimo/plugins/tuscany . I had to add a few additional repositories to the parent pom so that the plugin can be built successfully with a clean m2 local repository. The plugin can be installed on Geronimo 2.0.1. There is a version of the plugin for Geronimo Tomcat distribution and another for Geronimo Jetty distribution. There are a few samples in Geronimo sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/samplesthat can be used with the plugin. Thanks and regards, Vamsi
Re: Tuscany plugin for Geronimo moved from Geronimo sandbox to Geronimo Plugins
I have created a JIRA for this plugin move into Geronimo plugins. See https://issues.apache.org/jira/browse/GERONIMO-3447. Please attach any patches to this JIRA. Thanks, Vamsi On 8/30/07, ant elder [EMAIL PROTECTED] wrote: The changes are pretty recent, though you might not have seen then unless you use mvn -U. I could give you a patch to get passed the compile error if you like - is this code in the Geronimo JIRA system to raise and attach a patch to? ...ant On 8/30/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: How recent are the changes? I was able to build without errors 24 hrs ago. I have used 1.0-SNAPSHOT. You should be able to build against 0.99-incubating. After your note, I have introduced a tuscanyDasVersion and tuscanySdoVersion in the parent pom, so that the tuscanyVersion can be changed to point to a different version of Tuscany SCA release. Please update the code from svn, try changing tuscanyVersion in parent pom to 0.99-incubating and see if you are able to build successfully. I am travelling for a couple of days and I may not be able to attend to any issues immedaitely as I have very limited connectivity. I will respond as and when possible. Vamsi On 8/30/07, ant elder [EMAIL PROTECTED] wrote: I'm getting a compile error building this as one of the Tuscany interfaces has been changed recently. Is it intended to be used with the Tuscany trunk or with a particular release of Tuscany? ...ant On 8/29/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have moved the Tuscany Plugin for Geronimo from sandbox to Geronimo Plugins. The svn URL is https://svn.apache.org/repos/asf/geronimo/plugins/tuscany . I had to add a few additional repositories to the parent pom so that the plugin can be built successfully with a clean m2 local repository. The plugin can be installed on Geronimo 2.0.1. There is a version of the plugin for Geronimo Tomcat distribution and another for Geronimo Jetty distribution. There are a few samples in Geronimo sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/samplesthat can be used with the plugin. Thanks and regards, Vamsi
Re: implementation.osgi and SCA annotations
Hi, What java classes do you expect to be annotated with SCA annotations in the OSGi bundle? Thanks, Raymond - Original Message - From: Rajini Sivaram [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Sent: Thursday, August 30, 2007 4:05 AM Subject: Re: implementation.osgi and SCA annotations Ant, The defaults used by implementation.osgi match the default behaviour of OSGi bundles. Scope is set to COMPOSITE, remotable interfaces use pass-by-value, and properties can only be set/read using standard OSGi mechanisms. The attributes provided in implementation.osgi/ which are being replaced by annotations provide support for SCA options in OSGi bundles, but these require changes to the bundle anyway. So it makes sense to add these additional properties in a way that is consistent with SCA, rather than add something which is neither consistent with OSGi nor SCA. Thank you... Regards, Rajini On 8/30/07, ant elder [EMAIL PROTECTED] wrote: If thats the way to go then doing it now would be better than after 1.0 is out. But why can't the SCDL attributes be kept as well as supporting annotations and doesn't supporting both then mean non-SCA aware OSGi bundles can still be used with Tuscany? (not particularly concerned about this,would just like to understand) ...ant On 8/30/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Ant, Thank you. I was planning to remove the support for implementation.osgi/ attributes, making it not backward compatible. That was one of the reasons I wanted to introduce the change before 1.0. Is that a problem? Thank you... Regards, Rajini On 8/30/07, ant elder [EMAIL PROTECTED] wrote: On 8/29/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, We would like to start supporting SCA annotations in implementation classes used inside OSGi bundles to make implementation.osgi consistent with implementation.java. In the current implementation, SCA annotations are only supported for annotations used in interfaces, since we were keen on supporting existing OSGi bundles without any change. This meant that additional SCA properties like @AllowsPassByReference had to be supported through additional attributes on the implementation.osgi/ element. But since these properties do not have an OSGi equivalent, they cannot be used with existing OSGi bundles, and for new implementations which support these properties, we would like to support SCA annotations to make the OSGi implementation consistent with the Java implementation. This is a fairly big change in implementation.osgi, and I would like your views on whether this is a good time to make the change, so that the implementation will reflect the long-term strategy in the next release. I can submit a patch early next week if it can be integrated before the release. If you think it can be done in time then I think you should go for it, i'd commit any patches for you. The next release is 1.0 with the branch for that being taken around the 14th of September. If you can get patches submitted by at least a few days before then and the testcases and samples are working after the changes then I can't see any problem with going ahead now. Just to confirm one thing, are the changes going to be backward compatible, i.e. would SCDL that works today keep on working after the changes are done? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please apply patch 4 for TUSCANY-1500
Please can someone review and apply the patch for TUSCANY-1500 that I posted earlier today (patch 4). There's one new file and a number of changes to existing files. Many thanks. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany plugin for Geronimo moved from Geronimo sandbox to Geronimo Plugins
Thanks for the patch. I committed it to svn. Vamsi On 8/30/07, ant elder [EMAIL PROTECTED] wrote: The changes are pretty recent, though you might not have seen then unless you use mvn -U. I could give you a patch to get passed the compile error if you like - is this code in the Geronimo JIRA system to raise and attach a patch to? ...ant On 8/30/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: How recent are the changes? I was able to build without errors 24 hrs ago. I have used 1.0-SNAPSHOT. You should be able to build against 0.99-incubating. After your note, I have introduced a tuscanyDasVersion and tuscanySdoVersion in the parent pom, so that the tuscanyVersion can be changed to point to a different version of Tuscany SCA release. Please update the code from svn, try changing tuscanyVersion in parent pom to 0.99-incubating and see if you are able to build successfully. I am travelling for a couple of days and I may not be able to attend to any issues immedaitely as I have very limited connectivity. I will respond as and when possible. Vamsi On 8/30/07, ant elder [EMAIL PROTECTED] wrote: I'm getting a compile error building this as one of the Tuscany interfaces has been changed recently. Is it intended to be used with the Tuscany trunk or with a particular release of Tuscany? ...ant On 8/29/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have moved the Tuscany Plugin for Geronimo from sandbox to Geronimo Plugins. The svn URL is https://svn.apache.org/repos/asf/geronimo/plugins/tuscany . I had to add a few additional repositories to the parent pom so that the plugin can be built successfully with a clean m2 local repository. The plugin can be installed on Geronimo 2.0.1. There is a version of the plugin for Geronimo Tomcat distribution and another for Geronimo Jetty distribution. There are a few samples in Geronimo sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/samplesthat can be used with the plugin. Thanks and regards, Vamsi
Issue with dynamic creation of NotificationReferenceBindingProvider
Part of the design of binding-notification is that NotificationReferenceBindingProvider serves as a producer service to handle subscription requests from consumers. Because of this, the code was relying on NotificationReferenceBindingProvider being created early, at activation time of components and (component) services. In particular, having NotificationReferenceBindingProvider created at the first invocation from its notification component is too late, as no consumer will be able to subscribe before any message is sent. There may be a few ways to work around this dynamic creation, which I'll try to enumerate, but none of them seem ideal. But my real question is whether it would be possible to make this dynamic or lazy activation of references optional. That is, would it be possible to let the provider factory interface include a supportsDynamicReferenceActivation kind of method. The default return value would be true, but if necessary, the method could return false and then the composite activator would activate the references for this factory eagerly. Thoughts? Dynamic creation work around possiblities: 1- Try to create the producer service in the module activator - One of the problems is that producer service activator is implicit and reliant on the values of the notificationType and ntm attributes in the binding element, which are not known until the binding is processed. Also, the binding object itself does not seem to have a good way to determine the component reference and component that it corresponds to and that are needed to activate the producer service. 2- Try to create the producer service when the notification component is started - It is not clear to me that the hooks are there for the implementation provider to do this either, not to mention the fact that this would add a coupling of the implementation-notification module to the binding-notification module.
Re: Writing Composite and Component Properties
Hi, There are a few ways you can handle this: 1) Use the code in the databinding module: Node2XMLStreamReader and then XMLStreamSerializer 2) Use a BSD-licensed StAXUtils at https://stax-utils.dev.java.net/nonav/javadoc/utils/index.html. // create a DOMSource Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(...); Source domSource = new DOMSource(doc); // create a StAXResult XMLStreamWriter writer = XMLOutputFactory.newInstance().createXMLStreamWriter(System.out); Result staxResult = new StAXResult(writer); // run the transform TransformerFactory.newInstance().newTransformer().transform(domSource, staxResult); Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 30, 2007 6:28 AM Subject: Writing Composite and Component Properties Hi, I am working on https://issues.apache.org/jira/browse/TUSCANY-1482 and its mostly done - just the only thing related writing the property values. The Property class has this value as a xml Document already and it would be good if we could simply write that out. Right now I don't see a way to do this from the XMLStreamWriter interface. I am trying to avoid having to parse this document value which is already an XML doc and then write it again as XML which seems a bit absurd. Would it be good to directly make use of the output stream that underlies the XMLStreamWriter ? If so how would the CompositeProcessor's write method avail this ? Are there other alternatives that people can help me with ? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rationalizing SCA Domain implementations
We now have a number of domain implementations in Tuscany Java SCA including - The SCADomain interface - DefaultSCADomain - EmbeddedSCADomain - HotUpdatableSCADomain - DistributedDomain/Node Covering a number of scenarios - running a domain in a single node - running a domain across multiple nodes - Adding, removing, updating the contributions of a domain through the API and automatically - Activating/deactivating, starting/stopping deployable composites through the API - Starting, stopping components through the API - Locating service in the domain through the API etc. There are some scenarios that we don't cover at the moment - running multiple domains in a VM What else? I would like to propose that we rationalize these various implementations down to a more manageable number. I have a simple model in my mind of the building blocks we have to deal with. 1/ The node. Is responsible for running segregated domains in a VM Associated with zero or more domains. 2/ The domain. Logically knows about all of the artifacts of a domain. Associated with one or more (in the distributed case) nodes. A local representation of the domain (the SCADomain object) provides the interface to wider domain There are some subtleties here about the timing of associating a domain with a node(s) but the simple case, which we implement at the moment, is if you start a domain, start a node, associate the two together and then add contributions. The contributed components run on the node with which the local domain object is associated (more complex node/component selection algorithms can be imagined but we don't do this at present). Here are some suggestions based on the interfaces from the list of existing domain classes above, of the kind of things we need to be able to do; Domain Create/destroy the domain based on its URI Act of creating a domain object with a globally unique URI means that it becomes part of that domain and can scope comonent invocations in the context of that domain. There should be a default hot update location if we want to maintain that feature. Contribution management Add/remove contributions Resulting composites/components sit ready to be started Composite Management Start/stop composite Akin to adding a composite to the domain composite and activating it Not sure how we identify a composite to be activated - by composite name? Currently it's done with a reference to the composite object Do we need to expose separate activation operations? Component Management Start/stop component Add.Remove listener Not sure how the listener from the current interface is going to be used getComponentInfo There are some existng related component management interfaces here also LocateService public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName); service name - component name / service name public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName); We also need the domain to provide some systematic interfaces to support distributed operation, for example, ServiceDiscovery register/find service endpoint Node Create/destroy the node based on its URI Add/remove an association with a domain start/stop a nodes activity Currently we have an approach, with the EmbeddedSCADomain, where the class vends a series of management interfaces, contribution, model building etc. for performing actions on the domain. This is useful as it allows flexibility in how these management actions are implemented without changing all of the domain implementation. It would also be appropriate, in the future, to expose some of these interfaces as services to allow for remote management of the domain at a node. Would welcome thoughts about this generally. Also specifically do we need to maintain the detailed interfaces provided with EmbeddedSCADomain alongside this. Regards Simon
Re: Is there value in keeping download links for old releases?
Thank you for your input. I'll work on making the current releases more visible and leave the old ones as is. On 8/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: The Eclipse STP project isn't using M2 because they accidentally downloaded the wrong release, its what was current at the time and they haven't migrated to a newer release yet. I think its good to keep old releases to (1) show the release history, and (2) have historical downloads available for people working on back level systems. No problem with rearranging the website if it makes the current release more obvious but i don't think old ones should just be deleted or hidden. ...ant +1 for keeping links to old releases, but rearranging the download web page to make more obvious that the current release is current and that old releases are old. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
ant elder wrote: On 8/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: I've not yet been able to find any good way to reliably work out the complete service URL in all environments. What i think maybe the best approach is to add a getBaseURI method to the Tuscany ServletHost interface so that can be used by bindings. So then it would be down to each ServletHost impl to set this correctly rather than the Axis2 binding to work it out. So for example for WebappServletHost it would be the webapp url like, http://localhost:8080/helloworld-ws-service-webapp, for the war distro http://localhost:8080/tuscany, for Geronimo http://localhost:8080 etc. Does something like this sound ok or does anyone have any better ideas? ...ant I'm not sure which scenario you have in mind for this, so here are the two use cases I can think of: (1) A binding was configured with a URI like localhost:8080 but will need to tell the world (in generated WSDL, in service endpoint references etc.) the actual endpoint address at which it can be reached, 192.168.1.1:8080 or myhost:8080 for example (2) A binding was configured with a URI, but we are not in a position to provide the service at that exact same URI, because we are running in a Webapp deployed at a different URI for example. I don't really like this use case as I think there's issues with this approach and that we should configure the Web container from the SCA metadata, not the other way around, but I guess we have to live with that for now :) Anyway, in that case as well we need to figure the effective URI of the particular service to put it in service endpoint references for example. For both scenarios, I'd suggest methods like this: ServletHost.getRequestURI(String mapping) - giving you the complete URI that people will have to send requests to or ServletHost.getServletPath(String mapping) - giving you the actual URI at which the particular servlet is available Both methods are modeled after the Servlet API interface, and will give you what you need (assuming I correctly guessed the scenarios you're after) in a simpler way than a getBaseURI() method which would still require the binding to combine that base URI with the rest of the URI that it knows about. There's also a 3rd case where the binding uses a default or relative uri which the runtime can honour and things like ?wsdl still need to be able to advertise the actual endpoint. Anyway from those three cases it seems like a way to get his from the ServletHost is valid thing to have. Yes From the perspective of whats the simplest way to code this for the ws binding as-is now i suspect a method that returns a complete url from a mapping may not be so easy to use with the current Axis2 code. Can you point me to piece of code that will use that URL and pass it to Axis2? This area has changed a lot with Axis2 1.3 though so it may depend on if we move up to Axis2 1.3. We'd also have to have all the code to work out the actual ip address or host name for use by the Jetty and Tomcat standalone ServletHosts. How about we just have a ServletHost getContextPath() modeled after the Servlet APIs getContextPath method? ...ant After reading this: http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServletRequest.html#getContextPath(), getContextPath() seems to return the path portion of the URI starting with /, this is different from the complete request URI. So if a complete URL from a mapping is not convenient to pass to Axis2 then I don't think that there's an equivalent in the Servlet APIs and it's probably best to go back to your initial idea of a getBaseURI() method :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1399) Generate SDO test classes using maven-sdo-plugin
[ https://issues.apache.org/jira/browse/TUSCANY-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1399. - Resolution: Fixed Added toolsTest project to the SDO reactor build and migrated appropriate tests from the tools project. Note that if you import the toolsTest Project into Eclipse is will require a maven build before the eclipse project builds correctly, as Eclipse doesn't know how to run the java generator. Generate SDO test classes using maven-sdo-plugin Key: TUSCANY-1399 URL: https://issues.apache.org/jira/browse/TUSCANY-1399 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Reporter: Ron Gavlin Priority: Minor Fix For: Java-SDO-Next Tuscany needs a better way to test the various options supported by the XSD2JavaGenerator. The first step is to code-generate test classes on the fly using the maven-sdo-plugin rather than managing code-generated classes directly within SVN. Then a significant number of the same tests could be run multiple times using different options passed to the maven-sdo-plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-961) DAS: Using deprected SDO method causes Type lookup failure
[ https://issues.apache.org/jira/browse/TUSCANY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-961. - Resolution: Fixed Latest patch applied. DAS: Using deprected SDO method causes Type lookup failure -- Key: TUSCANY-961 URL: https://issues.apache.org/jira/browse/TUSCANY-961 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Brent Daniel Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 961.patch, 961.patch The DAS is still using SDOUtil.createTypeHelper() rather than TypeHelper.INSTANCE. This causes the DAS to not have visibility of types defined by TypeHelper or XSDHelper. -- 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-1637) Rationalize the SCA Domain implementations
Rationalize the SCA Domain implementations -- Key: TUSCANY-1637 URL: https://issues.apache.org/jira/browse/TUSCANY-1637 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime, Java SCA Embedded Runtime Affects Versions: Java-SCA-0.99 Reporter: Simon Laws Fix For: Java-SCA-1.0 We now have a number of domain implementations in Tuscany Java SCA including - The SCADomain interface - DefaultSCADomain - EmbeddedSCADomain - HotUpdatableSCADomain - DistributedDomain/Node - distribution webapp? We should try to boil this down to the minimum number of APIs that are required. A thread on the ML has been started on this subject -- 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-1638) SDO command-line code generator behaves differently than standalone when invoked in Eclipse
SDO command-line code generator behaves differently than standalone when invoked in Eclipse --- Key: TUSCANY-1638 URL: https://issues.apache.org/jira/browse/TUSCANY-1638 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SCA-1.0 Environment: OS is Windows XP Professional SP2, and the SDO command line tool is invoked in side an Eclipse 3.3 plugin. Reporter: Sean Zhou Fix For: Java-SCA-1.0 I am trying to invoke the SDO command-line code generator inside eclipse which is causing it to behave differently than standalone. The following fix is suggested by Frank in Tuscany: 1) In class org.apache.tuscany.sdo.generate.adapter.SDOGenModelGeneratorAdapterFactory add another override method, createGenModelAdapter(), to return a new Tuscany subclass of GenModelGeneratorAdapter (e.g., SDOGenModelGeneratorAdapter). 2) In the new subclass, override the ensureProjectExists() method to do nothing. 3) Override anything else you need to ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing Composite and Component Properties
Hi Raymond, Thanks for responding. As far as I saw the stax-utils have only snapshots published. If this is indeed true then it seems like option 1 is better. But with option 1, is it good to bring in the databinding as a dependency into assembly-xml. To me assembly-xml seems to be at must lower layer to databinding. Please let me know your opinions about this. Thanks - Venkat On 8/30/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, There are a few ways you can handle this: 1) Use the code in the databinding module: Node2XMLStreamReader and then XMLStreamSerializer 2) Use a BSD-licensed StAXUtils at https://stax-utils.dev.java.net/nonav/javadoc/utils/index.html. // create a DOMSource Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(...); Source domSource = new DOMSource(doc); // create a StAXResult XMLStreamWriter writer = XMLOutputFactory.newInstance().createXMLStreamWriter(System.out); Result staxResult = new StAXResult(writer); // run the transform TransformerFactory.newInstance().newTransformer().transform(domSource, staxResult); Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 30, 2007 6:28 AM Subject: Writing Composite and Component Properties Hi, I am working on https://issues.apache.org/jira/browse/TUSCANY-1482 and its mostly done - just the only thing related writing the property values. The Property class has this value as a xml Document already and it would be good if we could simply write that out. Right now I don't see a way to do this from the XMLStreamWriter interface. I am trying to avoid having to parse this document value which is already an XML doc and then write it again as XML which seems a bit absurd. Would it be good to directly make use of the output stream that underlies the XMLStreamWriter ? If so how would the CompositeProcessor's write method avail this ? Are there other alternatives that people can help me with ? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationalizing SCA Domain implementations
On 8/30/07, Simon Laws [EMAIL PROTECTED] wrote: We now have a number of domain implementations in Tuscany Java SCA including - The SCADomain interface - DefaultSCADomain - EmbeddedSCADomain - HotUpdatableSCADomain - DistributedDomain/Node Covering a number of scenarios - running a domain in a single node - running a domain across multiple nodes - Adding, removing, updating the contributions of a domain through the API and automatically - Activating/deactivating, starting/stopping deployable composites through the API - Starting, stopping components through the API - Locating service in the domain through the API etc. There are some scenarios that we don't cover at the moment - running multiple domains in a VM What else? I would like to propose that we rationalize these various implementations down to a more manageable number. I have a simple model in my mind of the building blocks we have to deal with. 1/ The node. Is responsible for running segregated domains in a VM Associated with zero or more domains. 2/ The domain. Logically knows about all of the artifacts of a domain. Associated with one or more (in the distributed case) nodes. A local representation of the domain (the SCADomain object) provides the interface to wider domain There are some subtleties here about the timing of associating a domain with a node(s) but the simple case, which we implement at the moment, is if you start a domain, start a node, associate the two together and then add contributions. The contributed components run on the node with which the local domain object is associated (more complex node/component selection algorithms can be imagined but we don't do this at present). Here are some suggestions based on the interfaces from the list of existing domain classes above, of the kind of things we need to be able to do; Domain Create/destroy the domain based on its URI Act of creating a domain object with a globally unique URI means that it becomes part of that domain and can scope comonent invocations in the context of that domain. There should be a default hot update location if we want to maintain that feature. Contribution management Add/remove contributions Resulting composites/components sit ready to be started Composite Management Start/stop composite Akin to adding a composite to the domain composite and activating it Not sure how we identify a composite to be activated - by composite name? Currently it's done with a reference to the composite object Do we need to expose separate activation operations? Component Management Start/stop component Add.Remove listener Not sure how the listener from the current interface is going to be used getComponentInfo There are some existng related component management interfaces here also LocateService public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName); service name - component name / service name public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName); We also need the domain to provide some systematic interfaces to support distributed operation, for example, ServiceDiscovery register/find service endpoint Node Create/destroy the node based on its URI Add/remove an association with a domain start/stop a nodes activity Currently we have an approach, with the EmbeddedSCADomain, where the class vends a series of management interfaces, contribution, model building etc. for performing actions on the domain. This is useful as it allows flexibility in how these management actions are implemented without changing all of the domain implementation. It would also be appropriate, in the future, to expose some of these interfaces as services to allow for remote management of the domain at a node. Would welcome thoughts about this generally. Also specifically do we need to maintain the detailed interfaces provided with EmbeddedSCADomain alongside this. Just to add to this that the Geronimo integration [1] also does very similar stuff to the HotUpdatableSCADomain (which is used by the webapp distro), and that neither of those work properly anymore, see TUSCANY-1555. Actually i'm not sure that the EmbeddedSCADomain works properly now either as it seems to have fallen behind a bit of some of the changes. Would be great to sort this out and have more of a proper SPI to bootstrap a runtime, and i'd help it even if nothing else by getting the webapp distro to work with it to help validate the interfaces work. ...ant [1] https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/geronimo-tuscany/src/main/java/org/apache/geronimo/tuscany/EmbeddedRuntimeGBean.java
[jira] Commented: (TUSCANY-544) WSDL2Java should support WSDLs with schema imports
[ https://issues.apache.org/jira/browse/TUSCANY-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523924 ] Sean Zhou commented on TUSCANY-544: --- I encountered the same problem with schema imports. Please see the exception stack and the WSDL and imported schema below: D:\TuscanyWSDL2Java.bat -targetDirectory d:\temp\t d:\temp\EchoServ ice.wsdl java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:632) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.createPackageInfoTable(XSD2JavaGenerato r.java:320) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator .java:270) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2Java Generator.java:217) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.main(WSDL2JavaGenerator.ja va:172) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at com.ibm.ws.soa.sca.bootstrap.SCALauncher.main(SCALauncher.java:74) java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at com.ibm.ws.soa.sca.bootstrap.SCALauncher.main(SCALauncher.java:74) Caused by: java.lang.IllegalArgumentException: java.lang.NullPointerException at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2Java Generator.java:252) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.main(WSDL2JavaGenerator.ja va:172) ... 5 more Caused by: java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:632) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.createPackageInfoTable(XSD2JavaGenerato r.java:320) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator .java:270) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2Java Generator.java:217) ... 6 more - EchoService.wsdl - ?xml version=1.0 encoding=UTF-8? definitions xmlns=http://schemas.xmlsoap.org/wsdl/; xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:tns=http://test/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; name=EchoService targetNamespace=http://test/; types xsd:schema xsd:import namespace=http://test/; schemaLocation=EchoService_schema1.xsd/ /xsd:schema /types message name=echo part element=tns:echo name=parameters/ /message message name=echoResponse part element=tns:echoResponse name=parameters/ /message portType name=Echo operation name=echo input message=tns:echo/ output message=tns:echoResponse/ /operation /portType binding name=EchoPortBinding type=tns:Echo soap:binding style=document transport=http://schemas.xmlsoap.org/soap/http/ operation name=echo soap:operation soapAction=/ input soap:body use=literal/ /input output soap:body use=literal/ /output /operation /binding service name=EchoService port binding=tns:EchoPortBinding name=EchoPort soap:address location=http://localhost:9080/w1/EchoService/ /port /service /definitions --- EchoService_schema1.xsd --- ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:tns=http://test/; targetNamespace=http://test/; version=1.0 xs:element name=echo type=tns:echo/ xs:element name=echoResponse type=tns:echoResponse/ xs:complexType name=echo xs:sequence xs:element minOccurs=0 name=arg0 type=xs:string/ /xs:sequence /xs:complexType xs:complexType name=echoResponse xs:sequence xs:element minOccurs=0 name=return type=xs:string/ /xs:sequence /xs:complexType /xs:schema WSDL2Java should support WSDLs with schema imports -- Key: TUSCANY-544 URL: https://issues.apache.org/jira/browse/TUSCANY-544 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-M2 Reporter: Ron Gavlin Fix For: Java-SCA-Next Many WSDLs choose to import schemas rather than embedding types inline. The tuscany WSDL2JavaGenerator does not currently
Re: Writing Composite and Component Properties
Hi, I meant to re-use some of the code in databinding module instead of adding it as dependency to assembly-xml. BTW, writing a converter from DOM to XMLStreamWriter is probably not too complex. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 30, 2007 11:50 AM Subject: Re: Writing Composite and Component Properties Hi Raymond, Thanks for responding. As far as I saw the stax-utils have only snapshots published. If this is indeed true then it seems like option 1 is better. But with option 1, is it good to bring in the databinding as a dependency into assembly-xml. To me assembly-xml seems to be at must lower layer to databinding. Please let me know your opinions about this. Thanks - Venkat On 8/30/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, There are a few ways you can handle this: 1) Use the code in the databinding module: Node2XMLStreamReader and then XMLStreamSerializer 2) Use a BSD-licensed StAXUtils at https://stax-utils.dev.java.net/nonav/javadoc/utils/index.html. // create a DOMSource Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(...); Source domSource = new DOMSource(doc); // create a StAXResult XMLStreamWriter writer = XMLOutputFactory.newInstance().createXMLStreamWriter(System.out); Result staxResult = new StAXResult(writer); // run the transform TransformerFactory.newInstance().newTransformer().transform(domSource, staxResult); Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 30, 2007 6:28 AM Subject: Writing Composite and Component Properties Hi, I am working on https://issues.apache.org/jira/browse/TUSCANY-1482 and its mostly done - just the only thing related writing the property values. The Property class has this value as a xml Document already and it would be good if we could simply write that out. Right now I don't see a way to do this from the XMLStreamWriter interface. I am trying to avoid having to parse this document value which is already an XML doc and then write it again as XML which seems a bit absurd. Would it be good to directly make use of the output stream that underlies the XMLStreamWriter ? If so how would the CompositeProcessor's write method avail this ? Are there other alternatives that people can help me with ? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
On 8/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: I've not yet been able to find any good way to reliably work out the complete service URL in all environments. What i think maybe the best approach is to add a getBaseURI method to the Tuscany ServletHost interface so that can be used by bindings. So then it would be down to each ServletHost impl to set this correctly rather than the Axis2 binding to work it out. So for example for WebappServletHost it would be the webapp url like, http://localhost:8080/helloworld-ws-service-webapp, for the war distro http://localhost:8080/tuscany, for Geronimo http://localhost:8080 etc. Does something like this sound ok or does anyone have any better ideas? ...ant I'm not sure which scenario you have in mind for this, so here are the two use cases I can think of: (1) A binding was configured with a URI like localhost:8080 but will need to tell the world (in generated WSDL, in service endpoint references etc.) the actual endpoint address at which it can be reached, 192.168.1.1:8080 or myhost:8080 for example (2) A binding was configured with a URI, but we are not in a position to provide the service at that exact same URI, because we are running in a Webapp deployed at a different URI for example. I don't really like this use case as I think there's issues with this approach and that we should configure the Web container from the SCA metadata, not the other way around, but I guess we have to live with that for now :) Anyway, in that case as well we need to figure the effective URI of the particular service to put it in service endpoint references for example. For both scenarios, I'd suggest methods like this: ServletHost.getRequestURI(String mapping) - giving you the complete URI that people will have to send requests to or ServletHost.getServletPath(String mapping) - giving you the actual URI at which the particular servlet is available Both methods are modeled after the Servlet API interface, and will give you what you need (assuming I correctly guessed the scenarios you're after) in a simpler way than a getBaseURI() method which would still require the binding to combine that base URI with the rest of the URI that it knows about. There's also a 3rd case where the binding uses a default or relative uri which the runtime can honour and things like ?wsdl still need to be able to advertise the actual endpoint. Anyway from those three cases it seems like a way to get his from the ServletHost is valid thing to have. Yes From the perspective of whats the simplest way to code this for the ws binding as-is now i suspect a method that returns a complete url from a mapping may not be so easy to use with the current Axis2 code. Can you point me to piece of code that will use that URL and pass it to Axis2? Its spread about a bit but see o.a.t.s.binding.ws.axis2.TuscanyListingAgent.setContextRoot. Axis2 works out the host and port and constructs the url from that, the ConfigurationContext context root and service path plus the service name. ...ant
Multi-threading Testing
Hi all, Can anyone share his/her experience on how multi-threading testing was conducted in the Apache open source projects? At first, I thought I can use GroboUtils but found out it's not in the people.apache.org/repo. Before going too far to make a request to add GroboUtils to the remote Maven repository, I thought I'd better ask people here. Thanks for your input. Fuhwei
JDKLogger calls, was: Monitoring, logging and exceptions (again)
Raymond Feng wrote: I just created https://issues.apache.org/jira/browse/TUSCANY-1635 to track the aspectj-based tracing. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 29, 2007 11:06 AM Subject: Re: Monitoring, logging and exceptions (again) Simon Laws wrote: On 8/20/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/20/07, Simon Nash [EMAIL PROTECTED] wrote: See inline. Simon Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 17, 2007 9:27 AM Subject: Re: Monitoring, logging and exceptions (again) [snip] ant elder wrote: And also my 2p inline... ...ant On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: A number of different requirements have been discussed and solutions proposed. My 2p (I'm using Raymond's definitions b.t.w) Tracing: Dump out input/output/exception for method calls for the purpose of debugging/troubleshooting. (Target for developers/technical support) I feel that tracing of execution paths through the Tuscany codebase would be useful but agree that it's a lot of work and will be difficult to maintain and keep consistent if we did it manually. I'm happy that this is the responsibility of whoever wants to trace through the code and not a core part of the codebase. For the Tuscany developer community AspectJ have been proposed a couple of times and support has been prototyped. We could choose SLF4J as the interface through which messages are output. I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a facade for logging APIs, so you can code to the SLF4J API and then plug in whatever logging impl you like, but if the only logging calls we have are confined to a single tracing aspect we might as well just code that aspect to a specific logging API like JDK logging. That avoids the extra dependency on SLF4J and anyone can add additional aspects if they really want to use a different logger. The main other benefit of SLF4J is its parameterized message logging (avoids all the if(logger.isDebugEnabled()) ) but again if all the logging calls are in a single aspect thats not so useful. Makes sense to me. If we go the aspectj route for tracing method entry/exit, I agree that using the JDK logger directly is simpler. Since the aspect is on the side, we're flexible. JDK logger can be default and it can be replaced easily if the embedders or users choose to do so. A few more questions on this: What dependencies will aspectj add to our distribution? aspectjweaver is more than 1Mb, do we need it? I'll try to spend some time to explore both the compile-time and load-time weaving. What about mid-method logging of specific interesting events, for example the contents of requests as the enter and leave bindings and implementation types and things like that? That sort of logging is often all a lot of users want to see not the detail tracing of every method entry/exit. Could we add things like this in specific places? +1 for the ability to produce this level of information. This is my preferred approach for debugging or understanding how some part of the code works. Having every method entry and exit produce a trace line often creates a huge amount of output that obscures the essential details of what is happening. Can this mid-method logging be split in two categories? a) Debug tracing A simple solution is to split the method in two, and then leverage the entry/exit method tracing as discussed above. In many cases this would lead to a convoluted code structure with local variables needing to be passed as parameters between the two methods, or methods that contain a single line of code (if a trace line needs to be produced from within a loop). We can use JDK logger to add statements in the middle of a method. Then we can use an aspect to capture such calls to dump out the information. For example, if we have the following statement in a method: logger.debug(...); The apsect can trap it by a point cut like call * java.util.logger.Logger.debug(..). If the logger call is already there, why is an aspect needed to trap it? Why not just let it execute? b) End-user readable information (info that a binding is sending/receiving a message for example) This falls into the second category discussed in this thread, reporting significant events to a management console. The above suggestion should help too. The key here is to have some calls to indicate such requirements and they can be then trapped to provide the concrete logic. I think we're starting to see concrete solutions for (a) with aspectj. I have not seen any real concrete proposal for (b) yet. -- Jean-Sebastien
[jira] Commented: (TUSCANY-1462) Consistent use of Parameters in Config
[ https://issues.apache.org/jira/browse/TUSCANY-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523965 ] Luciano Resende commented on TUSCANY-1462: -- I tried to apply the patch, but I'm getting failures (NPE) on the following test cases : Tests in error: testCommandNamedParameters(org.apache.tuscany.das.rdb.test.NamedParameterTests) testProgrammaticCommandNamedParameters(org.apache.tuscany.das.rdb.test.NamedParameterTests) testNamedParameters(org.apache.tuscany.das.rdb.test.NamedParameterTests) It might have been due to some merges, but could you please take a quick look using the latest revision if you have these failures ? Thanks. Consistent use of Parameters in Config -- Key: TUSCANY-1462 URL: https://issues.apache.org/jira/browse/TUSCANY-1462 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1462.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19970.html Need to followup above mail thread and confirm required changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1630) On fly wsdl generation with axis2 1.3, coding suggestion draft
[
https://issues.apache.org/jira/browse/TUSCANY-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523985
]
gengshaoguang commented on TUSCANY-1630:
Sorry every,
I was wrong here, Tuscany's code is right, my mistake happend as:
StAX implementation has seval vendors, majority 2 of them are
BEA(stax-1.2.0.jar) and woodstox.codehaus.org (wstx-asl-3.2.1.jar).
I have been using the first one for a long time, but it would cause the error
in Tuscany. Now I changed it into the second one, things go right.
I'm sorry for making the above warning and those mails about on fly wsdl
generation.
On fly wsdl generation with axis2 1.3, coding suggestion draft
--
Key: TUSCANY-1630
URL: https://issues.apache.org/jira/browse/TUSCANY-1630
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-Next
Environment: jdk1.5 windows, eclipse, latest svn code
Reporter: gengshaoguang
Fix For: Java-SCA-Next
The axis2 binding depends on axis2 1.2, it works well for binding.ws when you
provide artificial wsdl and reference it with interface:wsdl
interface=[uri]/. Be careful the service name must be the same to the java
interface.
Then you could remove your wsdl and mark out the interface.wsdl/.
Then the Java2WSDLHelper is going to work, but failed with compilation, it
compiles only with axis2 1.3.
Refresh the classpath, then we should do the following correction to fit
axis2 1.3.
...binding.ws.axis2.Axis2ServiceServlet.
private ConfigurationContext conf_ctx;
public void init(ConfigurationContext configContext) {
conf_ctx = configContext; //keep this object locally instead of in the
super's (super now change this member by itself)
/*this.configContext = configContext;
try {
super.init(DUMMY_CONFIG);
} catch (ServletException e) {
throw new RuntimeException(e);
}*/
agent = new TuscanyListingAgent(configContext);
}
.
@Override
protected ConfigurationContext initConfigContext(ServletConfig config)
throws ServletException {
return conf_ctx; //return local instance instead of original:
instance in the super
}
Tomorrow I will make a mvn test case and attach the code here on.
--
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] Assigned: (TUSCANY-544) WSDL2Java should support WSDLs with schema imports
[ https://issues.apache.org/jira/browse/TUSCANY-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-544: --- Assignee: Luciano Resende WSDL2Java should support WSDLs with schema imports -- Key: TUSCANY-544 URL: https://issues.apache.org/jira/browse/TUSCANY-544 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-M2 Reporter: Ron Gavlin Assignee: Luciano Resende Fix For: Java-SCA-Next Many WSDLs choose to import schemas rather than embedding types inline. The tuscany WSDL2JavaGenerator does not currently support this type of usage. -- 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]
