Re: [PROPOSAL] Add "tuscany-" as the prefix for our artifact ids
I don't object in principle but think we should be careful - can you post a proposal so we can all see. -- Jeremy On Aug 31, 2006, at 11:30 PM, Raymond Feng wrote: Hi, Did we conclude that we will rename the artifact ids as I proposed? If there's no objections, I'll make the changes. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Friday, August 25, 2006 2:28 AM Subject: Re: [PROPOSAL] Add "tuscany-" as the prefix for our artifact ids +1 Rick also suggested this a while back, maybe we should raise a JIRA this time so its not forgotten. ...ant On 8/25/06, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Here is a list of JARs we're building: axis2-1.0-SNAPSHOT.jar spring-1.0-SNAPSHOT.jar celtix-1.0-SNAPSHOT.jar groovy-1.0-SNAPSHOT.jar rmi-1.0-SNAPSHOT.jar api-1.0-SNAPSHOT.jar core-1.0-SNAPSHOT.jar spi-1.0-SNAPSHOT.jar wsdl-1.0-SNAPSHOT.jar Don't we think the name of the jars are misleading? Can we tell these jars from tuscany project? The groupId makes them unique for the maven repository but it seems to be wierd when we copy these jars into some folders. I propose that we restore the naming convention we had in M1: add "tuscany-" as a prefix to the artifactId. Do you agree? Thanks, Raymond - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Add "tuscany-" as the prefix for our artifact ids
Hi, Did we conclude that we will rename the artifact ids as I proposed? If there's no objections, I'll make the changes. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Friday, August 25, 2006 2:28 AM Subject: Re: [PROPOSAL] Add "tuscany-" as the prefix for our artifact ids +1 Rick also suggested this a while back, maybe we should raise a JIRA this time so its not forgotten. ...ant On 8/25/06, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Here is a list of JARs we're building: axis2-1.0-SNAPSHOT.jar spring-1.0-SNAPSHOT.jar celtix-1.0-SNAPSHOT.jar groovy-1.0-SNAPSHOT.jar rmi-1.0-SNAPSHOT.jar api-1.0-SNAPSHOT.jar core-1.0-SNAPSHOT.jar spi-1.0-SNAPSHOT.jar wsdl-1.0-SNAPSHOT.jar Don't we think the name of the jars are misleading? Can we tell these jars from tuscany project? The groupId makes them unique for the maven repository but it seems to be wierd when we copy these jars into some folders. I propose that we restore the naming convention we had in M1: add "tuscany-" as a prefix to the artifactId. Do you agree? Thanks, Raymond - 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: [C++] Extension matters
On 8/31/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
Hi all,
I'm inches away from getting an extension working that allows Python
scripts
to be used as components in SCA C++. I should be putting that up some time
tomorrow - I'll start a thread about a few minor issues with the extension
framework that I've come across, but it hasn't been too complex to get
this
going.
At the moment the extension provides an implementation.python element to
the
.composite of the form:
This allows other C++ components or C++ clients to call the service
implemented by code inside the Python module. The service interface is
currently described by a C++ header file, and uses the
interface.cppinterface binding. Currently, references from the Python
components are not
enabled (see below).
There are two further areas that are needed for full integration of Python
into SCA (or SCA into Python):
1) A programming model for SCA in Python to allow Python components or
Python clients to call SCA services. This will enable components with
Python
implementations to have references.
We could either create a Python extension that will emulate the service
lookup that we do in C++, e.g. a Python equivalent of the following C++
snippet:
// First, get the current ComponentContext
osoa::sca::ComponentContext myContext =
osoa::sca::ComponentContext::getCurrent();
// Find the required service, as referenced in
CalculatorImpl.componentType
DivideService* divideService =
(DivideService*)myContext.getService("divideService");
// Finally, invoke the service
result = divideService->divide(arg1, arg2);
Alternatively, we could look at doing some kind of annotations within the
Python component module - I'm not sure whether Python has annotation
support
(I don't believe so), or whether there is a way to 'fake' it to make
comments/documentation act as annotations.
2) An interface.python extension so that python components do not have to
have their interfaces converted to a C++ or WSDL description. Due to the
loose typing that Python allows this isn't the easiest thing to do - most
functions have signatures like: def myMethod(arg1, arg2) - and (as far as
I
can currently tell) there is no way to determine the types of the
arguments
or return values aside from at invocation time.
At the moment the SCAGEN tool generates the C++ component proxy and
wrapper
classes based on the C++ header specified in the interface.cpp element in
the .componentType file. If the .componentType file has an
interface.pythonelement instead, and specifies the Python module,
generating the correct C++
code neccessary to call the python service is hard. Alternatively, the
interface.python could specify the function signatures itself, but that
starts to stray into WSDL territory, e.g:
There may well be a way to specify things a bit tighter in Python that i
don't know about - I'll keep looking into this.
What do people think about these various issues? Has anyone got any
suggestions?
Thanks!
Andy
Hi Andy
Sounds like great progress.
1) I would favour whatever hides SCA from the Python programmer the most so
I like annotations. However if annotations are hard then the first approach
would be a stake in the ground until you have a better feel for how the
extension framework operates.
2) PHP is loosly typed also but you can get at the comments in the source so
you can describe function signatures there and look at them at run time (see
http://www.osoa.org/display/Main/PHP+and+SCA+White+Paper). Can you do the
same in Python?
If you do use support in Python to get at types its likely to be a run time
operation so we would need to rely on the generic proxies/wrappers in C++
and then call up into Python doing the apporpriate transformation as
dictated by the runtime generated interface description. As this is likely
to be a runtime thing I would go with WSDL to describe the interface. You
then have the mechanism for describing the python script as a remote service
ready to go. It would be good to have a component in C++ that is able to
generate WSDL on the fly (this would be handy for PHP also) but we would
have to agree how to describe the interface to the WSDL generator!
Maybe you could say a little bit more about what you do now to help us
envisage the development process and flow of control.
- you write a python class/operation
- you write your .componentType file including implementation.python
- you hand craft a .h file to match the python class ?
- you run SCA gen to generate the wrapper
- you have some code that converts the wrapper call into a call into the
Python engine targetted at the appropriate operation
Is that correct?
Regards
Simon
Re: REST bindings for Tuscany SCA runtime
On 9/1/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Simon Laws wrote:
> On 8/31/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Oisin Hurley wrote:
>> >> I am not sure I understand the issue with create/delete (except if
>> >> PUT and DEL are disabled). Posting/putting to a URL that doesn't
>> >> exist yet to create that resource can be troubling. Is that the
>> >> issue? Are you looking for some kind of factory service pattern to
>> >> create resources?
>> >>
>> >> Or am I completely mis-understanding the issue you're describing
>> >> here? :)
>> >
>> > Apologies for not making the context clearer - however, you've got
the
>> > point: there needs to be either a resource factory, or a generic
>> > resource
>> > holder to process create/delete of resources. I think I was
attempting
>> > to say that a first cut would be ok to support just the GET/POST
>> (as the
>> > most pressing scenarios) and then the PUT/DEL and factory approach
>> could
>> > follow as a feature improvement.
>> >
>> > I will put up a wiki summary on this thread.
>> >
>> > cheers
>> > --oh
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>> Yes, GET/POST first, PUT/DELETE later sounds reasonable to me.
>>
>> I've been struggling myself with the question on whether or not we need
>> some kind of resource holder/factory to create resources, and I'm now
>> starting to think that it really depends on how you view your
resources.
>>
>> Just a wild thought here...
>>
>> If you view your resources as objects, you'll probably say that you
need
>> a factory to do customerFactory->create("http:///customer/1234";).
>> Then you'll say customers->get("http:///customer/1234";) to retrieve
>> your customer object.
>>
>> If on the other hand you view the Web as a giant distributed file
>> system, then it's not so shocking to say:
>> customers->createFile("http:///customer1234";);
>> customers->getFile("http://./customer1234";);
>>
>> Thoughts?
>>
>> --
>> Jean-Sebastien
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> Hi Sebastien
>
> It's not clear that there is a difference between customers and
> customerFactory in your example. You are saying that there is some
> resource
> that causes the correct interpretation of PUT type requrests
> w.r.tgenerating/recording new resources that represent customers. This
> resource
> itself may, for example, represent the list of customers it has
> created in
> response to GET type requests. The relationship between Customers and
> Customer is not a wired relationship in the SCA sense but a resource
> relationship as dictated by the URLs used to represent endpoints.
>
> Regards
>
> Simon
>
Simon,
I agree with what you're saying. I think that we've now closed a loop :)
and that what you're saying is in line with the proposal at the bottom
of http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06704.html
Then we raised the question of whether or not the create verb in
particular should be handled by a separate factory.
And in this last email I was trying to say that somebody coming with an
OO view would probably want that factory separate from the actual
resources (and that I was initially in that camp some time ago), but
that now I'm seeing these resources more like a file system (with no
separate factory) where:
customers.get("http://my.customer.database.com/customers/1234";); returns
an instance of the Customer XSD complex type for customer 1234
customers.put/post("http://my.customer.database.com/customers/1234";,
customerDataObject / or a diff) creates/updates customer 1234 with a
Customer instance.
customers.get("http://my.customer.database.com/customers/";) returns a
list of URIs to the customers.
Is that consistent with your view?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Yes, sorry, I wasn't very clear in my post. I'm not trying to go round the
loop again:-) Your summary is consistent with my view.
Assuming HTTP here I probably expect to get different results from
GET - http://my.customer.database.com/customers/ (get me all the
customer records?)
GET - http://my.customer.database.com/customers/1234 (get me one customer
record?)
I'm also probably asking for different things when I say
PUT - http://my.customer.database.com/customers/ (Create all the
customer records?)
PUT - http://my.customer.database.com/customers/1234 (Create one customer
record?)
In normal static HTTP land the semantics are the same in both cases as I'm
just GETing or PUTing data.
In our case what actually happens depends on both the verb and the
Re: build breaks (and how to fix them)
Can we also move the databinding extensions under services so we have: service/transports services/databinding services/ Jim On Aug 31, 2006, at 8:19 PM, Jeremy Boynes wrote: On Aug 30, 2006, at 10:32 PM, Jeremy Boynes wrote: To tackle 3), I will move the projects under a new subdirectory in sca called (for want of a better name as core is taken) "kernel". I have moved api, host-api, spi and core under a sub-directory called kernel. I have not changed the poms yet except to change the module path in sca/pom.xml - I will be moving these to a new groupId : org.apache.tuscany.sca.kernel -- Jeremy - 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: build breaks (and how to fix them)
On Aug 30, 2006, at 10:32 PM, Jeremy Boynes wrote: To tackle 3), I will move the projects under a new subdirectory in sca called (for want of a better name as core is taken) "kernel". I have moved api, host-api, spi and core under a sub-directory called kernel. I have not changed the poms yet except to change the module path in sca/pom.xml - I will be moving these to a new groupId : org.apache.tuscany.sca.kernel -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Simon Laws wrote:
On 8/31/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Oisin Hurley wrote:
>> I am not sure I understand the issue with create/delete (except if
>> PUT and DEL are disabled). Posting/putting to a URL that doesn't
>> exist yet to create that resource can be troubling. Is that the
>> issue? Are you looking for some kind of factory service pattern to
>> create resources?
>>
>> Or am I completely mis-understanding the issue you're describing
>> here? :)
>
> Apologies for not making the context clearer - however, you've got the
> point: there needs to be either a resource factory, or a generic
> resource
> holder to process create/delete of resources. I think I was attempting
> to say that a first cut would be ok to support just the GET/POST
(as the
> most pressing scenarios) and then the PUT/DEL and factory approach
could
> follow as a feature improvement.
>
> I will put up a wiki summary on this thread.
>
> cheers
> --oh
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Yes, GET/POST first, PUT/DELETE later sounds reasonable to me.
I've been struggling myself with the question on whether or not we need
some kind of resource holder/factory to create resources, and I'm now
starting to think that it really depends on how you view your resources.
Just a wild thought here...
If you view your resources as objects, you'll probably say that you need
a factory to do customerFactory->create("http:///customer/1234";).
Then you'll say customers->get("http:///customer/1234";) to retrieve
your customer object.
If on the other hand you view the Web as a giant distributed file
system, then it's not so shocking to say:
customers->createFile("http:///customer1234";);
customers->getFile("http://./customer1234";);
Thoughts?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sebastien
It's not clear that there is a difference between customers and
customerFactory in your example. You are saying that there is some
resource
that causes the correct interpretation of PUT type requrests
w.r.tgenerating/recording new resources that represent customers. This
resource
itself may, for example, represent the list of customers it has
created in
response to GET type requests. The relationship between Customers and
Customer is not a wired relationship in the SCA sense but a resource
relationship as dictated by the URLs used to represent endpoints.
Regards
Simon
Simon,
I agree with what you're saying. I think that we've now closed a loop :)
and that what you're saying is in line with the proposal at the bottom
of http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06704.html
Then we raised the question of whether or not the create verb in
particular should be handled by a separate factory.
And in this last email I was trying to say that somebody coming with an
OO view would probably want that factory separate from the actual
resources (and that I was initially in that camp some time ago), but
that now I'm seeing these resources more like a file system (with no
separate factory) where:
customers.get("http://my.customer.database.com/customers/1234";); returns
an instance of the Customer XSD complex type for customer 1234
customers.put/post("http://my.customer.database.com/customers/1234";,
customerDataObject / or a diff) creates/updates customer 1234 with a
Customer instance.
customers.get("http://my.customer.database.com/customers/";) returns a
list of URIs to the customers.
Is that consistent with your view?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: build breaks (and how to fix them)
On Aug 31, 2006, at 4:48 PM, Luciano Resende wrote: Hi Jeremy I'm trying to catch up on things, after couple days out... do I need to update anything on DAS or what you mentioned here is that because DAS has a SDO dependency, it will have to be built and published after that ? When I modified the artifactId I updated DAS as well so there's nothing to change there. I plan to publish snapshots of SDO later tonight and when that happens DAS should be able to pick them up (no need to build everything together). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build breaks (and how to fix them)
Hi Jeremy I'm trying to catch up on things, after couple days out... do I need to update anything on DAS or what you mentioned here is that because DAS has a SDO dependency, it will have to be built and published after that ? - Luciano On 8/30/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: I have updated the POMs for the spec projects and buildtools so that we are ready to publish snapshot builds for them. This will allow us to build and publish SCA and SDO as standalone projects. Once SDO is published, we should be able to build and publish DAS. To tackle 3), I will move the projects under a new subdirectory in sca called (for want of a better name as core is taken) "kernel". -- Jeremy On Aug 29, 2006, at 5:24 PM, Jeremy Boynes wrote: > Sounds good to me. I will start to publish unstable builds to the > apache snapshot repo to help stabilize things. > -- > Jeremy > > On Aug 25, 2006, at 5:20 PM, Jim Marino wrote: > >> Many of us have experienced build breaks over the past several >> weeks, particularly in the Java SCA project. I believe the root of >> the problem to be not having the correct level of modularity. I >> would like to start with a general approach on how to fix this and >> once we gain consensus, move to creating a proposal for changing >> the current build structure. >> >> 1. The source tree should be independently built from individual >> projects under /java, sca, sdo, and das. Currently it is not since >> buildtools is required. I would like to get to the point where >> people can check out individual sub projects only and build from >> there. >> >> 2. For SCA Java, as Ant proposed, the samples dealing with >> extensions would move to their appropriate extension projects. >> Samples that used multiple extensions (e.g. BigBank with Celtix >> and Axis) would stay under samples/sca >> >> 3. API, SPI, core, hostutil, host-api would be built independently >> under a subdirectory of /sca >> >> 4. Runtime host projects would be build independently under a >> subdirectory of /sca >> >> 5. Extensions would move into into a subdirectory of /sca (they >> could still be organized according to type) and be built >> individually against a particular version of the core "jars". This >> would mean that extensions are not built together and are not >> built with the core. This would shield the entire build process >> from breaking when an extension breaks (e.g. Axis and Axiom not >> being in sync). It would also mean changes to the core could be >> vetted and not impact work being done on extensions. >> >> Thoughts? >> >> Jim >> >> >> >> - >> 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: Auto-config for collision column
Hi Kevin This sounds like a good aproach for one of the ways to support OCC in DAS. Should we also have this aproach documented in our Wiki as a reference ? - Luciano On 8/30/06, Kevin Williams <[EMAIL PROTECTED]> wrote: Currently, in the absence of otherwise conflicting, explicit configuration, we assume that any DO property named "id" will map to a primary key column in the database. Likewise a property name of the form "x_id" maps to a foreign key column that references some row in table "x". I would like to add another "auto configuration" convention for the RDB DAS for "collision" properties. So, any DO property with the name "occ_count" will be assumed to map to an integer table column that is used for optimistic concurrency control. This column will then be used to overqualify any related UPDATE statements for that table. In the future, we may want to add support for "occ_timestamp", etc. Any comments? Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Luciano Resende SOA Opensource - Apache Tuscany -
[jira] Created: (TUSCANY-686) InterfaceWSDLLoader creates WSDLServiceContract objs which return null on getInterfaceClass()
InterfaceWSDLLoader creates WSDLServiceContract objs which return null on getInterfaceClass() - Key: TUSCANY-686 URL: http://issues.apache.org/jira/browse/TUSCANY-686 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: r438923 Reporter: Scott Kurz SYMPTOM (when using elem along with and Axis 2 binding: java.lang.NullPointerException at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:314) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:110) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:91) at org.apache.tuscany.core.deployer.DeployerImpl.connect(DeployerImpl.java:141) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:103) at org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(LauncherImpl.java:193) PROBLEM: Axis2BindingBuilder.build does (line 60): Class interfaze = serviceDefinition.getServiceContract().getInterfaceClass(); This simply returns null since the WSDLServiceContract built by InterfaceWSDLLoader contains a portType but no interface class.Thus the ConnectorImpl hits the NPE we see above. Some sort of WSDL2Java should probably? be done when InterfaceWSDLLoader sets the portType on the WSDLServiceContract it builds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Extension matters
Hi all,
I'm inches away from getting an extension working that allows Python scripts
to be used as components in SCA C++. I should be putting that up some time
tomorrow - I'll start a thread about a few minor issues with the extension
framework that I've come across, but it hasn't been too complex to get this
going.
At the moment the extension provides an implementation.python element to the
.composite of the form:
This allows other C++ components or C++ clients to call the service
implemented by code inside the Python module. The service interface is
currently described by a C++ header file, and uses the
interface.cppinterface binding. Currently, references from the Python
components are not
enabled (see below).
There are two further areas that are needed for full integration of Python
into SCA (or SCA into Python):
1) A programming model for SCA in Python to allow Python components or
Python clients to call SCA services. This will enable components with Python
implementations to have references.
We could either create a Python extension that will emulate the service
lookup that we do in C++, e.g. a Python equivalent of the following C++
snippet:
// First, get the current ComponentContext
osoa::sca::ComponentContext myContext =
osoa::sca::ComponentContext::getCurrent();
// Find the required service, as referenced in
CalculatorImpl.componentType
DivideService* divideService =
(DivideService*)myContext.getService("divideService");
// Finally, invoke the service
result = divideService->divide(arg1, arg2);
Alternatively, we could look at doing some kind of annotations within the
Python component module - I'm not sure whether Python has annotation support
(I don't believe so), or whether there is a way to 'fake' it to make
comments/documentation act as annotations.
2) An interface.python extension so that python components do not have to
have their interfaces converted to a C++ or WSDL description. Due to the
loose typing that Python allows this isn't the easiest thing to do - most
functions have signatures like: def myMethod(arg1, arg2) - and (as far as I
can currently tell) there is no way to determine the types of the arguments
or return values aside from at invocation time.
At the moment the SCAGEN tool generates the C++ component proxy and wrapper
classes based on the C++ header specified in the interface.cpp element in
the .componentType file. If the .componentType file has an
interface.pythonelement instead, and specifies the Python module,
generating the correct C++
code neccessary to call the python service is hard. Alternatively, the
interface.python could specify the function signatures itself, but that
starts to stray into WSDL territory, e.g:
There may well be a way to specify things a bit tighter in Python that i
don't know about - I'll keep looking into this.
What do people think about these various issues? Has anyone got any
suggestions?
Thanks!
Andy
[jira] Created: (TUSCANY-685) hexBinary XSD type is wrongly treated as base64Binary type by current SDO impl
hexBinary XSD type is wrongly treated as base64Binary type by current SDO impl -- Key: TUSCANY-685 URL: http://issues.apache.org/jira/browse/TUSCANY-685 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Fuhwei Lwo If one defined an element with hexBinary type in the XSD and used SDO to set its value and serialize to an XML document, the value will be in base64Binary format instead of hexBinary. If one read the XML doc directly and tried to decode the value using hexBinary algorithm, a problem would occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Undeployment and App Removal
I have been working on implementing the ability to unregister and undeploy SCA composites from Tuscany Java. After talking to Jim and Jeremy, I wanted to start a discussion of design and implementation issues and possibly get limited functionality working. It seems to me that the first thing we should approach is implementing the removal of a deployable unit from the runtime. The following issues/conclusions seem like starting points: -It seems as if we can narrow deployable units to instances of CompositeComponent. -register() and deploy() methods build the composite and adding the app to the runtime's list. To go about removing, should we create corresponding unregister() and undeploy() methods and literally undo the adding process? -Should the stop() method (inherited from LifeCycle) be called on the application before it is removed from the runtime or can it be called after it is removed? -What should be used to identify a particular application to be removed? For now, it seems as if the application name that it is registered under should be sufficient as the only parameter needed to identify the application. Kapish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException
Hi Raymond/Frank
I saw that you create TUSCANY-684. Could you describe the extent of this
issue? Is this a major or minor issue? I understand that there's a bunch
of development work going on right now, but do you have a feel for the time
to resolution? If possible, we'd like to demo Tuscany a couple times next
month.
Re commonj.sdo.DataObject: Yes, this works. Does SDO or the factory methods
gen'd by the plugin have a utility/method to transfrom the DataObject into a
Patient object? I'll look around.
Also, we have a small test case to replicate the issue:
http://firestruck.com/temp/complexhelloworldws.zip (web service, deploy to
web container)
http://firestruck.com/temp/complexhelloworldwsclient.zip (Tuscany client)
Let us know where/how we can help.
-Chris
On 8/31/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
I think we probably have a problem with the proper scoping for the SDO
types
(especially static types which are registered by classloaders today). I'll
start a new thread to involve the folks on the SDO side.
Meanwhile, can you try to use "commonj.sdo.DataObject" for your business
interface to see if it helps?
Thanks,
Raymond
- Original Message -
From: "Chris Wall" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, August 30, 2006 5:27 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call
produces
TargetException leads to ClassCastException
> Hi Raymond. Thanks for your patience.
>
> With the factory declaraion I'm getting the same thing...
>
> org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
> http://www.bea.com/medrec}getString' not found in registered SDO types.
>at org.apache.tuscany.binding.celtix.io.NodeDataWriter.toXMLDocument(
> NodeDataWriter.java:142)
>at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper(
> NodeDataWriter.java:84)
>at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper(
> NodeDataWriter.java:47)
>at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.addParts(
> SOAPBindingImpl.java:567)
>at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.marshal(
> SOAPBindingImpl.java:119)
>at org.objectweb.celtix.bindings.Request.process(Request.java:91)
>
>
> org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
> http://www.bea.com/medrec}getPatient' not found in registered SDO types.
>
> Updated scdl:
>
> E:/sca/tuscany/java/samples/sca/medrec 190$ cat
> target/classes/META-INF/sca/default.scdl
>
> http://www.osoa.org/xmlns/sca/1.0";
>
> xmlns:system="http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT
> "
> name="tuscanyWS2WLS">
>
>
>
>
>
>
>
>
> name="medRecWebServicesService">MedRecWebServicesService
>
>
>
>
>
>http://www.bea.com/medrec#wsdl.endpoint(MedRecWebServices/MedRecWebServicesPort)
> "
>location="wsdl/MedRecWebServices.wsdl" />
>
>
>
>
>
> On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi, Chris.
>>
>> You probably need to use the following "import.sdo":
>>
>>
>>
>> Thanks,
>> Raymond
>>
>> - Original Message -
>> From: "Chris Wall" <[EMAIL PROTECTED]>
>> To:
>> Sent: Wednesday, August 30, 2006 4:24 PM
>> Subject: Re: Returning DynamicDataObjectImpl from web service call
>> produces
>> TargetException leads to ClassCastException
>>
>>
>> > Hey. Comments inline...
>> >
>> >
>> > On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi, Chris.
>> >>
>> >> If you have , it
>> >> means
>> >> that you prefer to use the dynamic SDO model derived from the
>> >> WSDL/XSD.
>> I
>> >> have two questions:
>> >
>> >
>> > CW: Ahh, I did not know. Yet, if I remove the import the following
>> line
>> > throws an exception:
>> >
>> > [NodeDataWriter}
>> > Property property = xsdHelper.getGlobalProperty(
>> >elementQName.getNamespaceURI(), elementQName.getLocalPart
(),
>> > true);
>> >
>> > org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
>> > http://www.bea.com/medrec}getString' not found in registered SDO
types.
>> >
>> > With import.sdo, this web service call returns successfully.
>> >
>> > 1) Is the exception from client side or server side?
>> >
>> >
>> > CW: Client. Occurs within Proxy.getPatient(...).
>> >
>> > 2) What's our business interface expecting? The strongly-typed java
>> >> class/interface generated by SDO or the dynamic DataObject?
>> >
>> >
>> > CW: Strongly-typed:
>> >
>> > com.bea.proto.webservice.Patient
>> > getPatient(com.bea.proto.webservice.PatientpPatient) throws
Exception;
>> >
>> >
>> > Basically, the "import.sdo" needs to be consistent with your business
>> >> interface signature.
>> >>
>> >> Thanks,
>> >> Raymond
>> >>
>> >> - Original Message -
>> >> From: Chris Wall
>> >> To: Raymond Feng
>> >> Sent: Wednesday, August 30, 2006 4:05 PM
>> >> Subject: Re: Returning DynamicDataObjectImpl from web service call
>> >> produces
>> >> TargetException leads to ClassCastException
>> >>
>> >>
>> >> Hey Raymond.
>>
Re: Building all of Tuscany
I added the pom into the build so an offline build should work as well. -- Jeremy On Aug 31, 2006, at 12:41 PM, Rick wrote: Actually building from the top still works... you just need to do online build :-) Rick wrote: Now that we have disjoint projects with respect to build, for those of us that want to build all of Tusany is there a means for that with a single command? If not, any thoughts on how or if there should be? Scripts? A maven project under pom? Profiles? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building all of Tuscany
Actually building from the top still works... you just need to do online build :-) Rick wrote: Now that we have disjoint projects with respect to build, for those of us that want to build all of Tusany is there a means for that with a single command? If not, any thoughts on how or if there should be? Scripts? A maven project under pom? Profiles? - 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: [C++] VC7 SCA project
I think you might have seen the changes that Sebastien has recently put in - I've only just put up the interface changes. Andy On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: Actually, I just checked your changes and I note that you haven't come across the problem with parameters called "interface", probably not good practice. At least you haven't checked any changes in. I'll make a patch and I'll try and make a patch for the VC project also. Regards Simon On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > ta > > > On 8/31/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > > > > On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > On 8/31/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > > > > > > > > Nope - I've been using the VC6 one - just start it up and VC7 gives > > you > > > > the > > > > option of converting the project and creating the.sln file, etc > > > > > > > > Andy > > > > > > > > On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Does anyone have a version of the VC7 project for SCA that matches > > the > > > > > reorganized code? If not I'll make one > > > > > > > > > > Regards > > > > > > > > > > Simon > > > > > > > > > > > > > > > > > > > > > > OK, so I did that but I had to make a few fixes. In particlar I get > > > > > > http://msdn2.microsoft.com/en-us/library/t72ahzw1.aspx > > > > > > For > > > Service.h > > > Interface.h > > > Binding.h > > > ServiceBinding.h > > > ReferenceBinding.h > > > > > > The code also uses the word "interface" as a parameter name which > > causes > > > havoc with my version of VC7. Have fixed it in > > > > > > CompositeService.h /.cpp > > > CompositeReference.h/.cpp > > > ServiceType.h/.cpp > > > Contract.h/.cpp > > > ReferenceType.h/.cpp > > > > > > Of course I would normally go ahead and raise a JIRA but I find it > > hard to > > > believe that these haven't already been fixed somehow. Am I doing > > > something > > > wrong? > > > > > > Nope - I saw these & fixed them in my code but I forgot to commit them. > > I'll do that now. > > > > Happy to raise a JIRA and attach a patch. > > > > > > If you have a patch for the VC7 project files I'll happily apply that > > for > > you. > > > > Cheers > > Andy > > > > >
Building all of Tuscany
Now that we have disjoint projects with respect to build, for those of us that want to build all of Tusany is there a means for that with a single command? If not, any thoughts on how or if there should be? Scripts? A maven project under pom? Profiles? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] VC7 SCA project
Actually, I just checked your changes and I note that you haven't come across the problem with parameters called "interface", probably not good practice. At least you haven't checked any changes in. I'll make a patch and I'll try and make a patch for the VC project also. Regards Simon On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: ta On 8/31/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > > On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > On 8/31/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > > > > > > Nope - I've been using the VC6 one - just start it up and VC7 gives > you > > > the > > > option of converting the project and creating the.sln file, etc > > > > > > Andy > > > > > > On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > > Does anyone have a version of the VC7 project for SCA that matches > the > > > > reorganized code? If not I'll make one > > > > > > > > Regards > > > > > > > > Simon > > > > > > > > > > > > > > > > OK, so I did that but I had to make a few fixes. In particlar I get > > > > http://msdn2.microsoft.com/en-us/library/t72ahzw1.aspx > > > > For > > Service.h > > Interface.h > > Binding.h > > ServiceBinding.h > > ReferenceBinding.h > > > > The code also uses the word "interface" as a parameter name which > causes > > havoc with my version of VC7. Have fixed it in > > > > CompositeService.h /.cpp > > CompositeReference.h/.cpp > > ServiceType.h/.cpp > > Contract.h/.cpp > > ReferenceType.h/.cpp > > > > Of course I would normally go ahead and raise a JIRA but I find it > hard to > > believe that these haven't already been fixed somehow. Am I doing > > something > > wrong? > > > Nope - I saw these & fixed them in my code but I forgot to commit them. > I'll do that now. > > Happy to raise a JIRA and attach a patch. > > > If you have a patch for the VC7 project files I'll happily apply that > for > you. > > Cheers > Andy > >
Re: [C++] VC7 SCA project
ta On 8/31/06, Andrew Borley <[EMAIL PROTECTED]> wrote: On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > On 8/31/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > > > > Nope - I've been using the VC6 one - just start it up and VC7 gives you > > the > > option of converting the project and creating the.sln file, etc > > > > Andy > > > > On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > Does anyone have a version of the VC7 project for SCA that matches the > > > reorganized code? If not I'll make one > > > > > > Regards > > > > > > Simon > > > > > > > > > > OK, so I did that but I had to make a few fixes. In particlar I get > > http://msdn2.microsoft.com/en-us/library/t72ahzw1.aspx > > For > Service.h > Interface.h > Binding.h > ServiceBinding.h > ReferenceBinding.h > > The code also uses the word "interface" as a parameter name which causes > havoc with my version of VC7. Have fixed it in > > CompositeService.h/.cpp > CompositeReference.h/.cpp > ServiceType.h/.cpp > Contract.h/.cpp > ReferenceType.h/.cpp > > Of course I would normally go ahead and raise a JIRA but I find it hard to > believe that these haven't already been fixed somehow. Am I doing > something > wrong? Nope - I saw these & fixed them in my code but I forgot to commit them. I'll do that now. Happy to raise a JIRA and attach a patch. If you have a patch for the VC7 project files I'll happily apply that for you. Cheers Andy
Re: [C++] VC7 SCA project
On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: On 8/31/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > > Nope - I've been using the VC6 one - just start it up and VC7 gives you > the > option of converting the project and creating the.sln file, etc > > Andy > > On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > Does anyone have a version of the VC7 project for SCA that matches the > > reorganized code? If not I'll make one > > > > Regards > > > > Simon > > > > OK, so I did that but I had to make a few fixes. In particlar I get http://msdn2.microsoft.com/en-us/library/t72ahzw1.aspx For Service.h Interface.h Binding.h ServiceBinding.h ReferenceBinding.h The code also uses the word "interface" as a parameter name which causes havoc with my version of VC7. Have fixed it in CompositeService.h/.cpp CompositeReference.h/.cpp ServiceType.h/.cpp Contract.h/.cpp ReferenceType.h/.cpp Of course I would normally go ahead and raise a JIRA but I find it hard to believe that these haven't already been fixed somehow. Am I doing something wrong? Nope - I saw these & fixed them in my code but I forgot to commit them. I'll do that now. Happy to raise a JIRA and attach a patch. If you have a patch for the VC7 project files I'll happily apply that for you. Cheers Andy
Re: Async callbacks over ws binding w/Axis2, was Re: Inner composite patch
On Aug 31, 2006, at 10:47 AM, Ignacio Silva-Lepe wrote: Sure, np. The basic idea is to use (1) the wiring and connection infrastructure that is there (or shortly to be there once the patch is applied) for composite references and services, and (2) the non- blocking execute with callback facilities of Axis2's operation client. I'm reviewing the patch now...It would also be interesting to get some of the Celtix (Jervis, Dan?) people to comment on how this could be done with that binding as well. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Async callbacks over ws binding w/Axis2, was Re: Inner composite patch
Sure, np. The basic idea is to use (1) the wiring and connection infrastructure that is there (or shortly to be there once the patch is applied) for composite references and services, and (2) the non-blocking execute with callback facilities of Axis2's operation client. Axis2Reference would need to be modified to use a variation of Axis2TargetInvoker that calls operationClient.execute(false) and that sets up a callback target invoker as the callback registered with operationClient. This could work as a subclass of Axis2TargetInvoker, probably in a similar way as AsyncJavaTargetInvoker is a subclass of PojoTargetInvoker (minus the new thread creation bit, that becomes unnecessary). Axis2Service is a bit trickier, mainly because the Axis2 api is not quite there for our needs. At first glance, it would seem like we could create an Axis2ServiceInOutAsyncMessageReceiver that extends Axis2's AbstractInOutAsyncMessageReceiver. But this latter class assumes that the business logic returns the result synchronously, i.e., when its call to invokeBusinessLogic is done it assumes that the result has been left in newmsgCtxt, and then it turns around and invokes the callback with the result or fault. We need to be able to separate this function so that the async invocation of the target component does happen in an independent Axis2ServiceInOutAsyncMessageReceiver, but the callback invocation happens in an Axis2ServiceCallbackTargetInvoker that is created by Axis2Service and that is set on the Axis2Service's outbound wire by the connector. A key item is the in-message context provided to Axis2ServiceInOutAsyncMessageReceiver's receive and that is needed in Axis2ServiceCallbackTargetInvoker to create the out-message context. We may end up using a workContext techinque similar to that used by AsyncJavaTargetInvoker in the local case. It may be possible to factor out the databinding function that is common with Axis2ServiceInOutSyncMessageReceiver. Needless to say, this is a first pass at putting this together, so comments are welcome. - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Thursday, August 31, 2006 9:58 AM Subject: Re: Inner composite patch, was Re: Optiional Autowire On 8/31/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote: I am getting a good picture of what needs to be done for async callbacks over ws binding w/axis2 and I can keep looking at this in my current sandbox until you are done, so it's not like I am stuck. Could you post an email about what and how you're looking at doing async and Axis2? There's a few of us who've worked on this binding in the past who'd be interested, I didn't even know you were looking at this until it was mentioned on IRC yesterday (unless I missed some previous email). ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-682) NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple threads
[ http://issues.apache.org/jira/browse/TUSCANY-682?page=all ] Frank Budinsky resolved TUSCANY-682. Resolution: Fixed Fixed in revision 438988. > NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple > threads > -- > > Key: TUSCANY-682 > URL: http://issues.apache.org/jira/browse/TUSCANY-682 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M1 > Environment: Win2K, multi-threaded load test >Reporter: Ron Gavlin >Priority: Critical > > I receive the following NPE when using Tuscany SDO in a multi-threaded > environment. Here is the stack trace: > java.lang.NullPointerException > at org.apache.tuscany.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) > at > org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2342) > at > org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:1284) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2032) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2139) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838) > at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:739) > at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:213) > ... > I suspect the NPE is due to synchronization problems with the > ClassImpl.propertyNameToPropertyMap. This problem occurs during load testing > of our application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-682) NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple threads
[ http://issues.apache.org/jira/browse/TUSCANY-682?page=comments#action_12431927 ] Ron Gavlin commented on TUSCANY-682: Hi Frank, My apologies. I didn't notice the comment you had added on line 194. Once I commented that line, the problem disappeared. Thanks for the excellent support. Regards, - Ron > NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple > threads > -- > > Key: TUSCANY-682 > URL: http://issues.apache.org/jira/browse/TUSCANY-682 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M1 > Environment: Win2K, multi-threaded load test >Reporter: Ron Gavlin >Priority: Critical > > I receive the following NPE when using Tuscany SDO in a multi-threaded > environment. Here is the stack trace: > java.lang.NullPointerException > at org.apache.tuscany.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) > at > org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2342) > at > org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:1284) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2032) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2139) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838) > at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:739) > at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:213) > ... > I suspect the NPE is due to synchronization problems with the > ClassImpl.propertyNameToPropertyMap. This problem occurs during load testing > of our application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r438785: move to ServiceContract/Operation
Hi Jim, Please see my further queries below and let me know if my thinking is right. On 8/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: I'd prefer ASM (CGLIB is built using it) since it is smaller, easier to use (CGLIB documentation is awful) and will probably give us more flexibility. Venkat : Ok.. will use ASM. What we need to do is provide an implementation of WireService that uses an approach which dispatches method invocations directly to the correct invocation chain. The JDK wire service currently creates invocation handlers that resolve the chain to invoke based on the method passed in from the proxy. We should be able to generate proxy code that does a "static" invoke to the correct chain without the overhead of a map lookup (see the JDK-based implementations of invocation handler). I follow this. So here is what I understand as, to be done: - for the logic in 'createProxy' method of the JDKWireService generate a class using ASM that implements the wire's interface - let us call this 'generatedProxy' - depending on the number of methods, create as many fields in this generatedProxy to hold instances of the InvocationChain - implement the body of each method in this 'generatedProxy' to execute all of the logic in JDKOutboundInvocationHandler (or other inbound hanlder as the case may be) using the appropriate field that holds its corresponding 'InvocationChain' instance. Having generated the bytecode for this 'generatedProxy' create an instance of it and return that as return value for the 'createProxy' method. Is this right? In addition, we should be able to create optimized variants of WireInvocationHandler. We particularly need to optimize JDKCallbackInvocationHandler and the JDKOutboundInvocationHandler constructor. As a note, I still need to switch over WireInvocationHandler.invoke (Method method, Object[] args) to take an Operation instead of a method. Geronimo I believe uses something similar so perhaps Jeremy could describe it further? I've also seen this done in Aspectwerkz with extremely fast performance. Jim As an when I get info on this I shall make the relevant changes. Is that ok ? Thanks - Venkat On Aug 31, 2006, at 12:04 AM, Venkata Krishnan wrote: > Hi Jim, > I worked a bit with cglib to generate manipulated intefaces as > apart of > the RMI-Binding and JavaScript e4x stuff. If this is good for a > start, then > please let me know what is to be done in JDKWireService. Thanks > > - Venkat > > On 8/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >> I have committed the changes to use ServiceContract/Operation in >> place of Java Interface/Method. This entailed modifications in SPI, >> particularly the signatures for classes in the wire package (e.g. >> RuntimeWire, InvocationChain), WireService, and Component >> (createTargetInvoker). >> >> ServiceContracts are created by an introspection registry for a given >> IDL. These registries may use the same pattern as registries for >> loaders and builders. For example, Java IDL has a >> JavaInterfaceProcessorRegistryImpl that delegates to >> JavaInterfaceProcessor implementations to populate a ServiceContract >> reflected from a Java interface. JavaInterfaceProcessor >> implementations may be system services which register with a >> JavaInterfaceProcessorRegistry, thereby adding support for metadata >> extensions (such as information specific to a databinding type). >> >> ServiceContract metadata is used to decorate wires. RuntimeWire has >> a new method getServiceContract() which will return the service >> contract associated with an inbound or outbound wire. Similarly, >> Invocation chains are decorated with an Operation. This metadata will >> be used by a new system service responsible for "optimizing/ >> mediating" wires as they are connected by the wiring infrastructure. >> This system service will be another registry with a set of builders. >> It will be different than the policy builder registry since policy >> builders only operate on one side of a wire (source or target). >> Raymond's databinding framework will use these facilities to >> introspect the outbound and inbounds parts of a wire and add >> appropriate interceptors. >> >> Currently, Operation and ServiceContract do not have facilities for >> runtime extensibility metadata; I will be adding these along with the >> new type of "optimizing/mediating" registry (probably) tomorrow. >> >> One outstanding work item is to provide a performant replacement for >> JDK proxies (JDKWireService). I suspect we will see significant >> performance penalties for local invocations, particularly callbacks, >> as several map lookups are done. If anyone is interested in creating >> an implementation of WireService based on a bytecode generation >> library such as ASM, please let me know and I will try and provide >> pointers. >> >> Jim >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED
[jira] Closed: (TUSCANY-301) @Service{interfaces={interface1, interface2}} does not work
[ http://issues.apache.org/jira/browse/TUSCANY-301?page=all ]
Jim Marino closed TUSCANY-301.
--
Resolution: Fixed
> @Service{interfaces={interface1, interface2}} does not work
> ---
>
> Key: TUSCANY-301
> URL: http://issues.apache.org/jira/browse/TUSCANY-301
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core
>Affects Versions: Java-Mx
>Reporter: Jean-Sebastien Delfino
> Assigned To: Jim Marino
> Fix For: Java-Mx
>
> Attachments:
> org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentTestCase.txt,
> testcase.zip
>
>
> @Service should allow you to specify multiple interfaces. This is supported
> by org.osoa.sca.Service but if you specify more than one interface on a
> service the runtime throws an exception.
> To reproduce the problem add the following to a component:
> @Service(interfaces={GreetingPortionProvider.class,
> GreetingPortionProvider2.class})
> Then wire two references using each of these two interfaces to the component.
> You will get the following exception:
> org.apache.tuscany.core.builder.BuilderConfigException: Incompatible source
> and target interface types for reference [greetingSuffix]
> Context stack trace:
> [tuscany.root][test][test][HelloWorldServiceComponent][GreetingSuffixComponent][tuscany.root]
> at
> org.apache.tuscany.core.builder.impl.DefaultWireBuilder.connect(DefaultWireBuilder.java:64)
> at
> org.apache.tuscany.core.runtime.RuntimeContextImpl.connect(RuntimeContextImpl.java:166)
> at
> org.apache.tuscany.core.context.impl.AbstractCompositeContext.connect(AbstractCompositeContext.java:792)
> at
> org.apache.tuscany.core.context.impl.AbstractCompositeContext.wireSource(AbstractCompositeContext.java:592)
> at
> org.apache.tuscany.core.context.impl.AbstractCompositeContext.start(AbstractCompositeContext.java:164)
> at
> org.apache.tuscany.core.context.scope.CompositeScopeContext.registerFactory(CompositeScopeContext.java:95)
> at
> org.apache.tuscany.core.context.impl.AbstractCompositeContext.registerConfiguration(AbstractCompositeContext.java:473)
> at
> org.apache.tuscany.core.context.impl.AbstractCompositeContext.registerModelObject(AbstractCompositeContext.java:420)
> at
> org.apache.tuscany.core.client.BootstrapHelper.registerModule(BootstrapHelper.java:133)
> at
> org.apache.tuscany.core.client.TuscanyRuntime.(TuscanyRuntime.java:103)
> at
> org.apache.tuscany.core.client.TuscanyRuntime.(TuscanyRuntime.java:67)
> at
> org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentTestCase.testGeetings(HelloWorldServiceComponentTestCase.java:32)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> To reproduce the problem use the attached test case.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-329) Simplified extension API improvements
[ http://issues.apache.org/jira/browse/TUSCANY-329?page=all ] Jim Marino closed TUSCANY-329. -- Resolution: Won't Fix Closing this out as an onld M1 issue > Simplified extension API improvements > - > > Key: TUSCANY-329 > URL: http://issues.apache.org/jira/browse/TUSCANY-329 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core >Affects Versions: Java-Mx >Reporter: ant elder > Assigned To: Jim Marino > Fix For: Java-Mx > > Attachments: AbstractImplementationLoader.java, > GroovyImplementationLoader.java > > > The work to create simple APIs for adding extensions has made some of the > work required to add an extension much simpler, but there's still things that > can be simplfied further for container extensions for new component types. > The relevant classes are the ContextFactory, ComponentContext, and > TargetInvoker which have a non trivial amount of code and its virtually > identical for most simple components. A ComponentTargetInvoker would also be > almost identical to the o.a.t.c.extension.ExternalServiceTargetInvoker. Code > for these classes already exists in the Java container, it just needs to be > refactored a little to be generic and moved to the o.a.t.c.extension package. > Be really great if we could get this done before M1 so we have stable > extension APIs for people to work with. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-682) NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple threads
[ http://issues.apache.org/jira/browse/TUSCANY-682?page=comments#action_12431923 ] Frank Budinsky commented on TUSCANY-682: I commited a fix, similar to the above patch, regardless of whether it fixes this problem or not. It's cleaner anyway. If you want to try it, it's in revision 438988. Frank. > NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple > threads > -- > > Key: TUSCANY-682 > URL: http://issues.apache.org/jira/browse/TUSCANY-682 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M1 > Environment: Win2K, multi-threaded load test >Reporter: Ron Gavlin >Priority: Critical > > I receive the following NPE when using Tuscany SDO in a multi-threaded > environment. Here is the stack trace: > java.lang.NullPointerException > at org.apache.tuscany.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) > at > org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2342) > at > org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:1284) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2032) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2139) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838) > at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:739) > at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:213) > ... > I suspect the NPE is due to synchronization problems with the > ClassImpl.propertyNameToPropertyMap. This problem occurs during load testing > of our application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-682) NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple threads
[ http://issues.apache.org/jira/browse/TUSCANY-682?page=comments#action_12431922 ] Frank Budinsky commented on TUSCANY-682: Ron, I think I need more info. Is the NPE because propertyNameToPropertyMap == null on this line: Property property = (Property)propertyNameToPropertyMap.get(propertyName); That's line 192 in my version. If so, I can't see any way, with my change, that it could be. Are you absolutely sure you're running code with my change applied? > NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple > threads > -- > > Key: TUSCANY-682 > URL: http://issues.apache.org/jira/browse/TUSCANY-682 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M1 > Environment: Win2K, multi-threaded load test >Reporter: Ron Gavlin >Priority: Critical > > I receive the following NPE when using Tuscany SDO in a multi-threaded > environment. Here is the stack trace: > java.lang.NullPointerException > at org.apache.tuscany.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) > at > org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2342) > at > org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:1284) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2032) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2139) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838) > at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:739) > at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:213) > ... > I suspect the NPE is due to synchronization problems with the > ClassImpl.propertyNameToPropertyMap. This problem occurs during load testing > of our application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-684) Generated SDO classes should be able to register the static types to a given TypeHelper
Generated SDO classes should be able to register the static types to a given TypeHelper --- Key: TUSCANY-684 URL: http://issues.apache.org/jira/browse/TUSCANY-684 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Raymond Feng Assigned To: Frank Budinsky In the generated SDO classes, static types are automatically registered into the EMF global registry. This behavior prevent us from keeping SDO types into different scopes defined by external schemes. It would be nice that we can do somthing like: SDOUtil.registerStaticTypes(TypeHelper scope, Class factoryClass); Thanks, Raymond -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-682) NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple threads
[ http://issues.apache.org/jira/browse/TUSCANY-682?page=comments#action_12431920 ] Ron Gavlin commented on TUSCANY-682: Hi Frank, I applied your patch and it had no affect. However, I did discover some interesting info during troubleshooting. The machine we are using to load test is a Wintel dual-core PC running WinXP. This machine gets the NPE with or without your patch. Just for kicks, I tried running the test on a single-processor Wintel PC running Win2K. This machine DOES NOT get the NPE with or without your patch. We are using Sun JDK 1.4.2_11 in both environments. Any suggestions where to go from here? - Ron > NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple > threads > -- > > Key: TUSCANY-682 > URL: http://issues.apache.org/jira/browse/TUSCANY-682 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M1 > Environment: Win2K, multi-threaded load test >Reporter: Ron Gavlin >Priority: Critical > > I receive the following NPE when using Tuscany SDO in a multi-threaded > environment. Here is the stack trace: > java.lang.NullPointerException > at org.apache.tuscany.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) > at > org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2342) > at > org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:1284) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2032) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2139) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918) > at > org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838) > at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:739) > at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:213) > ... > I suspect the NPE is due to synchronization problems with the > ClassImpl.propertyNameToPropertyMap. This problem occurs during load testing > of our application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sca recursive model sample update
Hello. Been away for a while. I am wondering if someone could update me on the status of the SCA samples running the recursive model. If there is work to be done here I would like to help on this effort as it will help me extend my knowledge of Tuscany from SDO into SCA. Robbie -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
[jira] Commented: (TUSCANY-682) NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple threads
[
http://issues.apache.org/jira/browse/TUSCANY-682?page=comments#action_12431917
]
Ron Gavlin commented on TUSCANY-682:
Hi Ron,
Multiple threads eh The only way I can see this happing is when
propertyNameToProperyMap is set back to null in getProperty(String). Could
you try changing a couple of ClassImpl methods to the following and see if
it fixes the problem?
private void initAliasNames(boolean force) {
if (propertyNameToPropertyMap == null || force)
{
Map result = new HashMap();
for (Iterator i = getProperties().iterator(); i.hasNext(); )
{
Property property = (Property)i.next();
result.put(property.getName(), property);
List aliasNames = property.getAliasNames();
for (int count = aliasNames.size(); count > 0; )
{
result.put(aliasNames.get(--count), property);
}
}
propertyNameToPropertyMap = result;
}
}
/**
*
*
* @generated NOT
*/
public Property getProperty(String propertyName)
{
initAliasNames(false);
Property property =
(Property)propertyNameToPropertyMap.get(propertyName);
if (property == null && !isOpen()) {
//propertyNameToPropertyMap = null;
initAliasNames(true);
property = (Property)propertyNameToPropertyMap.get(propertyName);
}
return property;
}
Thanks,
Frank.
> NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple
> threads
> --
>
> Key: TUSCANY-682
> URL: http://issues.apache.org/jira/browse/TUSCANY-682
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-M1
> Environment: Win2K, multi-threaded load test
>Reporter: Ron Gavlin
>Priority: Critical
>
> I receive the following NPE when using Tuscany SDO in a multi-threaded
> environment. Here is the stack trace:
> java.lang.NullPointerException
> at org.apache.tuscany.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2342)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:1284)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2032)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2139)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918)
> at
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838)
> at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:739)
> at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:213)
> ...
> I suspect the NPE is due to synchronization problems with the
> ClassImpl.propertyNameToPropertyMap. This problem occurs during load testing
> of our application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
On 8/31/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Oisin Hurley wrote:
>> I am not sure I understand the issue with create/delete (except if
>> PUT and DEL are disabled). Posting/putting to a URL that doesn't
>> exist yet to create that resource can be troubling. Is that the
>> issue? Are you looking for some kind of factory service pattern to
>> create resources?
>>
>> Or am I completely mis-understanding the issue you're describing
>> here? :)
>
> Apologies for not making the context clearer - however, you've got the
> point: there needs to be either a resource factory, or a generic
> resource
> holder to process create/delete of resources. I think I was attempting
> to say that a first cut would be ok to support just the GET/POST (as the
> most pressing scenarios) and then the PUT/DEL and factory approach could
> follow as a feature improvement.
>
> I will put up a wiki summary on this thread.
>
> cheers
> --oh
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Yes, GET/POST first, PUT/DELETE later sounds reasonable to me.
I've been struggling myself with the question on whether or not we need
some kind of resource holder/factory to create resources, and I'm now
starting to think that it really depends on how you view your resources.
Just a wild thought here...
If you view your resources as objects, you'll probably say that you need
a factory to do customerFactory->create("http:///customer/1234";).
Then you'll say customers->get("http:///customer/1234";) to retrieve
your customer object.
If on the other hand you view the Web as a giant distributed file
system, then it's not so shocking to say:
customers->createFile("http:///customer1234";);
customers->getFile("http://./customer1234";);
Thoughts?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sebastien
It's not clear that there is a difference between customers and
customerFactory in your example. You are saying that there is some resource
that causes the correct interpretation of PUT type requrests
w.r.tgenerating/recording new resources that represent customers. This
resource
itself may, for example, represent the list of customers it has created in
response to GET type requests. The relationship between Customers and
Customer is not a wired relationship in the SCA sense but a resource
relationship as dictated by the URLs used to represent endpoints.
Regards
Simon
[jira] Created: (TUSCANY-683) [SDO for C++] Adopt Apache stdcxx as an alternative standard C++ library
[SDO for C++] Adopt Apache stdcxx as an alternative standard C++ library Key: TUSCANY-683 URL: http://issues.apache.org/jira/browse/TUSCANY-683 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Environment: Windows XP and Linux Reporter: Geoff Winn There is an Apache incubator project to develop an implementation of the standard C++ library (their web site is here http://incubator.apache.org/stdcxx). Currently, in SDO for C++, we use the library provided by whichever platform we happen to run on. Using the Apache stdcxx library instead would provide us with a number of benefits - It is available on a wide range of platforms - It is the same implementation on all of them (so avoids obscure bugs from slight differences in C++ libraries) - It is open source so we can contribute fixes rather than writing around problems. - We become better citizens of the Apache community The one difficulty is that once SDO links against the stdcxx library then all users of SDO must also do so. Therefore, implement a build time switch that chooses between whatever the platform offers (ie the current arrangement) and stdcxx, defaulting to the current arrangement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Databindings
I just had an offline chat with Sebastien re. what is the story with databindings and the C++ SCA runtime as it stands. Here is the summary... Currently C++ SCA uses SDOs for remote calls In the future other databindings may be supported depending on demand Specifically, in the current code the following is assumed... - Bindings assume remotable interfaces - A Remotable interface maps to a WSDL (we don't necessarily need the WSDL but it's mappable to WSDL) - In WSDL all types are described by XSDs - XSD's map to SDO - The component is either C++ and happy with the SDO interface OR - The component is another language and we provide either - an SDO API OR - Good integration between SDO and the native language constructs Regards Simon
Re: REST bindings for Tuscany SCA runtime
Oisin Hurley wrote:
I am not sure I understand the issue with create/delete (except if
PUT and DEL are disabled). Posting/putting to a URL that doesn't
exist yet to create that resource can be troubling. Is that the
issue? Are you looking for some kind of factory service pattern to
create resources?
Or am I completely mis-understanding the issue you're describing
here? :)
Apologies for not making the context clearer - however, you've got the
point: there needs to be either a resource factory, or a generic
resource
holder to process create/delete of resources. I think I was attempting
to say that a first cut would be ok to support just the GET/POST (as the
most pressing scenarios) and then the PUT/DEL and factory approach could
follow as a feature improvement.
I will put up a wiki summary on this thread.
cheers
--oh
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Yes, GET/POST first, PUT/DELETE later sounds reasonable to me.
I've been struggling myself with the question on whether or not we need
some kind of resource holder/factory to create resources, and I'm now
starting to think that it really depends on how you view your resources.
Just a wild thought here...
If you view your resources as objects, you'll probably say that you need
a factory to do customerFactory->create("http:///customer/1234";).
Then you'll say customers->get("http:///customer/1234";) to retrieve
your customer object.
If on the other hand you view the Web as a giant distributed file
system, then it's not so shocking to say:
customers->createFile("http:///customer1234";);
customers->getFile("http://./customer1234";);
Thoughts?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO for C++] Opinions Requested: Adopting stdcxx as C++ library
OK. That's pretty conclusive. I'll raise a JIRA for it and implement option 2. Geoff. On 30/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Simon Laws wrote: > On 8/30/06, Pete Robbins <[EMAIL PROTECTED]> wrote: >> >> On 30/08/06, Andrew Borley <[EMAIL PROTECTED]> wrote: >> > >> > On 8/30/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: >> > . Using the Apache stdcxx library instead would provide >> > >> > > us with a number of benefits >> > >> > >> > Agreed. +1 for this. >> >> >> yup! >> >> The one difficulty is that once SDO links against the stdcxx library >> then >> > > all users of SDO must also do so. I think this gives us two options >> > > >> > > 1. Just do it, and live with the consequences. In this case we will >> (one >> > > way >> > > or another) pre-req stdcxx on all platforms, and all users of SDO >> for >> > C++ >> > > will be required to use stdcxx as their C++ standard library. >> > > >> > > 2. Create a build time switch that chooses between whatever the >> platform >> > > offers (ie the current arrangement) and stdcxx. Presumably >> defaulting >> to >> > > the >> > > current arrangement. >> > > >> > > I prefer option 2 but obviously it somewhat complicates our build >> > process >> > > and perhaps more seriously adds another complication to our test >> cases. >> > > >> > > What does the team think? >> >> >> My preference is also for option 2 as it gives our users more choice. >> > However, we may find ourselves #ifdef-ing chunks of code out to get >> around >> > the aforementioned differences in libraries (see Pete's map problem on >> > Windows yesterday..) which will make code less readable, etc. I think >> > starting this with the SDO codebase is a good idea, as this is a >> > relatively >> > standalone set of code, and will give us a good idea what the >> issues are >> > with this approach. >> >> >> Defintiely option 2! >> >> A side question - SDO has a couple of pre-reqs (libxml2, etc) - will >> these >> > need to be rebuilt against stdcxx as well? >> >> >> libxml2 is C rather than c++ so I don't think this is an issue. Same for >> Axis2C for the sdo_axiom utility. >> >> Cheers, >> >> -- >> Pete > > > > Generall I +1 the move to stdcxx and specifically to option 2 because... > > In PHP SDO land, which of course uses Tuscany SDO, we tend to have faily > autonomous builds, i.e. we expect our users to be able to download the > SDO > package and build it without having to download too much other stuff. At > least other stuff that isn't already known to the PHP build system . We > already depend on libxml2, iconv & zlib but these are generally > available in > linux at stable versions. If we add a mandatory dependency on the apache > incubator version of stdxx then we have added another barrier to entry as > there is another packge to download that people may not be familiar > with and > may cause clashes with other extensions that use other solutions. We > won't > know until we try it. It may also cause problems for the automatic > windows > build that takes place on the PECL servers outside of our control. I > don't > really know the details of this though so would have to look into it. > > Simon > +1 for option 2 as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] VC7 SCA project
On 8/31/06, Andrew Borley <[EMAIL PROTECTED]> wrote: Nope - I've been using the VC6 one - just start it up and VC7 gives you the option of converting the project and creating the.sln file, etc Andy On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > Does anyone have a version of the VC7 project for SCA that matches the > reorganized code? If not I'll make one > > Regards > > Simon > > OK, so I did that but I had to make a few fixes. In particlar I get http://msdn2.microsoft.com/en-us/library/t72ahzw1.aspx For Service.h Interface.h Binding.h ServiceBinding.h ReferenceBinding.h The code also uses the word "interface" as a parameter name which causes havoc with my version of VC7. Have fixed it in CompositeService.h/.cpp CompositeReference.h/.cpp ServiceType.h/.cpp Contract.h/.cpp ReferenceType.h/.cpp Of course I would normally go ahead and raise a JIRA but I find it hard to believe that these haven't already been fixed somehow. Am I doing something wrong? Happy to raise a JIRA and attach a patch. Regards Simon
Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException
Hi,
I think we probably have a problem with the proper scoping for the SDO types
(especially static types which are registered by classloaders today). I'll
start a new thread to involve the folks on the SDO side.
Meanwhile, can you try to use "commonj.sdo.DataObject" for your business
interface to see if it helps?
Thanks,
Raymond
- Original Message -
From: "Chris Wall" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, August 30, 2006 5:27 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call produces
TargetException leads to ClassCastException
Hi Raymond. Thanks for your patience.
With the factory declaraion I'm getting the same thing...
org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getString' not found in registered SDO types.
at org.apache.tuscany.binding.celtix.io.NodeDataWriter.toXMLDocument(
NodeDataWriter.java:142)
at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper(
NodeDataWriter.java:84)
at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper(
NodeDataWriter.java:47)
at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.addParts(
SOAPBindingImpl.java:567)
at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.marshal(
SOAPBindingImpl.java:119)
at org.objectweb.celtix.bindings.Request.process(Request.java:91)
org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
http://www.bea.com/medrec}getPatient' not found in registered SDO types.
Updated scdl:
E:/sca/tuscany/java/samples/sca/medrec 190$ cat
target/classes/META-INF/sca/default.scdl
http://www.osoa.org/xmlns/sca/1.0";
xmlns:system="http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT
"
name="tuscanyWS2WLS">
MedRecWebServicesService
http://www.bea.com/medrec#wsdl.endpoint(MedRecWebServices/MedRecWebServicesPort)
"
location="wsdl/MedRecWebServices.wsdl" />
On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Chris.
You probably need to use the following "import.sdo":
Thanks,
Raymond
- Original Message -
From: "Chris Wall" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, August 30, 2006 4:24 PM
Subject: Re: Returning DynamicDataObjectImpl from web service call
produces
TargetException leads to ClassCastException
> Hey. Comments inline...
>
>
> On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi, Chris.
>>
>> If you have , it
>> means
>> that you prefer to use the dynamic SDO model derived from the
>> WSDL/XSD.
I
>> have two questions:
>
>
> CW: Ahh, I did not know. Yet, if I remove the import the following
line
> throws an exception:
>
> [NodeDataWriter}
> Property property = xsdHelper.getGlobalProperty(
>elementQName.getNamespaceURI(), elementQName.getLocalPart(),
> true);
>
> org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{
> http://www.bea.com/medrec}getString' not found in registered SDO types.
>
> With import.sdo, this web service call returns successfully.
>
> 1) Is the exception from client side or server side?
>
>
> CW: Client. Occurs within Proxy.getPatient(...).
>
> 2) What's our business interface expecting? The strongly-typed java
>> class/interface generated by SDO or the dynamic DataObject?
>
>
> CW: Strongly-typed:
>
> com.bea.proto.webservice.Patient
> getPatient(com.bea.proto.webservice.PatientpPatient) throws Exception;
>
>
> Basically, the "import.sdo" needs to be consistent with your business
>> interface signature.
>>
>> Thanks,
>> Raymond
>>
>> - Original Message -
>> From: Chris Wall
>> To: Raymond Feng
>> Sent: Wednesday, August 30, 2006 4:05 PM
>> Subject: Re: Returning DynamicDataObjectImpl from web service call
>> produces
>> TargetException leads to ClassCastException
>>
>>
>> Hey Raymond.
>>
>> Our *client* scdl has:
>> .
>>
>> Deserialized into the dynamic SDO makes
>> sense. XMLStreamReader2XMLDocument
>> parses the stream and creates a DynamicDataObjectImpl as it's root
>> object.
>> DynamicDataObjectImpl is aware of it's Patient context -
>> name=getPatientResponse, package=java: com.bea.proto.webservice, and
>> attributes. It's the root object that is returned from the binding.
>>
>> Shouldn't there be an intermediate step that generates a Patient
object?
>>
>> -Chris
>>
>>
>>
>> On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> It seems that the exception is thrown from the target component and
it's
>> related to the static/dynamic SDO (The incoming XML got deserialized
into
>> the dynamic SDO instead of the generated static class which your
>> component
>> implementation code expects).
>>
>> What does the "import.sdo" look like on the server side? Using "<
>> import.sdo
>> factory="..."/>"?
>>
>> Thanks,
>> Raymond
>> - Original Message -
>> From: Chris Wall
>> To: tuscany-dev@ws.apache.org ; [EMAIL PROTECTED]
>> Sent: Wednesday, August 30, 2006 2:37 PM
>> Subject: Returning DynamicDataObjectImpl from web service call
>>
Re: Including schemas in SCA API jar?
I would like to see the schemas included and kept up-to-date. It would be useful for validation purposes at least. I'm fine with org/osoa/sca/schema. Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Wednesday, August 30, 2006 7:20 PM Subject: Including schemas in SCA API jar? We currently include the SCA schema's in the sca-api jar in the location /schemas/* - two questions: 1) should we continue to do this? 2) if we do, should we move them to a better place e.g. org/osoa/sca/ schema ? -- Jeremy - 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: REST bindings for Tuscany SCA runtime
I am not sure I understand the issue with create/delete (except if PUT and DEL are disabled). Posting/putting to a URL that doesn't exist yet to create that resource can be troubling. Is that the issue? Are you looking for some kind of factory service pattern to create resources? Or am I completely mis-understanding the issue you're describing here? :) Apologies for not making the context clearer - however, you've got the point: there needs to be either a resource factory, or a generic resource holder to process create/delete of resources. I think I was attempting to say that a first cut would be ok to support just the GET/POST (as the most pressing scenarios) and then the PUT/DEL and factory approach could follow as a feature improvement. I will put up a wiki summary on this thread. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-682) NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple threads
NPE at o.a.t.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) w/multiple threads -- Key: TUSCANY-682 URL: http://issues.apache.org/jira/browse/TUSCANY-682 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M1 Environment: Win2K, multi-threaded load test Reporter: Ron Gavlin Priority: Critical I receive the following NPE when using Tuscany SDO in a multi-threaded environment. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.impl.ClassImpl.getProperty(ClassImpl.java:192) at org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2342) at org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:1284) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2032) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2139) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838) at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:739) at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:213) ... I suspect the NPE is due to synchronization problems with the ClassImpl.propertyNameToPropertyMap. This problem occurs during load testing of our application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Meeraj Kunnumpurath for Tuscany committer
I contacted JimJ when I came back from vacation and asked him what was going on; I didn't get a reply so he may be busy. I asked Meeraj to fax his ICLA again and he did it this morning. -- Jeremy On Aug 31, 2006, at 6:13 AM, ant elder wrote: Just remembered I'd not seen anymore on this and see Meeraj still doesn't appear on the CLA list. Should there be a another ICLA fax attempt? ...ant On 8/8/06, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: Jeremy, meerajk is fine with me. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 08 August 2006 14:01 To: tuscany-dev@ws.apache.org Subject: Re: [RESULT] Meeraj Kunnumpurath for Tuscany committer To submit the account request, please could you tell me the username you would like to have? -- Jeremy On Aug 8, 2006, at 3:34 AM, Meeraj Kunnumpurath wrote: > Thanks a lot for voting me in. > > Ta > Meeraj > > -Original Message- > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > Sent: 07 August 2006 16:30 > To: tuscany-dev@ws.apache.org > Subject: [RESULT] Meeraj Kunnumpurath for Tuscany committer > > Passed with +1's from: > jboynes > jmarino > kwilliams > robbinspg > jsdelfino > rineholt > kentam > > and no -1's. > > I would like to welcome Meeraj as a committer and will start the > process of setting up his account. > -- > Jeremy > > On Aug 3, 2006, at 12:44 PM, Jeremy Boynes wrote: > >> I would like to nominate Meeraj to become a committer on Tuscany - he >> has been active in the project for quite a while now, contributing >> the > >> original Groovy container implementation, a work manager >> implementation for use by async invocations and has worked to debug >> several problems including some tricky synchronization issues. I >> think > >> he will continue to be a valuable contributor to the project. >> >> Here's my +1. >> -- >> Jeremy >> >> >> - >> 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] > > > This message has been checked for all email viruses by MessageLabs. > > > > > * > > You can find us at www.voca.com > > * > This communication is confidential and intended for the exclusive use > of the addressee only. You should not disclose its contents to any > other person. > If you are not the intended recipient please notify the sender named > above immediately. > > Registered in England, No 1023742, > Registered Office: Voca Limited > Drake House, Three Rivers Court, > Homestead Road, Rickmansworth, > Hertfordshire, WD3 1FX > > > This message has been checked for all email viruses by MessageLabs. > > - > 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] This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - 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: [C++] VC7 SCA project
Nope - I've been using the VC6 one - just start it up and VC7 gives you the option of converting the project and creating the.sln file, etc Andy On 8/31/06, Simon Laws <[EMAIL PROTECTED]> wrote: Does anyone have a version of the VC7 project for SCA that matches the reorganized code? If not I'll make one Regards Simon
Re: Tuscany war plugin
Great - thanks. I think there are three categories: WEB-INF/lib: webapp and its dependencies (host-api) - I think these can just be project dependencies WEB-INF/tuscany/boot: webapp-host and its dependencies - configuration element WEB-INF/tuscany/extensions: configuration element All of these should have defaults that can be overridden in the section of the pom, something like: org.apache.tuscany.plugin tuscany-war-plugin org.apache.tuscany core org.apache.tuscany axis2 We should also support all the features of the normal war plugin - I assume we can get that just by subclassing it. Hope that's enough to get started :-) -- Jeremy On Aug 31, 2006, at 5:09 AM, Meeraj Kunnumpurath wrote: Jeremy, I am starting on the war plugin. Could you pls point me to the runtime artefacts (tuscany boot libraries etc) that need to be included in the war? Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 29 August 2006 16:21 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Basically set up jars for the runtime rather than using war dependencies to put them in WEB-INF/lib. This would include: * Copy the webapp host jars to WEB-INF/lib * Copy the core runtime to e.g. WEB-INF/tuscany/boot * Take a set of extensions (as artifact references) and add them to e.g. WEB-INF/tuscany/extension * Copy extension dependencies to somewhere an ArtifactRepository can find them It could also check web.xml for the presence of the Tuscany listeners etc. and potentially add them. -- Jeremy On Aug 29, 2006, at 7:20 AM, Bert Lamb wrote: Is there more information on what specifically this plugin would need to do? -Bert On 8/28/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: Jim had said that as a prereq to a release then we should have a maven plugin that will set up the webapp runtime in a war. I think that having such a beast would make building the samples easier and so would suggest we get to work on it - is anyone interested in helping? -- Jeremy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - 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]
[C++] VC7 SCA project
Does anyone have a version of the VC7 project for SCA that matches the reorganized code? If not I'll make one Regards Simon
Re: Optiional Autowire
Sure I can give it a shot. I just don't want to interfere with your update. Jim Marino wrote: Rick, I realized I need to take a look at Ignacio's patch since I'm sure it won't apply cleanly with the SPI changes in place. So, if you don't mind, could you take a look at adding optional autowires? Here is what needs to be done: 1. Change the autowire annotation to default to required true (obvious) 2. The implementation processing framework needs to be updated to introspect autowire annotations and update ReferenceDefinition.setRequired(). ReferenceDefinition is used to represent references in general, and autowires in particular, which are treated as a type. There are several processors which may need updating. One is ImplementationProcessorServiceImpl. 3. SystemComponentBuilder needs to be modified to deal with ReferenceDefinition.isRequired() for autowires and pass that to the SystemOutboundAutowire constructor (which will need to be modified to add a required field) as it creates system wires. 4. SystemOutboundAutowire when it resolves the autowire will throw an exception if its required field is true. Let me know if I can help out. Jim On Aug 30, 2006, at 2:06 PM, Jim Marino wrote: On Aug 30, 2006, at 1:41 PM, Rick wrote: Sure why meddle with the master! :-) I'd actually not mind avoiding doing it myself but I prefer that to having to reconcile changes Seriously, the only request I would have is if convenient could you make it a separate svn checkin? Just like to review what you did for just this. Yep. That's what I intend to do The autowire information as far as I see is lost in the connection building phase, unless I missed it. Was wondering if it could not be added directly to the ServiceContract. It shouldn't be on the service contract since it is part of the component type (autowire is really a type of reference). ReferenceDefinition already contains the information needed and can be accessed from the system component builder. Jim - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inner composite patch, was Re: Optiional Autowire
On 8/31/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote: I am getting a good picture of what needs to be done for async callbacks over ws binding w/axis2 and I can keep looking at this in my current sandbox until you are done, so it's not like I am stuck. Could you post an email about what and how you're looking at doing async and Axis2? There's a few of us who've worked on this binding in the past who'd be interested, I didn't even know you were looking at this until it was mentioned on IRC yesterday (unless I missed some previous email). ...ant
[jira] Resolved: (TUSCANY-676) ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException)
[ http://issues.apache.org/jira/browse/TUSCANY-676?page=all ] Frank Budinsky resolved TUSCANY-676. Resolution: Fixed Fixed in revision 438921. > ImportSDOLoader: DataTypeImpl not found in > XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as > IllegalArgumentException) > > > Key: TUSCANY-676 > URL: http://issues.apache.org/jira/browse/TUSCANY-676 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Reporter: Chris Wall > Attachments: medrec.zip, MedRecWebServices.wsdl, tuscany-676.patch, > xsdecorebuilder_npe.zip > > > During SDO import of WSDL, elements of the following complex type are not > found when validated against available SDO datatypes within the XSD layer > (XSDEcoreBuilder). Downstream this causes an NPE. It could be that the > comparison between the type and the key is not properly implemented. See the > attached zip containing debug screenshots. > targetNamespace="java:com.bea.proto.webservice" xmlns:xs=" > http://www.w3.org/2001/XMLSchema";> > > > >type="xs:dateTime"/> >type="xs:string"/> >type="xs:string"/> >type="xs:string"/> >type="xs:string"/> >type="xs:string"/> > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Inner composite patch, was Re: Optiional Autowire
Hi Jim, Would you please let me know when you are done applying the inner composite patch? Don't mean to rush you, but I'd rather wait until that is done before I do another update, I imagine my current local sandbox would get pretty messy if I update now ... ;-) I am getting a good picture of what needs to be done for async callbacks over ws binding w/axis2 and I can keep looking at this in my current sandbox until you are done, so it's not like I am stuck. Thanks - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Thursday, August 31, 2006 1:38 AM Subject: Re: Optiional Autowire Rick, I realized I need to take a look at Ignacio's patch since I'm sure it won't apply cleanly with the SPI changes in place. So, if you don't mind, could you take a look at adding optional autowires? Here is what needs to be done: 1. Change the autowire annotation to default to required true (obvious) 2. The implementation processing framework needs to be updated to introspect autowire annotations and update ReferenceDefinition.setRequired(). ReferenceDefinition is used to represent references in general, and autowires in particular, which are treated as a type. There are several processors which may need updating. One is ImplementationProcessorServiceImpl. 3. SystemComponentBuilder needs to be modified to deal with ReferenceDefinition.isRequired() for autowires and pass that to the SystemOutboundAutowire constructor (which will need to be modified to add a required field) as it creates system wires. 4. SystemOutboundAutowire when it resolves the autowire will throw an exception if its required field is true. Let me know if I can help out. Jim On Aug 30, 2006, at 2:06 PM, Jim Marino wrote: On Aug 30, 2006, at 1:41 PM, Rick wrote: Sure why meddle with the master! :-) I'd actually not mind avoiding doing it myself but I prefer that to having to reconcile changes Seriously, the only request I would have is if convenient could you make it a separate svn checkin? Just like to review what you did for just this. Yep. That's what I intend to do The autowire information as far as I see is lost in the connection building phase, unless I missed it. Was wondering if it could not be added directly to the ServiceContract. It shouldn't be on the service contract since it is part of the component type (autowire is really a type of reference). ReferenceDefinition already contains the information needed and can be accessed from the system component builder. Jim - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-681) Port of Tuscany C++ to Mac OS X, powerpc arch
Port of Tuscany C++ to Mac OS X, powerpc arch - Key: TUSCANY-681 URL: http://issues.apache.org/jira/browse/TUSCANY-681 Project: Tuscany Issue Type: New Feature Components: C++ Build, C++ SCA, C++ SDO Environment: MacOS X 10.4.7 PowerPC Reporter: Oisin Hurley Priority: Minor Plain old porting job - prerequisite is a port of Axis2C for axiom bits and hosting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-671) Port JSON-RPC binding from M1
Thanks again for this Bert. Are you interested in helping continue development in this area? There's a lot we could look at doing with json and ajax so if you're interested I'll start some discussion threads. ...ant On 8/31/06, ant elder (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-671?page=all ] ant elder closed TUSCANY-671. - Resolution: Fixed Applied. Many thanks for the code Bert. > Port JSON-RPC binding from M1 > - > > Key: TUSCANY-671 > URL: http://issues.apache.org/jira/browse/TUSCANY-671 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA JsonRpc Binding >Affects Versions: Java-M2 >Reporter: Bert Lamb > Assigned To: ant elder >Priority: Minor > Attachments: json-rpc-binding.zip > > > Port the JSON-RPC binding from M1 into the new binding format. I've been working on this, so I should be able to post a patch soon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-671) Port JSON-RPC binding from M1
[ http://issues.apache.org/jira/browse/TUSCANY-671?page=all ] ant elder closed TUSCANY-671. - Resolution: Fixed Applied. Many thanks for the code Bert. > Port JSON-RPC binding from M1 > - > > Key: TUSCANY-671 > URL: http://issues.apache.org/jira/browse/TUSCANY-671 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA JsonRpc Binding >Affects Versions: Java-M2 >Reporter: Bert Lamb > Assigned To: ant elder >Priority: Minor > Attachments: json-rpc-binding.zip > > > Port the JSON-RPC binding from M1 into the new binding format. I've been > working on this, so I should be able to post a patch soon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Meeraj Kunnumpurath for Tuscany committer
Just remembered I'd not seen anymore on this and see Meeraj still doesn't appear on the CLA list. Should there be a another ICLA fax attempt? ...ant On 8/8/06, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: Jeremy, meerajk is fine with me. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 08 August 2006 14:01 To: tuscany-dev@ws.apache.org Subject: Re: [RESULT] Meeraj Kunnumpurath for Tuscany committer To submit the account request, please could you tell me the username you would like to have? -- Jeremy On Aug 8, 2006, at 3:34 AM, Meeraj Kunnumpurath wrote: > Thanks a lot for voting me in. > > Ta > Meeraj > > -Original Message- > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > Sent: 07 August 2006 16:30 > To: tuscany-dev@ws.apache.org > Subject: [RESULT] Meeraj Kunnumpurath for Tuscany committer > > Passed with +1's from: > jboynes > jmarino > kwilliams > robbinspg > jsdelfino > rineholt > kentam > > and no -1's. > > I would like to welcome Meeraj as a committer and will start the > process of setting up his account. > -- > Jeremy > > On Aug 3, 2006, at 12:44 PM, Jeremy Boynes wrote: > >> I would like to nominate Meeraj to become a committer on Tuscany - he >> has been active in the project for quite a while now, contributing >> the > >> original Groovy container implementation, a work manager >> implementation for use by async invocations and has worked to debug >> several problems including some tricky synchronization issues. I >> think > >> he will continue to be a valuable contributor to the project. >> >> Here's my +1. >> -- >> Jeremy >> >> >> - >> 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] > > > This message has been checked for all email viruses by MessageLabs. > > > > > * > > You can find us at www.voca.com > > * > This communication is confidential and intended for the exclusive use > of the addressee only. You should not disclose its contents to any > other person. > If you are not the intended recipient please notify the sender named > above immediately. > > Registered in England, No 1023742, > Registered Office: Voca Limited > Drake House, Three Rivers Court, > Homestead Road, Rickmansworth, > Hertfordshire, WD3 1FX > > > This message has been checked for all email viruses by MessageLabs. > > - > 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] This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-680) Add Python implementation binding
Add Python implementation binding - Key: TUSCANY-680 URL: http://issues.apache.org/jira/browse/TUSCANY-680 Project: Tuscany Issue Type: New Feature Components: C++ SCA Affects Versions: Cpp-current Reporter: Andrew Borley Priority: Minor Add a component implementation binding for invoking components written in Python -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Build instructions on Web site
Hi Oisin, Yep, that would be good. Andy On 8/31/06, Oisin Hurley <[EMAIL PROTECTED]> wrote: > Great! I don't think that anybody has tried MacOS X yet. It will be > really great if you can port the Linux build... and then we can all > get iBooks :) I've to get axis2c ported first :) Would it be good practice to put a JIRA in for this so that it's visible? cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tuscany war plugin
Jeremy, I am starting on the war plugin. Could you pls point me to the runtime artefacts (tuscany boot libraries etc) that need to be included in the war? Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 29 August 2006 16:21 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Basically set up jars for the runtime rather than using war dependencies to put them in WEB-INF/lib. This would include: * Copy the webapp host jars to WEB-INF/lib * Copy the core runtime to e.g. WEB-INF/tuscany/boot * Take a set of extensions (as artifact references) and add them to e.g. WEB-INF/tuscany/extension * Copy extension dependencies to somewhere an ArtifactRepository can find them It could also check web.xml for the presence of the Tuscany listeners etc. and potentially add them. -- Jeremy On Aug 29, 2006, at 7:20 AM, Bert Lamb wrote: > Is there more information on what specifically this plugin would need > to do? > > -Bert > > On 8/28/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> Jim had said that as a prereq to a release then we should have a >> maven plugin that will set up the webapp runtime in a war. I think >> that having such a beast would make building the samples easier and >> so would suggest we get to work on it - is anyone interested in >> helping? >> >> -- >> Jeremy >> >> >> - >> 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Build instructions on Web site
Great! I don't think that anybody has tried MacOS X yet. It will be really great if you can port the Linux build... and then we can all get iBooks :) I've to get axis2c ported first :) Would it be good practice to put a JIRA in for this so that it's visible? cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mvn -Peclipse eclipse:eclipse doesn't work any more
Hi, It seems that we added "." to the resource folder in pom.xml in recent checkins as follows: . META-INF true LICENSE.txt NOTICE.txt This breaks the maven eclipse plugin and the generated classpaths are messed up. I guess we need to apply the eclipse profile hack. Thanks, Raymond
Re: svn commit: r438785: move to ServiceContract/Operation
I'd prefer ASM (CGLIB is built using it) since it is smaller, easier to use (CGLIB documentation is awful) and will probably give us more flexibility. What we need to do is provide an implementation of WireService that uses an approach which dispatches method invocations directly to the correct invocation chain. The JDK wire service currently creates invocation handlers that resolve the chain to invoke based on the method passed in from the proxy. We should be able to generate proxy code that does a "static" invoke to the correct chain without the overhead of a map lookup (see the JDK-based implementations of invocation handler). In addition, we should be able to create optimized variants of WireInvocationHandler. We particularly need to optimize JDKCallbackInvocationHandler and the JDKOutboundInvocationHandler constructor. As a note, I still need to switch over WireInvocationHandler.invoke (Method method, Object[] args) to take an Operation instead of a method. Geronimo I believe uses something similar so perhaps Jeremy could describe it further? I've also seen this done in Aspectwerkz with extremely fast performance. Jim On Aug 31, 2006, at 12:04 AM, Venkata Krishnan wrote: Hi Jim, I worked a bit with cglib to generate manipulated intefaces as apart of the RMI-Binding and JavaScript e4x stuff. If this is good for a start, then please let me know what is to be done in JDKWireService. Thanks - Venkat On 8/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: I have committed the changes to use ServiceContract/Operation in place of Java Interface/Method. This entailed modifications in SPI, particularly the signatures for classes in the wire package (e.g. RuntimeWire, InvocationChain), WireService, and Component (createTargetInvoker). ServiceContracts are created by an introspection registry for a given IDL. These registries may use the same pattern as registries for loaders and builders. For example, Java IDL has a JavaInterfaceProcessorRegistryImpl that delegates to JavaInterfaceProcessor implementations to populate a ServiceContract reflected from a Java interface. JavaInterfaceProcessor implementations may be system services which register with a JavaInterfaceProcessorRegistry, thereby adding support for metadata extensions (such as information specific to a databinding type). ServiceContract metadata is used to decorate wires. RuntimeWire has a new method getServiceContract() which will return the service contract associated with an inbound or outbound wire. Similarly, Invocation chains are decorated with an Operation. This metadata will be used by a new system service responsible for "optimizing/ mediating" wires as they are connected by the wiring infrastructure. This system service will be another registry with a set of builders. It will be different than the policy builder registry since policy builders only operate on one side of a wire (source or target). Raymond's databinding framework will use these facilities to introspect the outbound and inbounds parts of a wire and add appropriate interceptors. Currently, Operation and ServiceContract do not have facilities for runtime extensibility metadata; I will be adding these along with the new type of "optimizing/mediating" registry (probably) tomorrow. One outstanding work item is to provide a performant replacement for JDK proxies (JDKWireService). I suspect we will see significant performance penalties for local invocations, particularly callbacks, as several map lookups are done. If anyone is interested in creating an implementation of WireService based on a bytecode generation library such as ASM, please let me know and I will try and provide pointers. Jim - 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: Jetty based standalone distribution (was: Re: Sample framework)
Hi Ant, Have you started with this? I must start with some baby steps into this. So if there is something that you'd like me to help out with, in this, please let me know. Thanks. - Venkat On 8/29/06, Jim Marino <[EMAIL PROTECTED]> wrote: On Aug 29, 2006, at 4:45 AM, ant elder wrote: > Ok Jim, I'd like start work on getting this Jetty based standalone > distribution going. Eventually I'd like a distribution which > includes things > like Jetty, So what needs to be done is: 1. Add an XPath engine into core to evaluate inclusion of a separate configuration file to handle setup of things like port (this would implement the property inclusion mechanism from the SCA spec) 2. Add an HTTPS connector to Jetty (involves getting it to work with a keystore) 3. Cleanup Jetty thread pool integration with the core WorkScheduler 4. A lot more unit tests 5. Integration testing > Axis2/WS, rmi, json, groovy, javascript and spring. I'd also > like some pre-installed samples, maybe in addition to the bin, > boot, and > extensions directories in the existing standalone distribution also > have an > applications directory to contain the samples and other > applications. And I > guess some bat/shell scripts to do startup etc. > > Anyone else interested in helping with this? > > ...ant >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r438785: move to ServiceContract/Operation
Hi Jim, I worked a bit with cglib to generate manipulated intefaces as apart of the RMI-Binding and JavaScript e4x stuff. If this is good for a start, then please let me know what is to be done in JDKWireService. Thanks - Venkat On 8/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: I have committed the changes to use ServiceContract/Operation in place of Java Interface/Method. This entailed modifications in SPI, particularly the signatures for classes in the wire package (e.g. RuntimeWire, InvocationChain), WireService, and Component (createTargetInvoker). ServiceContracts are created by an introspection registry for a given IDL. These registries may use the same pattern as registries for loaders and builders. For example, Java IDL has a JavaInterfaceProcessorRegistryImpl that delegates to JavaInterfaceProcessor implementations to populate a ServiceContract reflected from a Java interface. JavaInterfaceProcessor implementations may be system services which register with a JavaInterfaceProcessorRegistry, thereby adding support for metadata extensions (such as information specific to a databinding type). ServiceContract metadata is used to decorate wires. RuntimeWire has a new method getServiceContract() which will return the service contract associated with an inbound or outbound wire. Similarly, Invocation chains are decorated with an Operation. This metadata will be used by a new system service responsible for "optimizing/ mediating" wires as they are connected by the wiring infrastructure. This system service will be another registry with a set of builders. It will be different than the policy builder registry since policy builders only operate on one side of a wire (source or target). Raymond's databinding framework will use these facilities to introspect the outbound and inbounds parts of a wire and add appropriate interceptors. Currently, Operation and ServiceContract do not have facilities for runtime extensibility metadata; I will be adding these along with the new type of "optimizing/mediating" registry (probably) tomorrow. One outstanding work item is to provide a performant replacement for JDK proxies (JDKWireService). I suspect we will see significant performance penalties for local invocations, particularly callbacks, as several map lookups are done. If anyone is interested in creating an implementation of WireService based on a bytecode generation library such as ASM, please let me know and I will try and provide pointers. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
