You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Wojtek Janiszewski <wo...@gmail.com> on 2008/04/30 19:43:04 UTC
GSoC Project - CORBA Support for Apache Tuscany
Hi,
Raymond Feng checked in some skeleton code for CORBA services and
references binding. To start project I've tried to build Tuscany. I've
followed this document [1], tried to make top-down build with code from
[2] and got Build Failure while testing "Apache Tuscany SCA XML Assembly
Model".
I'm using maven 2.0.7, jdk1.5.0_09, Slackware Linux running 2.6.23.12
kernel.
Tests in error:
testResolveConstrainingType(org.apache.tuscany.sca.assembly.xml.WireTestCase)
testResolveComposite(org.apache.tuscany.sca.assembly.xml.WireTestCase)
testReadWireWriteComposite(org.apache.tuscany.sca.assembly.xml.WriteAllTestCase)
testPolicyIntentInheritance(org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase)
Exceptions for every test are quite the same:
java.util.MissingResourceException: Can't find
assembly-validation-messages bundle
at java.util.logging.Logger.setupResourceInfo(Logger.java:1309)
at java.util.logging.Logger.<init>(Logger.java:204)
at java.util.logging.Logger.getLogger(Logger.java:300)
at
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1.problem(CompositeBuilderImpl.java:89)
at
org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.warning(BaseConfigurationBuilderImpl.java:297)
at
org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.indexImplementationPropertiesServicesAndReferences(BaseConfigurationBuilderImpl.java:616)
at
org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:197)
at
org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:85)
at
org.apache.tuscany.sca.assembly.builder.impl.ComponentConfigurationBuilderImpl.build(ComponentConfigurationBuilderImpl.java:47)
at
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:127)
at
org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase.setUp(BuildPolicyTestCase.java:126)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
[1] - http://incubator.apache.org/tuscany/sca-java-development-guide.html
[2] - http://svn.apache.org/repos/asf/incubator/tuscany/java
I'm asking you for a help, does anyone have idea what I'm doing wrong?
Thanks,
Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Mike Edwards wrote:
> Jean-Sebastien Delfino wrote:
>>
>> I took a look at binding-corba/.../CorbaServiceBindingProvider in trunk.
>>
>> At the moment the ORB setup is in the start method of the provider
>> (and there's no cleanup in the stop method). I'm not quite sure how
>> this is going to work with multiple services sharing the same ORB.
>>
>> I'm thinking that we'll need the following to support multiple services:
>>
>> - A host-corba implementation (similar to host-ejb, host-rmi or
>> host-http) to setup/tear the ORB when the Tuscany runtime
>> starts/stops, independent of the registration of particular services
>> with the ORB.
>>
>> - Logic in that host-corba to set up the ORB in a lazy fashion when
>> the first Corba service is registered.
>>
>> - Only keep the ORB servant creation and naming bind/unbind in the
>> service provider class.
>>
>> Makes sense?
>
> This is a bit of a tangent but it is related - I think that the BPEL
> code has the same general requirement. The current ODE runtime must be
> brought up and torn down independent of any individual service
> component. Ideally this is done at the start and end of the node - it
> is a relatively expensive process.
>
> Thinking further, it is probably also true of the Spring runtime,
> although the expense there is low.
>
>
> Yours, Mike.
Yes, that makes sense to me.
--
Jean-Sebastien
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Mike Edwards <mi...@gmail.com>.
Jean-Sebastien Delfino wrote:
>
> I took a look at binding-corba/.../CorbaServiceBindingProvider in trunk.
>
> At the moment the ORB setup is in the start method of the provider (and
> there's no cleanup in the stop method). I'm not quite sure how this is
> going to work with multiple services sharing the same ORB.
>
> I'm thinking that we'll need the following to support multiple services:
>
> - A host-corba implementation (similar to host-ejb, host-rmi or
> host-http) to setup/tear the ORB when the Tuscany runtime starts/stops,
> independent of the registration of particular services with the ORB.
>
> - Logic in that host-corba to set up the ORB in a lazy fashion when the
> first Corba service is registered.
>
> - Only keep the ORB servant creation and naming bind/unbind in the
> service provider class.
>
> Makes sense?
This is a bit of a tangent but it is related - I think that the BPEL code has the same general
requirement. The current ODE runtime must be brought up and torn down independent of any individual
service component. Ideally this is done at the start and end of the node - it is a relatively
expensive process.
Thinking further, it is probably also true of the Spring runtime, although the expense there is low.
Yours, Mike.
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Wojtek Janiszewski wrote:
> Jean-Sebastien Delfino wrote:
>> I think it would be good to split binding-corba in two modules:
>>
>> - binding-corba for the model and SCDL read/write
>>
>> - binding-corba-runtime (or another suffix that makes what it is
>> obvious) for the runtime handling, service and reference provider code.
>>
>> This is the structure we now have for most other bindings allowing the
>> model to be used without dragging a dependency on setting up the
>> runtime support.
>>
>
> Hi,
> so I understand you'd like to have CorbaBinding, CorbaBindingImpl,
> CorbaBindingFactory, CorbaBindingFactoryImpl, CorbaBindingProcessor
> classes in binding-corba module, and remaining files (binding providers,
> invokers, etc.) in binding-corba-runtime.
Yes
If this is correct then I'll
> include those changes in further patches.
Great, Thanks :)
>
> Thanks,
> Wojtek
--
Jean-Sebastien
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Wojtek Janiszewski <wo...@gmail.com>.
Jean-Sebastien Delfino wrote:
> I think it would be good to split binding-corba in two modules:
>
> - binding-corba for the model and SCDL read/write
>
> - binding-corba-runtime (or another suffix that makes what it is
> obvious) for the runtime handling, service and reference provider code.
>
> This is the structure we now have for most other bindings allowing the
> model to be used without dragging a dependency on setting up the runtime
> support.
>
Hi,
so I understand you'd like to have CorbaBinding, CorbaBindingImpl,
CorbaBindingFactory, CorbaBindingFactoryImpl, CorbaBindingProcessor
classes in binding-corba module, and remaining files (binding providers,
invokers, etc.) in binding-corba-runtime. If this is correct then I'll
include those changes in further patches.
Thanks,
Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Wojtek Janiszewski wrote:
> Hi,
> I've gathered all current/past issues regarding project on wiki page:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/CORBA+reference+binding+features%2C+bugs%2C+issues
>
> Comments are always welcome.
>
> Thanks,
> Wojtek
>
I think it would be good to split binding-corba in two modules:
- binding-corba for the model and SCDL read/write
- binding-corba-runtime (or another suffix that makes what it is
obvious) for the runtime handling, service and reference provider code.
This is the structure we now have for most other bindings allowing the
model to be used without dragging a dependency on setting up the runtime
support.
--
Jean-Sebastien
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Wojtek Janiszewski <wo...@gmail.com>.
Ok, so I see that full path of exception class is mapped to the
retrieved exception id (with leading "IDL:" and following ":1.0"
strings, and optionally "Exception" substring removed). Then this is how
I'll do it.
Thanks,
Wojtek
Raymond Feng wrote:
> To map CORBA exceptions (object id) to java exceptions, we can follow
> the logic in org.apache.tuscany.sca.binding.ejb.util.EJBHandler.java:
>
> } catch (ApplicationException ex) {
> in = (InputStream)ex.getInputStream();
> try {
>
> org.apache.tuscany.sca.binding.ejb.corba.Java2IDLUtil.throwException(methodInfo.getMethod(),
> in);
> return null;
> } catch (Throwable e) {
> throw new RemoteException(e.getMessage(), e);
> }
> } catch (RemarshalException ex) {
> return invokeRemoteCORBACall(stub, methodName, args);
> } finally {
> stub._releaseReply(in);
> }
> } catch (SystemException ex) {
> throw Util.mapSystemException(ex);
> }
>
> Please note
> org.apache.tuscany.sca.binding.ejb.corba.Java2IDLUtil.throwException
> maps the object id to a declared java exception.
>
> Thanks,
> Raymond
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Raymond Feng <en...@gmail.com>.
To map CORBA exceptions (object id) to java exceptions, we can follow the
logic in org.apache.tuscany.sca.binding.ejb.util.EJBHandler.java:
} catch (ApplicationException ex) {
in = (InputStream)ex.getInputStream();
try {
org.apache.tuscany.sca.binding.ejb.corba.Java2IDLUtil.throwException(methodInfo.getMethod(),
in);
return null;
} catch (Throwable e) {
throw new RemoteException(e.getMessage(), e);
}
} catch (RemarshalException ex) {
return invokeRemoteCORBACall(stub, methodName, args);
} finally {
stub._releaseReply(in);
}
} catch (SystemException ex) {
throw Util.mapSystemException(ex);
}
Please note
org.apache.tuscany.sca.binding.ejb.corba.Java2IDLUtil.throwException maps
the object id to a declared java exception.
Thanks,
Raymond
--------------------------------------------------
From: "Wojtek Janiszewski" <wo...@gmail.com>
Sent: Sunday, June 08, 2008 6:50 PM
To: <tu...@ws.apache.org>
Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
> Hi,
> I've gathered all current/past issues regarding project on wiki page:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/CORBA+reference+binding+features%2C+bugs%2C+issues
> Comments are always welcome.
>
> Thanks,
> Wojtek
>
> Wojtek Janiszewski wrote:
>> Wojtek Janiszewski wrote:
>>> Simon Nash wrote:
>>>> One comment inline.
>>>>
>>>> Simon
>>>>>>> 6. If CORBA objects operation argument is object reference, then
>>>>>>> user should provide object which was previously obtained from
>>>>>>> binding or other CORBA object. User cannot use users-side object as
>>>>>>> an argument.
>>>>>>>
>>>>>>
>>>>>> Yes. Let's don't worry object reference too much at this point. We
>>>>>> are in the SOA world instead of distributed object :-).
>>>>>>
>>>> This is OK if we are exposing a SCA service via CORBA. If we are using
>>>> SCA to invoke existing CORBA services that expect object references
>>>> to be passed, we will need to come up with an approach for handling
>>>> them.
>>>>
>>>> I'd suggest that we start first with exposing SCA services via CORBA
>>>> as this seems to be the simplest and most useful form of integration.
>>>
>>> Unfortunately I started earlier with reference bindings - even submitted
>>> a patch today.
>>>
>>> My thoughts for object references are that after obtaining some remote
>>> reference, it will be enhanced by cglib and connected to users declared
>>> interface. By enhancing I mean interception of methods invocations and
>>> adding dynamic CORBA invocations. Such enhanced object could be
>>> recognizable by dynamic invocation mechanism, and it could be passed
>>> while invoking operations on remote objects.
>>>
>>> In this solution we would have two types of CORBA objects - ones that
>>> were intentionally declared, and ones that were obtained from roots, and
>>> which are transparent. It's maybe kind of out of control by Tuscany
>>> runtime, but is there any other way to obtain and use CORBA references
>>> which are not registered in name services?
>>>
>>> Thanks,
>>> Wojtek
>>>
>>
>> Hi,
>> I recently submitted some code, which helps invoking remote objects.
>> Mechanism for invoking remote CORBA objects is determining operation
>> arguments types by Java types and I'm not sure that Java to CORBA mapping
>> model I proposed is OK.
>>
>> There is quite nice description of Java to CORBA mapping under [1]. It
>> shows how idlj compiler creates Java structure basing on idl file and I
>> believe we shouldn't precisely follow those rules and try to make them as
>> simple as possible. Am I right?
>>
>> 1. Structures
>> I proposed that CORBA structures will be Java classes, with public fields
>> and no get/set methods. So every class field is member for CORBA
>> structure. Or maybe we should map JavaBean classes to CORBA structures?
>>
>> 2. Sequences and arrays
>> Sequences and arrays can be mapped to Java by arrays or lists.
>> Unfortunately both CORBA types behaves bit different, additionally CORBA
>> arrays have fixed length so there should be possibility to distinguish
>> those types somehow. For now on I cannot find any other solution, but
>> annotating arrays with it's target length. Any opinions?
>>
>> 3. Arguments with inout/out modifiers
>> In CORBA, operation argument value can be changed. As we know Java
>> supports passing arguments by values only, so update on argument is not
>> possible. Such was solved in Java by wrapping arguments in holder
>> classes, ie:
>>
>> public class IntHolder {
>> public int value;
>> }
>>
>> This means if user wants to get his argument updated he needs to create
>> argument in holder class, which could be tough (maybe there are low-level
>> techniques which allows to manipulate such arguments?).
>>
>> I know I should provide some method to recognize if users class is holder
>> for inout/out argument:
>> a. annotation
>> b. by implementing interface, ie:
>>
>> public interface Holder {
>> void setValue(Object value);
>> Object getValue();
>> }
>>
>> Or maybe there is some other solution? Which one should I choose?
>>
>> I'll appreciate any comments. Just ask if you need more details.
>>
>> [1] - http://members.tripod.com/gsraj/corba/chapter/
>>
>> Thanks,
>> Wojtek
>>
>
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Wojtek Janiszewski <wo...@gmail.com>.
Hi,
I've gathered all current/past issues regarding project on wiki page:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/CORBA+reference+binding+features%2C+bugs%2C+issues
Comments are always welcome.
Thanks,
Wojtek
Wojtek Janiszewski wrote:
> Wojtek Janiszewski wrote:
>> Simon Nash wrote:
>>> One comment inline.
>>>
>>> Simon
>>>>>> 6. If CORBA objects operation argument is object reference, then
>>>>>> user should provide object which was previously obtained from
>>>>>> binding or other CORBA object. User cannot use users-side object
>>>>>> as an argument.
>>>>>>
>>>>>
>>>>> Yes. Let's don't worry object reference too much at this point. We
>>>>> are in the SOA world instead of distributed object :-).
>>>>>
>>> This is OK if we are exposing a SCA service via CORBA. If we are using
>>> SCA to invoke existing CORBA services that expect object references
>>> to be passed, we will need to come up with an approach for handling
>>> them.
>>>
>>> I'd suggest that we start first with exposing SCA services via CORBA
>>> as this seems to be the simplest and most useful form of integration.
>>
>> Unfortunately I started earlier with reference bindings - even
>> submitted a patch today.
>>
>> My thoughts for object references are that after obtaining some remote
>> reference, it will be enhanced by cglib and connected to users
>> declared interface. By enhancing I mean interception of methods
>> invocations and adding dynamic CORBA invocations. Such enhanced object
>> could be recognizable by dynamic invocation mechanism, and it could be
>> passed while invoking operations on remote objects.
>>
>> In this solution we would have two types of CORBA objects - ones that
>> were intentionally declared, and ones that were obtained from roots,
>> and which are transparent. It's maybe kind of out of control by
>> Tuscany runtime, but is there any other way to obtain and use CORBA
>> references which are not registered in name services?
>>
>> Thanks,
>> Wojtek
>>
>
> Hi,
> I recently submitted some code, which helps invoking remote objects.
> Mechanism for invoking remote CORBA objects is determining operation
> arguments types by Java types and I'm not sure that Java to CORBA
> mapping model I proposed is OK.
>
> There is quite nice description of Java to CORBA mapping under [1]. It
> shows how idlj compiler creates Java structure basing on idl file and I
> believe we shouldn't precisely follow those rules and try to make them
> as simple as possible. Am I right?
>
> 1. Structures
> I proposed that CORBA structures will be Java classes, with public
> fields and no get/set methods. So every class field is member for CORBA
> structure. Or maybe we should map JavaBean classes to CORBA structures?
>
> 2. Sequences and arrays
> Sequences and arrays can be mapped to Java by arrays or lists.
> Unfortunately both CORBA types behaves bit different, additionally CORBA
> arrays have fixed length so there should be possibility to distinguish
> those types somehow. For now on I cannot find any other solution, but
> annotating arrays with it's target length. Any opinions?
>
> 3. Arguments with inout/out modifiers
> In CORBA, operation argument value can be changed. As we know Java
> supports passing arguments by values only, so update on argument is not
> possible. Such was solved in Java by wrapping arguments in holder
> classes, ie:
>
> public class IntHolder {
> public int value;
> }
>
> This means if user wants to get his argument updated he needs to create
> argument in holder class, which could be tough (maybe there are
> low-level techniques which allows to manipulate such arguments?).
>
> I know I should provide some method to recognize if users class is
> holder for inout/out argument:
> a. annotation
> b. by implementing interface, ie:
>
> public interface Holder {
> void setValue(Object value);
> Object getValue();
> }
>
> Or maybe there is some other solution? Which one should I choose?
>
> I'll appreciate any comments. Just ask if you need more details.
>
> [1] - http://members.tripod.com/gsraj/corba/chapter/
>
> Thanks,
> Wojtek
>
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Wojtek Janiszewski" <wo...@gmail.com>
Sent: Thursday, June 12, 2008 2:39 AM
To: <tu...@ws.apache.org>
Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
> Hi, Raymond.
> Please take a look at my comments inline.
> Thanks, Wojtek
>
> Raymond Feng wrote:
>> Hi, Wojtek.
>>
>> Please see my comments inline.
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "Wojtek Janiszewski" <wo...@gmail.com>
>> Sent: Wednesday, June 11, 2008 11:55 AM
>> To: <tu...@ws.apache.org>
>> Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
>>>
>>> Example 1.
>>> Java interface for TestObject implements TestObjectOperations,
>>> org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity. This means that
>>> user should define this interface using CORBA API types. This is what
>>> you mean?
>>
>> To access an existing CORBA service with general_tests.idl, I should be
>> able to use "TestObject" interface generated from the IDL in my SCA
>> reference with binding.corba. The CORBA reference binding invoker should
>> be able to marshal/marshal the data from the interface.
>
> What's the use case for reference binding using Java interface? Is it
> a) user generates classes from IDL file and uses them in binding
> configuration
> b) user creates classes basing on IDL file (without extending or
> implementing any types from CORBA API) and uses them in binding
> configuration
>
> I was following case b) from the beginning. Now I'm little confused.
I think we should support both cases. For case b), the java types have to be
mappable to IDL types based on the Java IDL mapping spec.
>
>>
>> Another case is that Java2IDL compliant java interface (for example, the
>> remote interfaces for EJB). We already have support in the binding.ejb
>> module.
>>
>>>
>>> Example 2.
>>> Operation:
>>> SomeStruct setStruct(inout SomeStruct arg)
>>> for interface TestObject uses SomeStructHolder (for passing INOUT
>>> argument) which implements
>>> org.omg.CORBA.portable.Streamable. SomeStructHolder contains SomeStruct
>>> as a structure representation. Again, SomeStruct uses CORBA API
>>> interface - it implements org.omg.CORBA.portable.IDLEntity. In this case
>>> SomeStruct was meant to be INOUT argument, so it uses
>>> SomeStructHolder. If SomeStruct would be declared as OUT, then again
>>> SomeStructHolder would be used, but little different application logic
>>> would be used - argument wouldn't be sent, but only retrieved after
>>> operation invocation (this remaining logic is generated in stubs
>>> and skeletons - so it's outside generated interface). This means, that
>>> user using holders the same way as in the generated style cannot tell
>>> to the binding reference whether the modifier is INOUT or OUT.
>>> This is one example of some real constraints which blocks using Java
>>> interface hierarchy the same way as generated from idlj compiler.
>>>
>>
>> OK. My understanding is that the generated java interface doesn't catch
>> all the information from the IDL because some of them are in the
>> generated stubs/skeletons. We probably need to decide what's the best
>> default here. For example, for the Holder type, we will default to INOUT.
>>
>> Another perspective is that for SCA remotable interfaces, the data
>> exchange semantics is pass-by-value. In the case that
>> @AllowsPassByReference is used, it only means the data is safe to pass by
>> reference and it does NOT mandate pass-by-reference. So we can perfectly
>> argue that the binding.corba doesn't support the INOUT and OUT arguments.
>>
>
> So I understand for both reference and service bindings we won't support
> INOUT/OUT modifiers.
>
I think it's reasonable if we cannot find a good way. At least supporting
INOUT/OUT parameters is a second priority.
> There is similar problem with CORBA arrays and CORBA sequences - Java
> types for them are both arrays, and additional logic is generated in
> stubs/skeletons (in arrays we only send fixed length array, in sequences
> we additionally send length of sequence first). Should we also make some
> default here? If so, then sequences looks more useful.
We might be able to consider the additional metadata to describe the java
type for CORBA as part of the databinding framework. We'll introduce the
annotation if it is inevitable.
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Wojtek Janiszewski <wo...@gmail.com>.
Hi, Raymond.
Please take a look at my comments inline.
Thanks, Wojtek
Raymond Feng wrote:
> Hi, Wojtek.
>
> Please see my comments inline.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Wojtek Janiszewski" <wo...@gmail.com>
> Sent: Wednesday, June 11, 2008 11:55 AM
> To: <tu...@ws.apache.org>
> Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
>>
>> Example 1.
>> Java interface for TestObject implements TestObjectOperations,
>> org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity. This means that
>> user should define this interface using CORBA API types. This is what
>> you mean?
>
> To access an existing CORBA service with general_tests.idl, I should be
> able to use "TestObject" interface generated from the IDL in my SCA
> reference with binding.corba. The CORBA reference binding invoker should
> be able to marshal/marshal the data from the interface.
What's the use case for reference binding using Java interface? Is it
a) user generates classes from IDL file and uses them in binding
configuration
b) user creates classes basing on IDL file (without extending or
implementing any types from CORBA API) and uses them in binding
configuration
I was following case b) from the beginning. Now I'm little confused.
>
> Another case is that Java2IDL compliant java interface (for example, the
> remote interfaces for EJB). We already have support in the binding.ejb
> module.
>
>>
>> Example 2.
>> Operation:
>> SomeStruct setStruct(inout SomeStruct arg)
>> for interface TestObject uses SomeStructHolder (for passing INOUT
>> argument) which implements
>> org.omg.CORBA.portable.Streamable. SomeStructHolder contains
>> SomeStruct as a structure representation. Again, SomeStruct uses CORBA
>> API interface - it implements org.omg.CORBA.portable.IDLEntity. In
>> this case SomeStruct was meant to be INOUT argument, so it uses
>> SomeStructHolder. If SomeStruct would be declared as OUT, then again
>> SomeStructHolder would be used, but little different application logic
>> would be used - argument wouldn't be sent, but only retrieved after
>> operation invocation (this remaining logic is generated in stubs
>> and skeletons - so it's outside generated interface). This means, that
>> user using holders the same way as in the generated style cannot tell
>> to the binding reference whether the modifier is INOUT or OUT.
>> This is one example of some real constraints which blocks using Java
>> interface hierarchy the same way as generated from idlj compiler.
>>
>
> OK. My understanding is that the generated java interface doesn't catch
> all the information from the IDL because some of them are in the
> generated stubs/skeletons. We probably need to decide what's the best
> default here. For example, for the Holder type, we will default to INOUT.
>
> Another perspective is that for SCA remotable interfaces, the data
> exchange semantics is pass-by-value. In the case that
> @AllowsPassByReference is used, it only means the data is safe to pass
> by reference and it does NOT mandate pass-by-reference. So we can
> perfectly argue that the binding.corba doesn't support the INOUT and OUT
> arguments.
>
So I understand for both reference and service bindings we won't support
INOUT/OUT modifiers.
There is similar problem with CORBA arrays and CORBA sequences - Java
types for them are both arrays, and additional logic is generated in
stubs/skeletons (in arrays we only send fixed length array, in sequences
we additionally send length of sequence first). Should we also make some
default here? If so, then sequences looks more useful.
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Raymond Feng <en...@gmail.com>.
Hi, Wojtek.
Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Wojtek Janiszewski" <wo...@gmail.com>
Sent: Wednesday, June 11, 2008 11:55 AM
To: <tu...@ws.apache.org>
Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
> Hi,
> I understand you mean to look at generated classes to determine
> Java/CORBA mapping. I followed case A, using existing IDL file:
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-corba/src/test/resources/general_tests.idl
> and focused on interface TestObject. Generated classes are in:
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-corba/src/test/java/org/apache/tuscany/sca/binding/corba/testing/generated/
>
> Example 1.
> Java interface for TestObject implements TestObjectOperations,
> org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity. This means that
> user should define this interface using CORBA API types. This is what
> you mean?
To access an existing CORBA service with general_tests.idl, I should be able
to use "TestObject" interface generated from the IDL in my SCA reference
with binding.corba. The CORBA reference binding invoker should be able to
marshal/marshal the data from the interface.
Another case is that Java2IDL compliant java interface (for example, the
remote interfaces for EJB). We already have support in the binding.ejb
module.
>
> Example 2.
> Operation:
> SomeStruct setStruct(inout SomeStruct arg)
> for interface TestObject uses SomeStructHolder (for passing INOUT
> argument) which implements
> org.omg.CORBA.portable.Streamable. SomeStructHolder contains SomeStruct as
> a structure representation. Again, SomeStruct uses CORBA API interface -
> it implements org.omg.CORBA.portable.IDLEntity. In this case SomeStruct
> was meant to be INOUT argument, so it uses
> SomeStructHolder. If SomeStruct would be declared as OUT, then again
> SomeStructHolder would be used, but little different application logic
> would be used - argument wouldn't be sent, but only retrieved after
> operation invocation (this remaining logic is generated in stubs
> and skeletons - so it's outside generated interface). This means, that
> user using holders the same way as in the generated style cannot tell
> to the binding reference whether the modifier is INOUT or OUT.
> This is one example of some real constraints which blocks using Java
> interface hierarchy the same way as generated from idlj compiler.
>
OK. My understanding is that the generated java interface doesn't catch all
the information from the IDL because some of them are in the generated
stubs/skeletons. We probably need to decide what's the best default here.
For example, for the Holder type, we will default to INOUT.
Another perspective is that for SCA remotable interfaces, the data exchange
semantics is pass-by-value. In the case that @AllowsPassByReference is used,
it only means the data is safe to pass by reference and it does NOT mandate
pass-by-reference. So we can perfectly argue that the binding.corba doesn't
support the INOUT and OUT arguments.
> Thanks,
> Wojtek
>
> Raymond Feng wrote:
>> Hi,
>>
>> There are two specifications in these areas.
>>
>> 1) Java2IDL: http://www.omg.org/docs/formal/08-01-14.pdf
>> 2) IDL2Java: http://www.omg.org/docs/formal/08-01-11.pdf
>>
>> Let's try to use a few scenarios to help us understand what rules should
>> be applied.
>>
>> Case A: There is an existing CORBA service (Java or C++) with IDL. Now we
>> want to consume it using SCA.
>>
>> Here is what I would do:
>> a) Run idl2java to generate a java interface (ignoring other stubs and
>> skeletons) from the IDL.
>> b) Declare a SCA reference with binding.corba and set the interface to
>> the one generated from a)
>> c) The Tuscany corba invoker should be able to create a request stream
>> for input args and parse the response to get the return value.
>>
>> The corba invoker needs to find the corba operation name from the java
>> method and know how to marshal/unmarshal the parameters/return value.
>>
>> Case B: We have a SCA component and we want to expose it as a CORBA
>> service.
>>
>> The corba service binding listener will have to unpack/pack data from the
>> ServerRequest. Let's assume the component service interface is defined in
>> java, then we need to follow the Java2IDL spec so that we handle the java
>> parameters/return value following the CORBA IDL rules.
>>
>> Ideally, the exposed CORBA service would behave as it has an IDL
>> generated from "rmic -idl <java_interface>".
>>
>> Thanks,
>> Raymond
>>
>> [snip]
>>>
>>> Hi,
>>> I recently submitted some code, which helps invoking remote objects.
>>> Mechanism for invoking remote CORBA objects is determining operation
>>> arguments types by Java types and I'm not sure that Java to CORBA
>>> mapping model I proposed is OK.
>>>
>>> There is quite nice description of Java to CORBA mapping under [1]. It
>>> shows how idlj compiler creates Java structure basing on idl file and I
>>> believe we shouldn't precisely follow those rules and try to make them
>>> as simple as possible. Am I right?
>>>
>>> 1. Structures
>>> I proposed that CORBA structures will be Java classes, with public
>>> fields and no get/set methods. So every class field is member for CORBA
>>> structure. Or maybe we should map JavaBean classes to CORBA structures?
>>>
>>> 2. Sequences and arrays
>>> Sequences and arrays can be mapped to Java by arrays or lists.
>>> Unfortunately both CORBA types behaves bit different, additionally CORBA
>>> arrays have fixed length so there should be possibility to distinguish
>>> those types somehow. For now on I cannot find any other solution, but
>>> annotating arrays with it's target length. Any opinions?
>>>
>>> 3. Arguments with inout/out modifiers
>>> In CORBA, operation argument value can be changed. As we know Java
>>> supports passing arguments by values only, so update on argument is not
>>> possible. Such was solved in Java by wrapping arguments in holder
>>> classes, ie:
>>>
>>> public class IntHolder {
>>> public int value;
>>> }
>>>
>>> This means if user wants to get his argument updated he needs to create
>>> argument in holder class, which could be tough (maybe there are
>>> low-level techniques which allows to manipulate such arguments?).
>>>
>>> I know I should provide some method to recognize if users class is
>>> holder for inout/out argument:
>>> a. annotation
>>> b. by implementing interface, ie:
>>>
>>> public interface Holder {
>>> void setValue(Object value);
>>> Object getValue();
>>> }
>>>
>>> Or maybe there is some other solution? Which one should I choose?
>>>
>>> I'll appreciate any comments. Just ask if you need more details.
>>>
>>> [1] - http://members.tripod.com/gsraj/corba/chapter/
>>>
>>> Thanks,
>>> Wojtek
>
>
>
>
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Wojtek Janiszewski <wo...@gmail.com>.
Hi,
I understand you mean to look at generated classes to determine
Java/CORBA mapping. I followed case A, using existing IDL file:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-corba/src/test/resources/general_tests.idl
and focused on interface TestObject. Generated classes are in:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-corba/src/test/java/org/apache/tuscany/sca/binding/corba/testing/generated/
Example 1.
Java interface for TestObject implements TestObjectOperations,
org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity. This means that
user should define this interface using CORBA API types. This is what
you mean?
Example 2.
Operation:
SomeStruct setStruct(inout SomeStruct arg)
for interface TestObject uses SomeStructHolder (for passing INOUT
argument) which implements
org.omg.CORBA.portable.Streamable. SomeStructHolder contains SomeStruct
as a structure representation. Again, SomeStruct uses CORBA API
interface - it implements org.omg.CORBA.portable.IDLEntity. In this case
SomeStruct was meant to be INOUT argument, so it uses
SomeStructHolder. If SomeStruct would be declared as OUT, then again
SomeStructHolder would be used, but little different application logic
would be used - argument wouldn't be sent, but only retrieved after
operation invocation (this remaining logic is generated in stubs
and skeletons - so it's outside generated interface). This means, that
user using holders the same way as in the generated style cannot tell
to the binding reference whether the modifier is INOUT or OUT.
This is one example of some real constraints which blocks using Java
interface hierarchy the same way as generated from idlj compiler.
Thanks,
Wojtek
Raymond Feng wrote:
> Hi,
>
> There are two specifications in these areas.
>
> 1) Java2IDL: http://www.omg.org/docs/formal/08-01-14.pdf
> 2) IDL2Java: http://www.omg.org/docs/formal/08-01-11.pdf
>
> Let's try to use a few scenarios to help us understand what rules should
> be applied.
>
> Case A: There is an existing CORBA service (Java or C++) with IDL. Now
> we want to consume it using SCA.
>
> Here is what I would do:
> a) Run idl2java to generate a java interface (ignoring other stubs and
> skeletons) from the IDL.
> b) Declare a SCA reference with binding.corba and set the interface to
> the one generated from a)
> c) The Tuscany corba invoker should be able to create a request stream
> for input args and parse the response to get the return value.
>
> The corba invoker needs to find the corba operation name from the java
> method and know how to marshal/unmarshal the parameters/return value.
>
> Case B: We have a SCA component and we want to expose it as a CORBA
> service.
>
> The corba service binding listener will have to unpack/pack data from
> the ServerRequest. Let's assume the component service interface is
> defined in java, then we need to follow the Java2IDL spec so that we
> handle the java parameters/return value following the CORBA IDL rules.
>
> Ideally, the exposed CORBA service would behave as it has an IDL
> generated from "rmic -idl <java_interface>".
>
> Thanks,
> Raymond
>
> [snip]
>>
>> Hi,
>> I recently submitted some code, which helps invoking remote objects.
>> Mechanism for invoking remote CORBA objects is determining operation
>> arguments types by Java types and I'm not sure that Java to CORBA
>> mapping model I proposed is OK.
>>
>> There is quite nice description of Java to CORBA mapping under [1]. It
>> shows how idlj compiler creates Java structure basing on idl file and
>> I believe we shouldn't precisely follow those rules and try to make
>> them as simple as possible. Am I right?
>>
>> 1. Structures
>> I proposed that CORBA structures will be Java classes, with public
>> fields and no get/set methods. So every class field is member for
>> CORBA structure. Or maybe we should map JavaBean classes to CORBA
>> structures?
>>
>> 2. Sequences and arrays
>> Sequences and arrays can be mapped to Java by arrays or lists.
>> Unfortunately both CORBA types behaves bit different, additionally
>> CORBA arrays have fixed length so there should be possibility to
>> distinguish those types somehow. For now on I cannot find any other
>> solution, but annotating arrays with it's target length. Any opinions?
>>
>> 3. Arguments with inout/out modifiers
>> In CORBA, operation argument value can be changed. As we know Java
>> supports passing arguments by values only, so update on argument is
>> not possible. Such was solved in Java by wrapping arguments in holder
>> classes, ie:
>>
>> public class IntHolder {
>> public int value;
>> }
>>
>> This means if user wants to get his argument updated he needs to
>> create argument in holder class, which could be tough (maybe there are
>> low-level techniques which allows to manipulate such arguments?).
>>
>> I know I should provide some method to recognize if users class is
>> holder for inout/out argument:
>> a. annotation
>> b. by implementing interface, ie:
>>
>> public interface Holder {
>> void setValue(Object value);
>> Object getValue();
>> }
>>
>> Or maybe there is some other solution? Which one should I choose?
>>
>> I'll appreciate any comments. Just ask if you need more details.
>>
>> [1] - http://members.tripod.com/gsraj/corba/chapter/
>>
>> Thanks,
>> Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Raymond Feng <en...@gmail.com>.
Hi,
There are two specifications in these areas.
1) Java2IDL: http://www.omg.org/docs/formal/08-01-14.pdf
2) IDL2Java: http://www.omg.org/docs/formal/08-01-11.pdf
Let's try to use a few scenarios to help us understand what rules should be
applied.
Case A: There is an existing CORBA service (Java or C++) with IDL. Now we
want to consume it using SCA.
Here is what I would do:
a) Run idl2java to generate a java interface (ignoring other stubs and
skeletons) from the IDL.
b) Declare a SCA reference with binding.corba and set the interface to the
one generated from a)
c) The Tuscany corba invoker should be able to create a request stream for
input args and parse the response to get the return value.
The corba invoker needs to find the corba operation name from the java
method and know how to marshal/unmarshal the parameters/return value.
Case B: We have a SCA component and we want to expose it as a CORBA service.
The corba service binding listener will have to unpack/pack data from the
ServerRequest. Let's assume the component service interface is defined in
java, then we need to follow the Java2IDL spec so that we handle the java
parameters/return value following the CORBA IDL rules.
Ideally, the exposed CORBA service would behave as it has an IDL generated
from "rmic -idl <java_interface>".
Thanks,
Raymond
[snip]
>
> Hi,
> I recently submitted some code, which helps invoking remote objects.
> Mechanism for invoking remote CORBA objects is determining operation
> arguments types by Java types and I'm not sure that Java to CORBA mapping
> model I proposed is OK.
>
> There is quite nice description of Java to CORBA mapping under [1]. It
> shows how idlj compiler creates Java structure basing on idl file and I
> believe we shouldn't precisely follow those rules and try to make them as
> simple as possible. Am I right?
>
> 1. Structures
> I proposed that CORBA structures will be Java classes, with public fields
> and no get/set methods. So every class field is member for CORBA
> structure. Or maybe we should map JavaBean classes to CORBA structures?
>
> 2. Sequences and arrays
> Sequences and arrays can be mapped to Java by arrays or lists.
> Unfortunately both CORBA types behaves bit different, additionally CORBA
> arrays have fixed length so there should be possibility to distinguish
> those types somehow. For now on I cannot find any other solution, but
> annotating arrays with it's target length. Any opinions?
>
> 3. Arguments with inout/out modifiers
> In CORBA, operation argument value can be changed. As we know Java
> supports passing arguments by values only, so update on argument is not
> possible. Such was solved in Java by wrapping arguments in holder classes,
> ie:
>
> public class IntHolder {
> public int value;
> }
>
> This means if user wants to get his argument updated he needs to create
> argument in holder class, which could be tough (maybe there are low-level
> techniques which allows to manipulate such arguments?).
>
> I know I should provide some method to recognize if users class is holder
> for inout/out argument:
> a. annotation
> b. by implementing interface, ie:
>
> public interface Holder {
> void setValue(Object value);
> Object getValue();
> }
>
> Or maybe there is some other solution? Which one should I choose?
>
> I'll appreciate any comments. Just ask if you need more details.
>
> [1] - http://members.tripod.com/gsraj/corba/chapter/
>
> Thanks,
> Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Wojtek Janiszewski <wo...@gmail.com>.
Wojtek Janiszewski wrote:
> Simon Nash wrote:
>> One comment inline.
>>
>> Simon
>>>>> 6. If CORBA objects operation argument is object reference, then
>>>>> user should provide object which was previously obtained from
>>>>> binding or other CORBA object. User cannot use users-side object as
>>>>> an argument.
>>>>>
>>>>
>>>> Yes. Let's don't worry object reference too much at this point. We
>>>> are in the SOA world instead of distributed object :-).
>>>>
>> This is OK if we are exposing a SCA service via CORBA. If we are using
>> SCA to invoke existing CORBA services that expect object references
>> to be passed, we will need to come up with an approach for handling them.
>>
>> I'd suggest that we start first with exposing SCA services via CORBA
>> as this seems to be the simplest and most useful form of integration.
>
> Unfortunately I started earlier with reference bindings - even submitted
> a patch today.
>
> My thoughts for object references are that after obtaining some remote
> reference, it will be enhanced by cglib and connected to users declared
> interface. By enhancing I mean interception of methods invocations and
> adding dynamic CORBA invocations. Such enhanced object could be
> recognizable by dynamic invocation mechanism, and it could be passed
> while invoking operations on remote objects.
>
> In this solution we would have two types of CORBA objects - ones that
> were intentionally declared, and ones that were obtained from roots, and
> which are transparent. It's maybe kind of out of control by Tuscany
> runtime, but is there any other way to obtain and use CORBA references
> which are not registered in name services?
>
> Thanks,
> Wojtek
>
Hi,
I recently submitted some code, which helps invoking remote objects.
Mechanism for invoking remote CORBA objects is determining operation
arguments types by Java types and I'm not sure that Java to CORBA
mapping model I proposed is OK.
There is quite nice description of Java to CORBA mapping under [1]. It
shows how idlj compiler creates Java structure basing on idl file and I
believe we shouldn't precisely follow those rules and try to make them
as simple as possible. Am I right?
1. Structures
I proposed that CORBA structures will be Java classes, with public
fields and no get/set methods. So every class field is member for CORBA
structure. Or maybe we should map JavaBean classes to CORBA structures?
2. Sequences and arrays
Sequences and arrays can be mapped to Java by arrays or lists.
Unfortunately both CORBA types behaves bit different, additionally CORBA
arrays have fixed length so there should be possibility to distinguish
those types somehow. For now on I cannot find any other solution, but
annotating arrays with it's target length. Any opinions?
3. Arguments with inout/out modifiers
In CORBA, operation argument value can be changed. As we know Java
supports passing arguments by values only, so update on argument is not
possible. Such was solved in Java by wrapping arguments in holder
classes, ie:
public class IntHolder {
public int value;
}
This means if user wants to get his argument updated he needs to create
argument in holder class, which could be tough (maybe there are
low-level techniques which allows to manipulate such arguments?).
I know I should provide some method to recognize if users class is
holder for inout/out argument:
a. annotation
b. by implementing interface, ie:
public interface Holder {
void setValue(Object value);
Object getValue();
}
Or maybe there is some other solution? Which one should I choose?
I'll appreciate any comments. Just ask if you need more details.
[1] - http://members.tripod.com/gsraj/corba/chapter/
Thanks,
Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Wojtek Janiszewski <wo...@gmail.com>.
Simon Nash wrote:
> One comment inline.
>
> Simon
>>>> 6. If CORBA objects operation argument is object reference, then
>>>> user should provide object which was previously obtained from
>>>> binding or other CORBA object. User cannot use users-side object as
>>>> an argument.
>>>>
>>>
>>> Yes. Let's don't worry object reference too much at this point. We
>>> are in the SOA world instead of distributed object :-).
>>>
> This is OK if we are exposing a SCA service via CORBA. If we are using
> SCA to invoke existing CORBA services that expect object references
> to be passed, we will need to come up with an approach for handling them.
>
> I'd suggest that we start first with exposing SCA services via CORBA
> as this seems to be the simplest and most useful form of integration.
Unfortunately I started earlier with reference bindings - even submitted
a patch today.
My thoughts for object references are that after obtaining some remote
reference, it will be enhanced by cglib and connected to users declared
interface. By enhancing I mean interception of methods invocations and
adding dynamic CORBA invocations. Such enhanced object could be
recognizable by dynamic invocation mechanism, and it could be passed
while invoking operations on remote objects.
In this solution we would have two types of CORBA objects - ones that
were intentionally declared, and ones that were obtained from roots, and
which are transparent. It's maybe kind of out of control by Tuscany
runtime, but is there any other way to obtain and use CORBA references
which are not registered in name services?
Thanks,
Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Simon Nash <na...@apache.org>.
One comment inline.
Simon
Jean-Sebastien Delfino wrote:
> Raymond Feng wrote:
>> Please see my comments inline.
>>
>> Thanks,
>> Raymond
>>
>> --------------------------------------------------
>> From: "Wojtek Janiszewski" <wo...@gmail.com>
>> Sent: Thursday, May 22, 2008 3:21 AM
>> To: <tu...@ws.apache.org>
>> Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
>>
>>> Hello Tuscany Community!
>>>
>>> I've spent last days considering project details and made some
>>> prototypes which were mainly verifying CORBA API in JDK. I'd like
>>> also to begin coding shortly - I'd like to start implementing
>>> reference binding implementation for CORBA objects. I've listed some
>>> assumptions/doubts:
>>>
>>> 1. Original time schedule was to start work with "Implementation of
>>> interface-corba-idl module.". I was told to start with CORBA
>>> bindings, I just wanted to make sure that these modules
>>> implementation schedule can be swapped.
>>
>> I think the CORA IDL support can be a 2nd step. We can invoke/expose
>> CORBA services using java interfaces.
>>
>>>
>>> 2. I'll implement service/reference bindings using CORBA Dynamic
>>> Invocation Interface (DII) API. Standard JDK CORBA support *should*
>>> be enough, if no, there are other CORBA implementations, such as JacORB.
>>
>> Standard JDK APIs should be good enough. There is an Apache CORBA
>> project at: http://cwiki.apache.org/YOKO/.
>>
>>>
>>> 3. Where should parameters ORBInitialHost and ORBInitialPort be
>>> passed to application? They shouldn't be configured global for
>>> application, because every binding can use different ORB, so I assume
>>> it should be configured per binding. Which attributes for
>>> binding.corba shall I use?
>>
>> They should be configured at the <binding.corba>.
>>
>>>
>>> 4. In CORBA we can register objects under unique name, or obtain
>>> remote objects as references from other CORBA objects. In binding
>>> configuration user should point remote objects name, which is
>>> registered in name service. Again, I think it should be configured
>>> per binding, so which attribute for binding.corba shall I use?
>>
>> That should be derived from the URI of the binding.
>>
>>>
>>> 5. CORBA objects obtained from binding will be dynamically enhanced
>>> by, lets call it, DII Corba Invoker (DCI), and attached to matching
>>> Java interface, so Tuscany user can use it. DCI will be responsible
>>> for creating request, based on operation name, operation arguments
>>> and return type. Every other CORBA object, obtained in any way (from
>>> binding, as a result of any other CORBA objects operation) will be
>>> also enhanced/attached as above.
>>
>> Yes. The corba reference binding invoker is responsible to bridge the
>> invocations between SCA and CORBA.
>>
>>>
>>> 6. If CORBA objects operation argument is object reference, then user
>>> should provide object which was previously obtained from binding or
>>> other CORBA object. User cannot use users-side object as an argument.
>>>
>>
>> Yes. Let's don't worry object reference too much at this point. We are
>> in the SOA world instead of distributed object :-).
>>
This is OK if we are exposing a SCA service via CORBA. If we are using
SCA to invoke existing CORBA services that expect object references
to be passed, we will need to come up with an approach for handling them.
I'd suggest that we start first with exposing SCA services via CORBA
as this seems to be the simplest and most useful form of integration.
Simon
>>> I hope I described my thoughts clearly, I'll appreciate any comments,
>>> especially pointing out things I'm wrong or missing.
>>>
>>> Thanks,
>>> Wojtek
>>
>
> I took a look at binding-corba/.../CorbaServiceBindingProvider in trunk.
>
> At the moment the ORB setup is in the start method of the provider (and
> there's no cleanup in the stop method). I'm not quite sure how this is
> going to work with multiple services sharing the same ORB.
>
> I'm thinking that we'll need the following to support multiple services:
>
> - A host-corba implementation (similar to host-ejb, host-rmi or
> host-http) to setup/tear the ORB when the Tuscany runtime starts/stops,
> independent of the registration of particular services with the ORB.
>
> - Logic in that host-corba to set up the ORB in a lazy fashion when the
> first Corba service is registered.
>
> - Only keep the ORB servant creation and naming bind/unbind in the
> service provider class.
>
> Makes sense?
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Please see my comments inline.
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Wojtek Janiszewski" <wo...@gmail.com>
> Sent: Thursday, May 22, 2008 3:21 AM
> To: <tu...@ws.apache.org>
> Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
>
>> Hello Tuscany Community!
>>
>> I've spent last days considering project details and made some
>> prototypes which were mainly verifying CORBA API in JDK. I'd like also
>> to begin coding shortly - I'd like to start implementing reference
>> binding implementation for CORBA objects. I've listed some
>> assumptions/doubts:
>>
>> 1. Original time schedule was to start work with "Implementation of
>> interface-corba-idl module.". I was told to start with CORBA bindings,
>> I just wanted to make sure that these modules implementation schedule
>> can be swapped.
>
> I think the CORA IDL support can be a 2nd step. We can invoke/expose
> CORBA services using java interfaces.
>
>>
>> 2. I'll implement service/reference bindings using CORBA Dynamic
>> Invocation Interface (DII) API. Standard JDK CORBA support *should* be
>> enough, if no, there are other CORBA implementations, such as JacORB.
>
> Standard JDK APIs should be good enough. There is an Apache CORBA
> project at: http://cwiki.apache.org/YOKO/.
>
>>
>> 3. Where should parameters ORBInitialHost and ORBInitialPort be passed
>> to application? They shouldn't be configured global for application,
>> because every binding can use different ORB, so I assume it should be
>> configured per binding. Which attributes for binding.corba shall I use?
>
> They should be configured at the <binding.corba>.
>
>>
>> 4. In CORBA we can register objects under unique name, or obtain
>> remote objects as references from other CORBA objects. In binding
>> configuration user should point remote objects name, which is
>> registered in name service. Again, I think it should be configured per
>> binding, so which attribute for binding.corba shall I use?
>
> That should be derived from the URI of the binding.
>
>>
>> 5. CORBA objects obtained from binding will be dynamically enhanced
>> by, lets call it, DII Corba Invoker (DCI), and attached to matching
>> Java interface, so Tuscany user can use it. DCI will be responsible
>> for creating request, based on operation name, operation arguments and
>> return type. Every other CORBA object, obtained in any way (from
>> binding, as a result of any other CORBA objects operation) will be
>> also enhanced/attached as above.
>
> Yes. The corba reference binding invoker is responsible to bridge the
> invocations between SCA and CORBA.
>
>>
>> 6. If CORBA objects operation argument is object reference, then user
>> should provide object which was previously obtained from binding or
>> other CORBA object. User cannot use users-side object as an argument.
>>
>
> Yes. Let's don't worry object reference too much at this point. We are
> in the SOA world instead of distributed object :-).
>
>> I hope I described my thoughts clearly, I'll appreciate any comments,
>> especially pointing out things I'm wrong or missing.
>>
>> Thanks,
>> Wojtek
>
I took a look at binding-corba/.../CorbaServiceBindingProvider in trunk.
At the moment the ORB setup is in the start method of the provider (and
there's no cleanup in the stop method). I'm not quite sure how this is
going to work with multiple services sharing the same ORB.
I'm thinking that we'll need the following to support multiple services:
- A host-corba implementation (similar to host-ejb, host-rmi or
host-http) to setup/tear the ORB when the Tuscany runtime starts/stops,
independent of the registration of particular services with the ORB.
- Logic in that host-corba to set up the ORB in a lazy fashion when the
first Corba service is registered.
- Only keep the ORB servant creation and naming bind/unbind in the
service provider class.
Makes sense?
--
Jean-Sebastien
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Wojtek Janiszewski" <wo...@gmail.com>
Sent: Thursday, May 22, 2008 3:21 AM
To: <tu...@ws.apache.org>
Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
> Hello Tuscany Community!
>
> I've spent last days considering project details and made some prototypes
> which were mainly verifying CORBA API in JDK. I'd like also to begin
> coding shortly - I'd like to start implementing reference binding
> implementation for CORBA objects. I've listed some assumptions/doubts:
>
> 1. Original time schedule was to start work with "Implementation of
> interface-corba-idl module.". I was told to start with CORBA bindings, I
> just wanted to make sure that these modules implementation schedule can be
> swapped.
I think the CORA IDL support can be a 2nd step. We can invoke/expose CORBA
services using java interfaces.
>
> 2. I'll implement service/reference bindings using CORBA Dynamic
> Invocation Interface (DII) API. Standard JDK CORBA support *should* be
> enough, if no, there are other CORBA implementations, such as JacORB.
Standard JDK APIs should be good enough. There is an Apache CORBA project
at: http://cwiki.apache.org/YOKO/.
>
> 3. Where should parameters ORBInitialHost and ORBInitialPort be passed to
> application? They shouldn't be configured global for application, because
> every binding can use different ORB, so I assume it should be configured
> per binding. Which attributes for binding.corba shall I use?
They should be configured at the <binding.corba>.
>
> 4. In CORBA we can register objects under unique name, or obtain remote
> objects as references from other CORBA objects. In binding configuration
> user should point remote objects name, which is registered in name
> service. Again, I think it should be configured per binding, so which
> attribute for binding.corba shall I use?
That should be derived from the URI of the binding.
>
> 5. CORBA objects obtained from binding will be dynamically enhanced by,
> lets call it, DII Corba Invoker (DCI), and attached to matching Java
> interface, so Tuscany user can use it. DCI will be responsible for
> creating request, based on operation name, operation arguments and return
> type. Every other CORBA object, obtained in any way (from binding, as a
> result of any other CORBA objects operation) will be also
> enhanced/attached as above.
Yes. The corba reference binding invoker is responsible to bridge the
invocations between SCA and CORBA.
>
> 6. If CORBA objects operation argument is object reference, then user
> should provide object which was previously obtained from binding or other
> CORBA object. User cannot use users-side object as an argument.
>
Yes. Let's don't worry object reference too much at this point. We are in
the SOA world instead of distributed object :-).
> I hope I described my thoughts clearly, I'll appreciate any comments,
> especially pointing out things I'm wrong or missing.
>
> Thanks,
> Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Wojtek Janiszewski <wo...@gmail.com>.
Hello Tuscany Community!
I've spent last days considering project details and made some
prototypes which were mainly verifying CORBA API in JDK. I'd like also
to begin coding shortly - I'd like to start implementing reference
binding implementation for CORBA objects. I've listed some
assumptions/doubts:
1. Original time schedule was to start work with "Implementation of
interface-corba-idl module.". I was told to start with CORBA bindings, I
just wanted to make sure that these modules implementation schedule can
be swapped.
2. I'll implement service/reference bindings using CORBA Dynamic
Invocation Interface (DII) API. Standard JDK CORBA support *should* be
enough, if no, there are other CORBA implementations, such as JacORB.
3. Where should parameters ORBInitialHost and ORBInitialPort be passed
to application? They shouldn't be configured global for application,
because every binding can use different ORB, so I assume it should be
configured per binding. Which attributes for binding.corba shall I use?
4. In CORBA we can register objects under unique name, or obtain remote
objects as references from other CORBA objects. In binding configuration
user should point remote objects name, which is registered in name
service. Again, I think it should be configured per binding, so which
attribute for binding.corba shall I use?
5. CORBA objects obtained from binding will be dynamically enhanced by,
lets call it, DII Corba Invoker (DCI), and attached to matching Java
interface, so Tuscany user can use it. DCI will be responsible for
creating request, based on operation name, operation arguments and
return type. Every other CORBA object, obtained in any way (from
binding, as a result of any other CORBA objects operation) will be also
enhanced/attached as above.
6. If CORBA objects operation argument is object reference, then user
should provide object which was previously obtained from binding or
other CORBA object. User cannot use users-side object as an argument.
I hope I described my thoughts clearly, I'll appreciate any comments,
especially pointing out things I'm wrong or missing.
Thanks,
Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Raymond Feng <en...@gmail.com>.
Hi, Wojtek.
I'm glad to see you make progress. Please submit incremental patches with
JIRAs as you improve the code. This way, we can review and apply them so
that the community knows what's evolving.
Thanks,
Raymond
--------------------------------------------------
From: "Wojtek Janiszewski" <wo...@gmail.com>
Sent: Saturday, May 03, 2008 11:10 AM
To: <tu...@ws.apache.org>
Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
> Simon Laws wrote:
>>> And I also solved it like before.
>>> Finally I end up with build error like this:
>>>
>>> [ERROR] BUILD ERROR
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Failed to resolve artifact.
>>>
>>> Couldn't find a version in [3.3.0-I20070620, 3.2.1-M20060915-1030,
>>> 3.3.0-I20070531-1800] to match range [3.3.0,4.0.0)
>>> org.eclipse.ui:ide:jar:null
>>>
>>> from the specified remote repositories:
>>> central (http://repo1.maven.org/maven2),
>>> apache.ws.zone (http://ws.zones.apache.org/repository2),
>>> apache.incubator
>>> (http://people.apache.org/repo/m2-incubating-repository
>>> ),
>>> repo1.eclipse (http://repo1.maven.org/eclipse/),
>>> apache.snapshots
>>> (http://people.apache.org/repo/m2-snapshot-repository),
>>> apache (http://maven.apache.org/maven2)
>>>
>>> Looks like this one isn't connected with previous errors. Any
>>> suggestions?
>>>
>>> Thanks,
>>> Wojtek
>>>
>>
>> Apologies Wojtek, I missed that one and it needs the same change. I just
>> checked in the fix so if you update modules/monitor-logging and
>> modules/workspace-impl you should see two property file name changes and
>> hopefully it will compile for you.
>>
>> Regards
>>
>> Simon
>>
>
> Hi,
> thanks, it helped. But I still get the following error:
>
> Couldn't find a version in [3.3.0-I20070620, 3.2.1-M20060915-1030,
> 3.3.0-I20070531-1800] to match range [3.3.0,4.0.0)
> org.eclipse.ui:ide:jar:null
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> apache.ws.zone (http://ws.zones.apache.org/repository2),
> apache.incubator (http://people.apache.org/repo/m2-incubating-repository
> ),
> repo1.eclipse (http://repo1.maven.org/eclipse/),
> apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
> apache (http://maven.apache.org/maven2)
>
>
> Apart from build errors - I've made some progress to project and started
> to learn about extending Tuscany from
> http://incubator.apache.org/tuscany/sca-java-extension-development-guide.data/ExtendingTuscany-V01.pdf
> and from CORBA base code. I've created CorbaModuleActivator class, which
> plugs binding module into Tuscany. I've added following line to
> META-INF/services/org.apache.tuscany.sca.core.ModuleActivator (which
> points to previously added activator):
>
> org.apache.tuscany.sca.binding.corba.CorbaModuleActivator
>
> I've also updated
> org.apache.tuscany.sca.binding.corba.impl.CorbaBindingProviderFactory.createReferenceBindingProvider(...)
> method to return CorbaReferenceBindingProvider object.
>
> I've tested CORBA base code using my sample prepared for university
> seminar. I've configured CORBA reference in composite file, I've "mocked"
> some of CORBA base code (made CorbaInvoker to return fixed response) , and
> successfully executed method for CORBA reference. Now it's time to know
> better Tuscany SPI and Tuscany/SCA specification.
>
> I forgot to mention my GSoC project page. It can be found under [1].
>
> [1] -
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/CORBA+support+for+Apache+Tuscany
>
> Thanks,
> Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Wojtek Janiszewski <wo...@gmail.com>.
Simon Laws wrote:
>> And I also solved it like before.
>> Finally I end up with build error like this:
>>
>> [ERROR] BUILD ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Failed to resolve artifact.
>>
>> Couldn't find a version in [3.3.0-I20070620, 3.2.1-M20060915-1030,
>> 3.3.0-I20070531-1800] to match range [3.3.0,4.0.0)
>> org.eclipse.ui:ide:jar:null
>>
>> from the specified remote repositories:
>> central (http://repo1.maven.org/maven2),
>> apache.ws.zone (http://ws.zones.apache.org/repository2),
>> apache.incubator (http://people.apache.org/repo/m2-incubating-repository
>> ),
>> repo1.eclipse (http://repo1.maven.org/eclipse/),
>> apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
>> apache (http://maven.apache.org/maven2)
>>
>> Looks like this one isn't connected with previous errors. Any suggestions?
>>
>> Thanks,
>> Wojtek
>>
>
> Apologies Wojtek, I missed that one and it needs the same change. I just
> checked in the fix so if you update modules/monitor-logging and
> modules/workspace-impl you should see two property file name changes and
> hopefully it will compile for you.
>
> Regards
>
> Simon
>
Hi,
thanks, it helped. But I still get the following error:
Couldn't find a version in [3.3.0-I20070620, 3.2.1-M20060915-1030,
3.3.0-I20070531-1800] to match range [3.3.0,4.0.0)
org.eclipse.ui:ide:jar:null
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
apache.ws.zone (http://ws.zones.apache.org/repository2),
apache.incubator (http://people.apache.org/repo/m2-incubating-repository
),
repo1.eclipse (http://repo1.maven.org/eclipse/),
apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
apache (http://maven.apache.org/maven2)
Apart from build errors - I've made some progress to project and started
to learn about extending Tuscany from
http://incubator.apache.org/tuscany/sca-java-extension-development-guide.data/ExtendingTuscany-V01.pdf
and from CORBA base code. I've created CorbaModuleActivator class, which
plugs binding module into Tuscany. I've added following line to
META-INF/services/org.apache.tuscany.sca.core.ModuleActivator (which
points to previously added activator):
org.apache.tuscany.sca.binding.corba.CorbaModuleActivator
I've also updated
org.apache.tuscany.sca.binding.corba.impl.CorbaBindingProviderFactory.createReferenceBindingProvider(...)
method to return CorbaReferenceBindingProvider object.
I've tested CORBA base code using my sample prepared for university
seminar. I've configured CORBA reference in composite file, I've
"mocked" some of CORBA base code (made CorbaInvoker to return fixed
response) , and successfully executed method for CORBA reference. Now
it's time to know better Tuscany SPI and Tuscany/SCA specification.
I forgot to mention my GSoC project page. It can be found under [1].
[1] -
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/CORBA+support+for+Apache+Tuscany
Thanks,
Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Simon Laws <si...@googlemail.com>.
On Thu, May 1, 2008 at 1:06 PM, Wojtek Janiszewski <
wojtek.janiszewski@gmail.com> wrote:
> Simon Laws wrote:
>
> > On Wed, Apr 30, 2008 at 7:10 PM, Raymond Feng <en...@gmail.com>
> > wrote:
> >
> > For now, I recommend you to use "mvn clean install -fn" to continue.
> > > And
> > > also please open a JIRA to report the problem you are seeing so that
> > > we can
> > > track and fix it.
> > >
> > > Thanks,
> > > Raymond
> > > --------------------------------------------------
> > > From: "Wojtek Janiszewski" <wo...@gmail.com>
> > > Sent: Wednesday, April 30, 2008 10:43 AM
> > > To: <tu...@ws.apache.org>
> > > Subject: GSoC Project - CORBA Support for Apache Tuscany
> > >
> > >
> > > Hi,
> > >
> > > > Raymond Feng checked in some skeleton code for CORBA services and
> > > > references binding. To start project I've tried to build Tuscany.
> > > > I've
> > > > followed this document [1], tried to make top-down build with code
> > > > from [2]
> > > > and got Build Failure while testing "Apache Tuscany SCA XML Assembly
> > > > Model".
> > > > I'm using maven 2.0.7, jdk1.5.0_09, Slackware Linux running
> > > > 2.6.23.12kernel.
> > > >
> > > > Tests in error:
> > > >
> > > >
> > > >
> > > > testResolveConstrainingType(org.apache.tuscany.sca.assembly.xml.WireTestCase)
> > > >
> > > > testResolveComposite(org.apache.tuscany.sca.assembly.xml.WireTestCase)
> > > >
> > > >
> > > >
> > > > testReadWireWriteComposite(org.apache.tuscany.sca.assembly.xml.WriteAllTestCase)
> > > >
> > > >
> > > >
> > > > testPolicyIntentInheritance(org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase)
> > > >
> > > > Exceptions for every test are quite the same:
> > > > java.util.MissingResourceException: Can't find
> > > > assembly-validation-messages bundle
> > > > at
> > > > java.util.logging.Logger.setupResourceInfo(Logger.java:1309)
> > > > at java.util.logging.Logger.<init>(Logger.java:204)
> > > > at java.util.logging.Logger.getLogger(Logger.java:300)
> > > > at
> > > >
> > > > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1.problem(CompositeBuilderImpl.java:89)
> > > > at
> > > >
> > > > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.warning(BaseConfigurationBuilderImpl.java:297)
> > > > at
> > > >
> > > > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.indexImplementationPropertiesServicesAndReferences(BaseConfigurationBuilderImpl.java:616)
> > > > at
> > > >
> > > > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:197)
> > > > at
> > > >
> > > > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:85)
> > > > at
> > > >
> > > > org.apache.tuscany.sca.assembly.builder.impl.ComponentConfigurationBuilderImpl.build(ComponentConfigurationBuilderImpl.java:47)
> > > > at
> > > >
> > > > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:127)
> > > > at
> > > >
> > > > org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase.setUp(BuildPolicyTestCase.java:126)
> > > > at junit.framework.TestCase.runBare(TestCase.java:132)
> > > > at junit.framework.TestResult$1.protect(TestResult.java:110)
> > > > at
> > > > junit.framework.TestResult.runProtected(TestResult.java:128)
> > > > at junit.framework.TestResult.run(TestResult.java:113)
> > > > at junit.framework.TestCase.run(TestCase.java:124)
> > > > at junit.framework.TestSuite.runTest(TestSuite.java:232)
> > > > at junit.framework.TestSuite.run(TestSuite.java:227)
> > > > at
> > > >
> > > > org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
> > > > at
> > > >
> > > > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> > > > at
> > > >
> > > > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
> > > > at
> > > >
> > > > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
> > > > at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > >
> > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > at
> > > >
> > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > at
> > > >
> > > > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> > > > at
> > > >
> > > > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
> > > >
> > > >
> > > >
> > > > [1] -
> > > > http://incubator.apache.org/tuscany/sca-java-development-guide.html
> > > > [2] - http://svn.apache.org/repos/asf/incubator/tuscany/java
> > > >
> > > > I'm asking you for a help, does anyone have idea what I'm doing
> > > > wrong?
> > > >
> > > > Thanks,
> > > > Wojtek
> > > >
> > > >
> > > Hi Wojtek
> >
> > I cam across this problem also and checked in a fix so maybe it needs a
> > little something else. Can you tell me when you took the code from svn?
> > Also
> > can you take a look in the source you have an tell me what properties
> > files
> > you have in the directory sca/modules/assembly/src/main/resources/. Do
> > they
> > have the same names as the files in the svn repository?
> >
> >
> > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/assembly/src/main/resources/
> >
> > Thanks
> >
> > Simon
> >
> >
> Hi Raymond, Simon,
>
> Raymond:
> I'd like to open a JIRA report. Which Tuscany component in JIRA should I
> choose?
>
> Simon:
> I've downloaded source code yesterday (30th April) about 1PM UTC +2. In
> sca/modules/assembly/src/main/resources/ I had two files:
> assembly-validation-messages_en.properties
> assembly-validation-messages_it.properties
>
> After updating source code problem gone, but another one showed up:
>
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running MonitorTestCase
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.102 sec
> <<< FAILURE!
> testCreateProblem(MonitorTestCase) Time elapsed: 0.038 sec <<< ERROR!
> java.util.MissingResourceException: Can't find
> tuscany-monitor-test-messages bundle
> (...)
>
> Results :
>
> Tests in error:
> testCreateProblem(MonitorTestCase)
>
> I've solved this one by renaming local file
> tuscany-monitor-test-messages_en.properties to
> tuscany-monitor-test-messages.properties.
>
> Another problem occured:
>
> Running org.apache.tuscany.sca.domain.manager.impl.DomainManagerTestCase
> Tests run: 5, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.609 sec
> <<< FAILURE!
> testDependencies1(org.apache.tuscany.sca.domain.manager.impl.DomainManagerTestCase)
> Time elapsed: 0.101 sec <<< ERROR!
> java.util.MissingResourceException: Can't find
> workspace-validation-messages bundle
> (...)
>
> testDependencies2(org.apache.tuscany.sca.domain.manager.impl.DomainManagerTestCase)
> Time elapsed: 0.074 sec <<< ERROR!
> java.util.MissingResourceException: Can't find
> workspace-validation-messages bundle
> (...)
>
> Results :
>
> Tests in error:
>
>
> testDependencies1(org.apache.tuscany.sca.domain.manager.impl.DomainManagerTestCase)
>
> testDependencies2(org.apache.tuscany.sca.domain.manager.impl.DomainManagerTestCase)
>
> And I also solved it like before.
> Finally I end up with build error like this:
>
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
>
> Couldn't find a version in [3.3.0-I20070620, 3.2.1-M20060915-1030,
> 3.3.0-I20070531-1800] to match range [3.3.0,4.0.0)
> org.eclipse.ui:ide:jar:null
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> apache.ws.zone (http://ws.zones.apache.org/repository2),
> apache.incubator (http://people.apache.org/repo/m2-incubating-repository
> ),
> repo1.eclipse (http://repo1.maven.org/eclipse/),
> apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
> apache (http://maven.apache.org/maven2)
>
> Looks like this one isn't connected with previous errors. Any suggestions?
>
> Thanks,
> Wojtek
>
Apologies Wojtek, I missed that one and it needs the same change. I just
checked in the fix so if you update modules/monitor-logging and
modules/workspace-impl you should see two property file name changes and
hopefully it will compile for you.
Regards
Simon
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Wojtek Janiszewski <wo...@gmail.com>.
Simon Laws wrote:
> On Wed, Apr 30, 2008 at 7:10 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> For now, I recommend you to use "mvn clean install -fn" to continue. And
>> also please open a JIRA to report the problem you are seeing so that we can
>> track and fix it.
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "Wojtek Janiszewski" <wo...@gmail.com>
>> Sent: Wednesday, April 30, 2008 10:43 AM
>> To: <tu...@ws.apache.org>
>> Subject: GSoC Project - CORBA Support for Apache Tuscany
>>
>>
>> Hi,
>>> Raymond Feng checked in some skeleton code for CORBA services and
>>> references binding. To start project I've tried to build Tuscany. I've
>>> followed this document [1], tried to make top-down build with code from [2]
>>> and got Build Failure while testing "Apache Tuscany SCA XML Assembly Model".
>>> I'm using maven 2.0.7, jdk1.5.0_09, Slackware Linux running 2.6.23.12kernel.
>>>
>>> Tests in error:
>>>
>>>
>>> testResolveConstrainingType(org.apache.tuscany.sca.assembly.xml.WireTestCase)
>>> testResolveComposite(org.apache.tuscany.sca.assembly.xml.WireTestCase)
>>>
>>>
>>> testReadWireWriteComposite(org.apache.tuscany.sca.assembly.xml.WriteAllTestCase)
>>>
>>>
>>> testPolicyIntentInheritance(org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase)
>>>
>>> Exceptions for every test are quite the same:
>>> java.util.MissingResourceException: Can't find
>>> assembly-validation-messages bundle
>>> at java.util.logging.Logger.setupResourceInfo(Logger.java:1309)
>>> at java.util.logging.Logger.<init>(Logger.java:204)
>>> at java.util.logging.Logger.getLogger(Logger.java:300)
>>> at
>>> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1.problem(CompositeBuilderImpl.java:89)
>>> at
>>> org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.warning(BaseConfigurationBuilderImpl.java:297)
>>> at
>>> org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.indexImplementationPropertiesServicesAndReferences(BaseConfigurationBuilderImpl.java:616)
>>> at
>>> org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:197)
>>> at
>>> org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:85)
>>> at
>>> org.apache.tuscany.sca.assembly.builder.impl.ComponentConfigurationBuilderImpl.build(ComponentConfigurationBuilderImpl.java:47)
>>> at
>>> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:127)
>>> at
>>> org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase.setUp(BuildPolicyTestCase.java:126)
>>> at junit.framework.TestCase.runBare(TestCase.java:132)
>>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>>> at junit.framework.TestResult.runProtected(TestResult.java:128)
>>> at junit.framework.TestResult.run(TestResult.java:113)
>>> at junit.framework.TestCase.run(TestCase.java:124)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:232)
>>> at junit.framework.TestSuite.run(TestSuite.java:227)
>>> at
>>> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>>> at
>>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
>>> at
>>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
>>> at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>> at
>>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
>>> at
>>> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
>>>
>>>
>>>
>>> [1] -
>>> http://incubator.apache.org/tuscany/sca-java-development-guide.html
>>> [2] - http://svn.apache.org/repos/asf/incubator/tuscany/java
>>>
>>> I'm asking you for a help, does anyone have idea what I'm doing wrong?
>>>
>>> Thanks,
>>> Wojtek
>>>
>>
> Hi Wojtek
>
> I cam across this problem also and checked in a fix so maybe it needs a
> little something else. Can you tell me when you took the code from svn? Also
> can you take a look in the source you have an tell me what properties files
> you have in the directory sca/modules/assembly/src/main/resources/. Do they
> have the same names as the files in the svn repository?
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/assembly/src/main/resources/
>
> Thanks
>
> Simon
>
Hi Raymond, Simon,
Raymond:
I'd like to open a JIRA report. Which Tuscany component in JIRA should I
choose?
Simon:
I've downloaded source code yesterday (30th April) about 1PM UTC +2. In
sca/modules/assembly/src/main/resources/ I had two files:
assembly-validation-messages_en.properties
assembly-validation-messages_it.properties
After updating source code problem gone, but another one showed up:
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running MonitorTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.102
sec <<< FAILURE!
testCreateProblem(MonitorTestCase) Time elapsed: 0.038 sec <<< ERROR!
java.util.MissingResourceException: Can't find
tuscany-monitor-test-messages bundle
(...)
Results :
Tests in error:
testCreateProblem(MonitorTestCase)
I've solved this one by renaming local file
tuscany-monitor-test-messages_en.properties to
tuscany-monitor-test-messages.properties.
Another problem occured:
Running org.apache.tuscany.sca.domain.manager.impl.DomainManagerTestCase
Tests run: 5, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.609
sec <<< FAILURE!
testDependencies1(org.apache.tuscany.sca.domain.manager.impl.DomainManagerTestCase)
Time elapsed: 0.101 sec <<< ERROR!
java.util.MissingResourceException: Can't find
workspace-validation-messages bundle
(...)
testDependencies2(org.apache.tuscany.sca.domain.manager.impl.DomainManagerTestCase)
Time elapsed: 0.074 sec <<< ERROR!
java.util.MissingResourceException: Can't find
workspace-validation-messages bundle
(...)
Results :
Tests in error:
testDependencies1(org.apache.tuscany.sca.domain.manager.impl.DomainManagerTestCase)
testDependencies2(org.apache.tuscany.sca.domain.manager.impl.DomainManagerTestCase)
And I also solved it like before.
Finally I end up with build error like this:
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Couldn't find a version in [3.3.0-I20070620, 3.2.1-M20060915-1030,
3.3.0-I20070531-1800] to match range [3.3.0,4.0.0)
org.eclipse.ui:ide:jar:null
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
apache.ws.zone (http://ws.zones.apache.org/repository2),
apache.incubator
(http://people.apache.org/repo/m2-incubating-repository),
repo1.eclipse (http://repo1.maven.org/eclipse/),
apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
apache (http://maven.apache.org/maven2)
Looks like this one isn't connected with previous errors. Any suggestions?
Thanks,
Wojtek
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Apr 30, 2008 at 7:10 PM, Raymond Feng <en...@gmail.com> wrote:
> For now, I recommend you to use "mvn clean install -fn" to continue. And
> also please open a JIRA to report the problem you are seeing so that we can
> track and fix it.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Wojtek Janiszewski" <wo...@gmail.com>
> Sent: Wednesday, April 30, 2008 10:43 AM
> To: <tu...@ws.apache.org>
> Subject: GSoC Project - CORBA Support for Apache Tuscany
>
>
> Hi,
> > Raymond Feng checked in some skeleton code for CORBA services and
> > references binding. To start project I've tried to build Tuscany. I've
> > followed this document [1], tried to make top-down build with code from [2]
> > and got Build Failure while testing "Apache Tuscany SCA XML Assembly Model".
> > I'm using maven 2.0.7, jdk1.5.0_09, Slackware Linux running 2.6.23.12kernel.
> >
> > Tests in error:
> >
> >
> > testResolveConstrainingType(org.apache.tuscany.sca.assembly.xml.WireTestCase)
> > testResolveComposite(org.apache.tuscany.sca.assembly.xml.WireTestCase)
> >
> >
> > testReadWireWriteComposite(org.apache.tuscany.sca.assembly.xml.WriteAllTestCase)
> >
> >
> > testPolicyIntentInheritance(org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase)
> >
> > Exceptions for every test are quite the same:
> > java.util.MissingResourceException: Can't find
> > assembly-validation-messages bundle
> > at java.util.logging.Logger.setupResourceInfo(Logger.java:1309)
> > at java.util.logging.Logger.<init>(Logger.java:204)
> > at java.util.logging.Logger.getLogger(Logger.java:300)
> > at
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1.problem(CompositeBuilderImpl.java:89)
> > at
> > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.warning(BaseConfigurationBuilderImpl.java:297)
> > at
> > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.indexImplementationPropertiesServicesAndReferences(BaseConfigurationBuilderImpl.java:616)
> > at
> > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:197)
> > at
> > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:85)
> > at
> > org.apache.tuscany.sca.assembly.builder.impl.ComponentConfigurationBuilderImpl.build(ComponentConfigurationBuilderImpl.java:47)
> > at
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:127)
> > at
> > org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase.setUp(BuildPolicyTestCase.java:126)
> > at junit.framework.TestCase.runBare(TestCase.java:132)
> > at junit.framework.TestResult$1.protect(TestResult.java:110)
> > at junit.framework.TestResult.runProtected(TestResult.java:128)
> > at junit.framework.TestResult.run(TestResult.java:113)
> > at junit.framework.TestCase.run(TestCase.java:124)
> > at junit.framework.TestSuite.runTest(TestSuite.java:232)
> > at junit.framework.TestSuite.run(TestSuite.java:227)
> > at
> > org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
> > at
> > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> > at
> > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
> > at
> > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
> > at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:585)
> > at
> > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> > at
> > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
> >
> >
> >
> > [1] -
> > http://incubator.apache.org/tuscany/sca-java-development-guide.html
> > [2] - http://svn.apache.org/repos/asf/incubator/tuscany/java
> >
> > I'm asking you for a help, does anyone have idea what I'm doing wrong?
> >
> > Thanks,
> > Wojtek
> >
>
>
Hi Wojtek
I cam across this problem also and checked in a fix so maybe it needs a
little something else. Can you tell me when you took the code from svn? Also
can you take a look in the source you have an tell me what properties files
you have in the directory sca/modules/assembly/src/main/resources/. Do they
have the same names as the files in the svn repository?
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/assembly/src/main/resources/
Thanks
Simon
Re: GSoC Project - CORBA Support for Apache Tuscany
Posted by Raymond Feng <en...@gmail.com>.
For now, I recommend you to use "mvn clean install -fn" to continue. And
also please open a JIRA to report the problem you are seeing so that we can
track and fix it.
Thanks,
Raymond
--------------------------------------------------
From: "Wojtek Janiszewski" <wo...@gmail.com>
Sent: Wednesday, April 30, 2008 10:43 AM
To: <tu...@ws.apache.org>
Subject: GSoC Project - CORBA Support for Apache Tuscany
> Hi,
> Raymond Feng checked in some skeleton code for CORBA services and
> references binding. To start project I've tried to build Tuscany. I've
> followed this document [1], tried to make top-down build with code from
> [2] and got Build Failure while testing "Apache Tuscany SCA XML Assembly
> Model".
> I'm using maven 2.0.7, jdk1.5.0_09, Slackware Linux running 2.6.23.12
> kernel.
>
> Tests in error:
>
> testResolveConstrainingType(org.apache.tuscany.sca.assembly.xml.WireTestCase)
> testResolveComposite(org.apache.tuscany.sca.assembly.xml.WireTestCase)
>
> testReadWireWriteComposite(org.apache.tuscany.sca.assembly.xml.WriteAllTestCase)
>
> testPolicyIntentInheritance(org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase)
>
> Exceptions for every test are quite the same:
> java.util.MissingResourceException: Can't find
> assembly-validation-messages bundle
> at java.util.logging.Logger.setupResourceInfo(Logger.java:1309)
> at java.util.logging.Logger.<init>(Logger.java:204)
> at java.util.logging.Logger.getLogger(Logger.java:300)
> at
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1.problem(CompositeBuilderImpl.java:89)
> at
> org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.warning(BaseConfigurationBuilderImpl.java:297)
> at
> org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.indexImplementationPropertiesServicesAndReferences(BaseConfigurationBuilderImpl.java:616)
> at
> org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:197)
> at
> org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:85)
> at
> org.apache.tuscany.sca.assembly.builder.impl.ComponentConfigurationBuilderImpl.build(ComponentConfigurationBuilderImpl.java:47)
> at
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:127)
> at
> org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase.setUp(BuildPolicyTestCase.java:126)
> at junit.framework.TestCase.runBare(TestCase.java:132)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
>
>
>
> [1] - http://incubator.apache.org/tuscany/sca-java-development-guide.html
> [2] - http://svn.apache.org/repos/asf/incubator/tuscany/java
>
> I'm asking you for a help, does anyone have idea what I'm doing wrong?
>
> Thanks,
> Wojtek