Re: GSoC Project - CORBA Support for Apache Tuscany
Please see my comments inline. Thanks, Raymond -- From: Wojtek Janiszewski [EMAIL PROTECTED] Sent: Thursday, June 12, 2008 2:39 AM To: tuscany-dev@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 [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:55 AM To: tuscany-dev@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
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
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 [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:55 AM To: tuscany-dev@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
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
Re: GSoC Project - CORBA Support for Apache Tuscany
Hi, Wojtek. Please see my comments inline. Thanks, Raymond -- From: Wojtek Janiszewski [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:55 AM To: tuscany-dev@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
Re: GSoC Project - CORBA Support for Apache Tuscany
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 [EMAIL PROTECTED]
Sent: Sunday, June 08, 2008 6:50 PM
To: tuscany-dev@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
Re: GSoC Project - CORBA Support for Apache Tuscany
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
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
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
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
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
One comment inline. Simon Jean-Sebastien Delfino wrote: Raymond Feng wrote: Please see my comments inline. Thanks, Raymond -- From: Wojtek Janiszewski [EMAIL PROTECTED] Sent: Thursday, May 22, 2008 3:21 AM To: tuscany-dev@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
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
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
Raymond Feng wrote: Please see my comments inline. Thanks, Raymond -- From: Wojtek Janiszewski [EMAIL PROTECTED] Sent: Thursday, May 22, 2008 3:21 AM To: tuscany-dev@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
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
Please see my comments inline. Thanks, Raymond -- From: Wojtek Janiszewski [EMAIL PROTECTED] Sent: Thursday, May 22, 2008 3:21 AM To: tuscany-dev@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
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 [EMAIL PROTECTED] Sent: Saturday, May 03, 2008 11:10 AM To: tuscany-dev@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
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
On Wed, Apr 30, 2008 at 7:10 PM, Raymond Feng [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Sent: Wednesday, April 30, 2008 10:43 AM To: tuscany-dev@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
Simon Laws wrote: On Wed, Apr 30, 2008 at 7:10 PM, Raymond Feng [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Sent: Wednesday, April 30, 2008 10:43 AM To: tuscany-dev@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
Re: GSoC Project - CORBA Support for Apache Tuscany
On Thu, May 1, 2008 at 1:06 PM, Wojtek Janiszewski [EMAIL PROTECTED] wrote: Simon Laws wrote: On Wed, Apr 30, 2008 at 7:10 PM, Raymond Feng [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Sent: Wednesday, April 30, 2008 10:43 AM To: tuscany-dev@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
Re: GSoC Project - CORBA Support for Apache Tuscany
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 [EMAIL PROTECTED] Sent: Wednesday, April 30, 2008 10:43 AM To: tuscany-dev@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
