Merged changes from M1 branch into the head stream
I merged the changes from the M1 branch into the main stream This includes changes to some of the pom.xml files to generate correct manifest files and changes to the readme, license and notice files to include them in the generated JARs. The merge process was a little complicated so could the people working on the various components please check that I didn't mess up or miss anything? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version number in pom.xml
Daniel Kulp wrote: 1.0-incubating-M2-SNAPSHOT is probably the technical version number we should be using. It specifically states we are working on the snapshot version of 1.0-incubating-M2 which I assume will be the version we use when we release M2. Dan On Tuesday June 20 2006 12:29 pm, Jean-Sebastien Delfino wrote: We currently have versionincubating-M1/version in all our pom.xml files. What do you think we should use now? SNAPSHOT? 1.0-SNAPSHOT? 0.1-SNAPSHOT? Any opinions? This makes sense to me but what do others think? If I remember correctly at some point I had proposed 0.9 and some of us thought that a 0.9 version number could give false expectations in terms of stability/completeness. Are we running the same risk with a 1.0-incubating-M2? Or do you think that having -M2 at the end makes it clear that this will only be a Milestone release and not a 1.0 release? If there is no objections, I'll change the version numbers to 1.0-incubating-M2 on Thursday morning. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany SPI interfaces
I'm trying to implement the sample ruby extension and running into some issues. I'm implementing an AtomicComponentContext (with the code in the head stream) and also trying the equivalent AtomicComponent with some of the code in the sandbox. I want to be able to implement my extension class without having to depend on base Tuscany runtime implementation classes, so I'm just implementing the SPI interfaces. Unless I missed something (and it's very possible since I don't understand all the pieces yet) here's what I found: - with the code in the head, my AtomicComponentContext needs to implement 15 methods; - with the code in the sandbox, I have to implement 25 methods. And this is just one class, I'm not even implementing the builders or invokers yet... I think that in both cases this is too much. It looks like the experiment in the sandbox is attempting to provide a simpler programming model for these extensions by hiding some of the complexity in base implementation classes, but I think it will be better to define a set of independent interfaces and make some of them optional. In other words if my extension does not wish to implement one of the interfaces, then it just doesn't need to, and the runtime should assume some default behavior, instead of forcing me to implement all the 25 methods... Another thought is to allow the contract to be implemented with multiple objects specialized in each aspect instead of one big object with 25 methods. As I'm going through the implementation of the ruby component implementation extension, I'm trying to come up with a short list of requirements and methods that I think we really need to implement, and with that list I'd like us to prototype simpler SPI interfaces. If anybody is interested in helping, please feel free to jump in, it would really be great if we could do a binding extension in parallel, and also if the people who actually developed some of the existing extensions could come up with the requirements they've seen in terms of SPI and proposals to improve our extensibility story. Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: move of container.java to core2
On Jun 20, 2006, at 10:37 AM, Jean-Sebastien Delfino wrote: Jim Marino wrote: In trying to eliminate reliance on core2 by container.java in the sandbox and have it only rely on the extensibility SPI, it occurred to me that this would mandate moving a lot of implementation classes from core2 into SPI. I believe having container.java as a separate project rely on core2 is the wrong approach. This leaves three options: - move the required classes to SPI - make container.java not dependent on core classes by duplicating them - merging container.java with core. I think moving the classes to SPI is not the best approach since they are implementations. Having duplicate classes does not seem to be the optimal approach either as that will result in a maintenance burden and a lot of code repetition. As background, the sharing of classes between core2 and container.java arises from the fact that the runtime uses a POJO model to assemble system services, and hence there is commonality between the two. I prefer to do the latter as it appears to be the cleanest. Also, java.container is not a very good example of how to extend the recursive core due to its advanced capabilities. I'd rather include a simple Java container geared to demonstrating how to extend the runtime. It would be helpful if people provide input over the next day...I plan to implement choice 3 tomorrow if there are no alternatives. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I would prefer another option: Define a clean SPI contract with just interfaces so that containers (component implementation extensions) do not have to depend on internal classes from the core project. I thought that it was the reason for having an SPI project separate from core. I think that the core runtime and the java container should be decoupled with clean interface-based contracts between the two. What are the technical issues preventing us from achieving that? That's exactly what we have, a clean SPI with mostly interfaces. Container.java and core, however, both use java Pojo's (system services, and Java CI components) so there are some common reflection and injection related classes. It doesn't make sense to duplicate those classes and related test cases and maintain exact replicas in two different projects of a significant amount of code. On the other hand, keeping container.java separate and referencing those core classes sends an unclear message to extension developers. The other option, putting the implementation classes in SPI is in my view also wrong for two reasons. First, they are implementation- related, Second, they are not things we want to expose in the SPI. So, to recap, we have a separate SPI extension package that does not require extension developers to reference the core implementation. Core, for example, is built on SPI. The issue I was bringing up in this thread is that as core and container.java share a significant amount of implementation, and container.java is central to both SCA and the Java Tuscany implementation, it makes sense to combine the two as opposed to duplicating the shared implementation. Jim -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Any recursive composition sample?
The last few weeks we've been talking about composites and recursive composition so much... and today I looked for a sample showing the new recursive composition model in our whole code base, including the head and our various sandboxes... and couldn't find any. I think it'll help all of us get our heads around this new model if we can see a few samples. Could somebody point me to a recursive composition sample if we have any and I missed it? Is anybody curious and interested in trying to port a few of our existing samples to the new recursive model? I guess the update of the SCA spec describing the recursive composition is not public yet, but the materials presented at JavaOne are public as far as I know, and should be sufficient to develop samples leveraging the new recursive composition model. If anybody is interested in developing sample scenarios that demonstrate the value of the recursive composition, please let me know, we can work together on this. I'd like to start this activity in parallel with the SPI analysis work that I'm currently doing. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sample Implementation and Binding extensions
You'll need t ask Jeremy on bootstrapping but you don't need to bootstrap the container to test you component extensions - the Spring and Groovy examples show how to do this. The Groovy issue was brought up on this list earlier and it's not related to Tuscany at all. It's a problem with the version of ASM it is using. I don't have the Tuscany thread right now but if you do a search, it involves deleting a version of ASM from you maven repo. If you can't find it, let me know and I'll look. Jim On Jun 20, 2006, at 12:59 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: Which code base are you intending to use: the M1 which implements the old .9 spec or the sandbox one which implements support for the new recursive model, or both? In terms of how to specifically improve the extensibility story, my opinions have been embodied in the sandbox code and presentation Jeremy and I gave the other week (there are several slides providing high-level overviews of how to extend things) :-) Comments on that approach would be appreciated. Jim On Jun 19, 2006, at 6:25 PM, Jean-Sebastien Delfino wrote: In order to better understand our extensibility story and how we can improve it for M2, I'd like to experiment a little with our extensibility APIs and try to develop two simple extensions: - a jruby implementation extension (I won't be starting from scratch, we already have an initial implementation, but I'll try to add support for properties, references, lifecycle management, and deployment maybe) - a simple TCP/IP (socket) binding implementation I'll bring any questions and issues I run into and improvement proposals on the mailing list and I'm thinking about keeping track of this on a Wiki page as well. I'm going to start with the component implementation extension. If anybody wants to help and start the TCP/IP binding extension, please let me know and we can coordinate (I think we'll find common techniques and patterns between the two). --Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm starting with both. Interestingly most of the differences between the two sets of SPIs are not related to the spec changes to support recursive composition, I found this surprising. I'm also going to propose, in the form of prototypes, improvements to the SPIs, there are good (and less good) things in both code streams, and I'd like to try to combine the best of both. Right now I'm prototyping this with the head stream, as I don't see yet how to run a simple sample with the code in sandbox, I'm running into the following issues: - I cannot find TuscanyRuntime anymore, has this been removed? has the mechanism for a client to bootstrap the runtime changed? is there a sample anywhere? - I was counting on the groovy container that you pointed me to yesterday to understand better the new SPIs but I'm not able to build it, the test cases fail with: java.lang.NoSuchMethodError: org.objectweb.asm.ClassVisitor.visit (IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/ lang/String;)V at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass (AsmClassGenerator.java:317) at org.codehaus.groovy.control.CompilationUnit$7.call (CompilationUnit.java:690) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes (CompilationUnit.java:956) at org.codehaus.groovy.control.CompilationUnit.classgen (CompilationUnit.java:629) at org.codehaus.groovy.control.CompilationUnit.compile (CompilationUnit.java:464) at groovy.lang.GroovyClassLoader.parseClass (GroovyClassLoader.java:300) at groovy.lang.GroovyClassLoader.parseClass (GroovyClassLoader.java:262) at groovy.lang.GroovyClassLoader.parseClass (GroovyClassLoader.java:257) at groovy.lang.GroovyClassLoader.parseClass (GroovyClassLoader.java:233) at org.apache.tuscany.container.groovy.GroovyAtomicComponent.createInstan ce(GroovyAtomicComponent.java:77) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SPI interfaces
+1
Where are you doing this and how can we start helping? A long time ago I had
a go at something like this for the JavaScript component, the interfaces it
had were along the lines of the ones below. probably a bit old now with all
the other changes. One thing I found hard was having a nice way to have
interfaces be either Java classes or WSDL portTypes particularly with
components invoking service references.
ComponentFactory {
Component createComponent(Component component);
}
Component {
ComponentDefinition getComponentDefinition();
Invoker createComponentInvoker(MapString, Object properties,
MapString, Reference references);
}
Invoker {
public Object invoke(String operationName, Object[] args);
}
ComponentDefinition {
Interface getInterface();
ListString getReferenceNames();
ListProperty getProperties();
String getInitOperationName();
String getDestroyOperationName();
}
Property {
String getName();
Object getDefaultValue();
boolean isRequired();
}
Reference {
Interface getInterface();
Object getProxy();
Invoker getInvoker();
}
Interface {
}
ClassInterface {
class[] getInterfaceClasses();
}
WSDLInterface {
String getNamespce();
String getPortTypeName();
Definition getDefinition();
}
...ant
On 6/21/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
I'm trying to implement the sample ruby extension and running into some
issues.
I'm implementing an AtomicComponentContext (with the code in the head
stream) and also trying the equivalent AtomicComponent with some of the
code in the sandbox. I want to be able to implement my extension class
without having to depend on base Tuscany runtime implementation classes,
so I'm just implementing the SPI interfaces.
Unless I missed something (and it's very possible since I don't
understand all the pieces yet) here's what I found:
- with the code in the head, my AtomicComponentContext needs to
implement 15 methods;
- with the code in the sandbox, I have to implement 25 methods.
And this is just one class, I'm not even implementing the builders or
invokers yet... I think that in both cases this is too much.
It looks like the experiment in the sandbox is attempting to provide a
simpler programming model for these extensions by hiding some of the
complexity in base implementation classes, but I think it will be better
to define a set of independent interfaces and make some of them
optional. In other words if my extension does not wish to implement one
of the interfaces, then it just doesn't need to, and the runtime should
assume some default behavior, instead of forcing me to implement all the
25 methods...
Another thought is to allow the contract to be implemented with multiple
objects specialized in each aspect instead of one big object with 25
methods.
As I'm going through the implementation of the ruby component
implementation extension, I'm trying to come up with a short list of
requirements and methods that I think we really need to implement, and
with that list I'd like us to prototype simpler SPI interfaces. If
anybody is interested in helping, please feel free to jump in, it would
really be great if we could do a binding extension in parallel, and also
if the people who actually developed some of the existing extensions
could come up with the requirements they've seen in terms of SPI and
proposals to improve our extensibility story.
Thanks,
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SPI interfaces
Jim Marino wrote:
I think you missed something. With core2, most people will extend from
the helper abstract classes in the SPI extension package (this was
also the case with the previous core). For example:
I didn't miss this class, as I said that's exactly what I'm trying to
avoid. I want to implement the SPI interfaces without having to extend
base implementation classes.
public class FooAtomicComponent extends AtomicComponentExtensionObject{
public FooAtomicComponent(String name, CompositeComponent?
parent, ScopeContainer scopeContainer, WireService wireService) {
super(name, parent, scopeContainer, wireService);
}
public Object getServiceInstance() throws TargetException {
return null;
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws
TargetException {
return null;
}
public ListClass? getServiceInterfaces() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName,
Method operation) {
return null;
}
}
I generally don't like to count methods without looking at what they
do (e.g. some could just be setter/getter types). The above class
contains 5 methods, which I believe are reasonable and we don't want
to separate out. Invoker is very simple too:
- Two methods to invoke, one for message invocations, and one for
raw payloads. Generally, the first will just pull the payload and
invoke the second
- A setter/getter pair for whether the invocation is cacheable
- A boolean if the invoker can be optimized away and the target can be
called through straight invocation without a proxy. Generally false.
- A clone method
The Spring and Groovy samples in the sandbox demonstrate both of these.
Jim
On Jun 21, 2006, at 1:37 AM, Jean-Sebastien Delfino wrote:
I'm trying to implement the sample ruby extension and running into
some issues.
I'm implementing an AtomicComponentContext (with the code in the head
stream) and also trying the equivalent AtomicComponent with some of
the code in the sandbox. I want to be able to implement my extension
class without having to depend on base Tuscany runtime implementation
classes, so I'm just implementing the SPI interfaces.
Unless I missed something (and it's very possible since I don't
understand all the pieces yet) here's what I found:
- with the code in the head, my AtomicComponentContext needs to
implement 15 methods;
- with the code in the sandbox, I have to implement 25 methods.
And this is just one class, I'm not even implementing the builders or
invokers yet... I think that in both cases this is too much.
It looks like the experiment in the sandbox is attempting to provide
a simpler programming model for these extensions by hiding some of
the complexity in base implementation classes, but I think it will be
better to define a set of independent interfaces and make some of
them optional. In other words if my extension does not wish to
implement one of the interfaces, then it just doesn't need to, and
the runtime should assume some default behavior, instead of forcing
me to implement all the 25 methods...
Another thought is to allow the contract to be implemented with
multiple objects specialized in each aspect instead of one big object
with 25 methods.
As I'm going through the implementation of the ruby component
implementation extension, I'm trying to come up with a short list of
requirements and methods that I think we really need to implement,
and with that list I'd like us to prototype simpler SPI interfaces.
If anybody is interested in helping, please feel free to jump in, it
would really be great if we could do a binding extension in parallel,
and also if the people who actually developed some of the existing
extensions could come up with the requirements they've seen in terms
of SPI and proposals to improve our extensibility story.
Thanks,
--Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
C++ runtime extensibility story
Could somebody working on the C++ runtime give us an overview of the C++ extensibility story (I'm not sure if you guys already have defined something but I thought I'd ask anyway). How can somebody add a component implementation extension or a binding extension to the C++ runtime? I'm currently looking at the design of our Java runtime extensibility and trying to see how we can improve it, maybe we can steal some good ideas from your C++ work :) or share ideas on the subject. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-475) Class cast exception on
[ http://issues.apache.org/jira/browse/TUSCANY-475?page=all ]
Kelvin Goodson updated TUSCANY-475:
---
Attachment: T475.patch
This patch is rooted in the directory java/sdo/impl.
The test has been updated with method testListIndexing().
The DataIObjectUtil.Accessor.setIndex() method now guards against negative
values and throws IndexOutOfBounds as soon as a negative value is encountered.
The special value NO_INDEX is used when the Property is not a vector and is set
to -1, therefore the amended setIndex method must not be used to set a value
of NO_INDEX. A comment to that effect has been added.
Class cast exception on
---
Key: TUSCANY-475
URL: http://issues.apache.org/jira/browse/TUSCANY-475
Project: Tuscany
Type: Bug
Components: Java SDO Implementation
Versions: Java-M1
Environment: Windows XP
Reporter: Simon Laws
Attachments: T475.patch
I'm trying to retrieve rows from a database via the relational DAS. When I
run my test prgram I get
Exception in thread main java.lang.ClassCastException:
org.eclipse.emf.ecore.util.EcoreEList$Dynamic incompatible with
commonj.sdo.DataObject
at
org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:322)
at
org.apache.tuscany.sdo.interop.SDOInterop.testReadAndWriteRelationalDB2(SDOInterop.java)
at org.apache.tuscany.sdo.interop.SDOInterop.main(SDOInterop.java:136)
The code looks like.
CommandGroup commandGroup =
CommandGroup.FACTORY.createCommandGroup(getClass().getResourceAsStream(interopconfig-db2.xml));
Command read = commandGroup.getCommand(all type);
DataObject root = read.executeQuery();
DataObject firstRow = root.getDataObject(alltype[0]);
Now I expect to get a firstRow DataObject back. Indeed
DataObjectImpl.getDataObject() casts the return to a DataObject
public DataObject getDataObject(String path)
{
return (DataObject)get(path);
}
However the the DataObjectUtil.get() operation creates an Accessor and calls
getAndRecycle
public static Object get(DataObject dataObject, String path)
{
Property property = dataObject.getType().getProperty(path);
if (property != null) {
return dataObject.get(property);
} else {
return Accessor.create((EObject)dataObject, path).getAndRecyle();
}
}
getAndRecycle call get which, because I have specified a 0 index, just
returns the value which happens to be of type EcoreEList$Dynamic
So while I may have an error in my code somewhere or it might not be
retrieving any data from the database a class cast exception inside of SDO
doesn't seem like the correct way to tell me.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ runtime - build error on Linux
Geoffrey Winn wrote: Jean-Sebastian, Hi. I don't have access to an RHEL 4 system. Could you try one thing for me? The error you report is coming from calls like dor-setLong(long, 0x); and the signature for the setLong method specifies int64 for the second argument. I'm wondering if the problem is that the 0x value is being treated as a 32 bit constant rather than 64. Could you try appending LL to the constant value eg dor-setLong(long, 0xLL); If I read the docs correctly that will specify that the constant is 64 bit. Thanks in advance, Geoff. I finally found a moment to try this today. Good news: adding LL fixes the problem. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version number in pom.xml
I think M2 is better than 0.9 because it simply says that this is the next milestone after M1, rather than carrying some kind of 90% complete implication. However I'm not quite sure about the 1.0 designation at the beginning. This seems to imply that when incubation is complete, we will immediately deliver a 1.0 release. This is certainly one possible (and desirable) scenario, but I can imagine other circumstances that might make us choose to do a post-incubation release at some level that is less than 1.0. For example, what if at the time we exit incubation, the current published SCA spec is only at a 0.95 level? Might we choose to deliver a 0.95 Tuscany release matching that spec, and upgrade to a 1.0 release when the spec upgrades to 1.0 and we have matching code? I don't really want to get into a debate now about the probability of such a situation arising. But if there is even a small chance that we might not jump immediately from incubation to a 1.0 release, then I'd suggest using something like incubating-M2-SNAPSHOT to give us a bit more flexibility down the road. Simon Jean-Sebastien Delfino wrote: Daniel Kulp wrote: 1.0-incubating-M2-SNAPSHOT is probably the technical version number we should be using. It specifically states we are working on the snapshot version of 1.0-incubating-M2 which I assume will be the version we use when we release M2. Dan On Tuesday June 20 2006 12:29 pm, Jean-Sebastien Delfino wrote: We currently have versionincubating-M1/version in all our pom.xml files. What do you think we should use now? SNAPSHOT? 1.0-SNAPSHOT? 0.1-SNAPSHOT? Any opinions? This makes sense to me but what do others think? If I remember correctly at some point I had proposed 0.9 and some of us thought that a 0.9 version number could give false expectations in terms of stability/completeness. Are we running the same risk with a 1.0-incubating-M2? Or do you think that having -M2 at the end makes it clear that this will only be a Milestone release and not a 1.0 release? If there is no objections, I'll change the version numbers to 1.0-incubating-M2 on Thursday morning. -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SPI interfaces
In the new core2 API, component factory is no longer needed.
AtomicComponent contains the invocation chains and and is responsible
for creating invokers. Related to having WSDL or Java interface
types, one of the things we also did was separate proxy creation from
the wire so now you can invoke on RuntimeWire directly, while proxies
are created by a separate service. The presentation has some slides
on this that we didn't get to due to time constraints.
One issue that has come up is in both runtimes (core and core2) we
are using Method to represent invocations. This may cause issues
since a Java interface always has to be generated. One thing we could
look at is going to something more generic.
Jim
On Jun 21, 2006, at 2:07 AM, ant elder wrote:
+1
Where are you doing this and how can we start helping? A long time
ago I had
a go at something like this for the JavaScript component, the
interfaces it
had were along the lines of the ones below. probably a bit old now
with all
the other changes. One thing I found hard was having a nice way to
have
interfaces be either Java classes or WSDL portTypes particularly with
components invoking service references.
ComponentFactory {
Component createComponent(Component component);
}
Component {
ComponentDefinition getComponentDefinition();
Invoker createComponentInvoker(MapString, Object properties,
MapString, Reference references);
}
Invoker {
public Object invoke(String operationName, Object[] args);
}
ComponentDefinition {
Interface getInterface();
ListString getReferenceNames();
ListProperty getProperties();
String getInitOperationName();
String getDestroyOperationName();
}
Property {
String getName();
Object getDefaultValue();
boolean isRequired();
}
Reference {
Interface getInterface();
Object getProxy();
Invoker getInvoker();
}
Interface {
}
ClassInterface {
class[] getInterfaceClasses();
}
WSDLInterface {
String getNamespce();
String getPortTypeName();
Definition getDefinition();
}
...ant
On 6/21/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
I'm trying to implement the sample ruby extension and running into
some
issues.
I'm implementing an AtomicComponentContext (with the code in the head
stream) and also trying the equivalent AtomicComponent with some
of the
code in the sandbox. I want to be able to implement my extension
class
without having to depend on base Tuscany runtime implementation
classes,
so I'm just implementing the SPI interfaces.
Unless I missed something (and it's very possible since I don't
understand all the pieces yet) here's what I found:
- with the code in the head, my AtomicComponentContext needs to
implement 15 methods;
- with the code in the sandbox, I have to implement 25 methods.
And this is just one class, I'm not even implementing the builders or
invokers yet... I think that in both cases this is too much.
It looks like the experiment in the sandbox is attempting to
provide a
simpler programming model for these extensions by hiding some of the
complexity in base implementation classes, but I think it will be
better
to define a set of independent interfaces and make some of them
optional. In other words if my extension does not wish to
implement one
of the interfaces, then it just doesn't need to, and the runtime
should
assume some default behavior, instead of forcing me to implement
all the
25 methods...
Another thought is to allow the contract to be implemented with
multiple
objects specialized in each aspect instead of one big object with 25
methods.
As I'm going through the implementation of the ruby component
implementation extension, I'm trying to come up with a short list of
requirements and methods that I think we really need to implement,
and
with that list I'd like us to prototype simpler SPI interfaces. If
anybody is interested in helping, please feel free to jump in, it
would
really be great if we could do a binding extension in parallel,
and also
if the people who actually developed some of the existing extensions
could come up with the requirements they've seen in terms of SPI and
proposals to improve our extensibility story.
Thanks,
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-423) open content tests for generated classes
[ http://issues.apache.org/jira/browse/TUSCANY-423?page=all ] Kelvin Goodson updated TUSCANY-423: --- Attachment: T423+T470test_rollup.patch I was going to add my test code that proved that Jira Tuscany-470 was working as designed, but that JIRA is closed. The T470 test code I wrote builds upon the patch that is waiting to be applied under this JIRA (423), so I am attaching a rollup patch which contains all the new tests of the exisiting attached ocGenTests.patch file, + the new test for XPath referencing through open content properties developed whilst looking at T470. Please apply only this latter attachment (T423+T470test_rollup.patch) and ignore the ocGenTests.patch file. open content tests for generated classes Key: TUSCANY-423 URL: http://issues.apache.org/jira/browse/TUSCANY-423 Project: Tuscany Type: Test Components: Java SDO Implementation Versions: Java-Mx Reporter: Kelvin Goodson Priority: Minor Attachments: T423+T470test_rollup.patch, ocGenTests.patch I will attach a patch with some tests that have come about from my playing with open content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version number in pom.xml
Simon, Unfortunately, with the way Maven 2 works, if you don't have a version number at the beginning, you are asking for problems, especially for maven plugins. I've gone over this with the Maven folks a couple times now. The maven version numbers should ALWAYS be: #.#[.#]*[-text][-SNAPSHOT] or #.#[.#]-# (for updates to a release), like 1.0-1 or something. After thinking about it, I might suggest: 0.92-incubating-M2-SNAPSHOT where we use the SCA version number. That would kind of keep us from going to a 1.0 release until the spec is 1.0. I'm not sure if that's a bad thing or not. Dan On Wednesday June 21 2006 5:12 am, Simon Nash wrote: I think M2 is better than 0.9 because it simply says that this is the next milestone after M1, rather than carrying some kind of 90% complete implication. However I'm not quite sure about the 1.0 designation at the beginning. This seems to imply that when incubation is complete, we will immediately deliver a 1.0 release. This is certainly one possible (and desirable) scenario, but I can imagine other circumstances that might make us choose to do a post-incubation release at some level that is less than 1.0. For example, what if at the time we exit incubation, the current published SCA spec is only at a 0.95 level? Might we choose to deliver a 0.95 Tuscany release matching that spec, and upgrade to a 1.0 release when the spec upgrades to 1.0 and we have matching code? I don't really want to get into a debate now about the probability of such a situation arising. But if there is even a small chance that we might not jump immediately from incubation to a 1.0 release, then I'd suggest using something like incubating-M2-SNAPSHOT to give us a bit more flexibility down the road. Simon Jean-Sebastien Delfino wrote: Daniel Kulp wrote: 1.0-incubating-M2-SNAPSHOT is probably the technical version number we should be using. It specifically states we are working on the snapshot version of 1.0-incubating-M2 which I assume will be the version we use when we release M2. Dan On Tuesday June 20 2006 12:29 pm, Jean-Sebastien Delfino wrote: We currently have versionincubating-M1/version in all our pom.xml files. What do you think we should use now? SNAPSHOT? 1.0-SNAPSHOT? 0.1-SNAPSHOT? Any opinions? This makes sense to me but what do others think? If I remember correctly at some point I had proposed 0.9 and some of us thought that a 0.9 version number could give false expectations in terms of stability/completeness. Are we running the same risk with a 1.0-incubating-M2? Or do you think that having -M2 at the end makes it clear that this will only be a Milestone release and not a 1.0 release? If there is no objections, I'll change the version numbers to 1.0-incubating-M2 on Thursday morning. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-485) Missing xsd element in Tuscany-model.config file causes failure.
Missing xsd element in Tuscany-model.config file causes failure. -- Key: TUSCANY-485 URL: http://issues.apache.org/jira/browse/TUSCANY-485 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Reporter: Andrew Borley Priority: Minor If the xsd element is missed out of the Tuscany-model.config file an exception is thrown in ModelLoader::loadModuleFile with message: Invalid path:xsd/file. There may be no xsd files needed by the component, so we should probably be able to cope with this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any recursive composition sample?
On Jun 21, 2006, at 4:48 AM, cr22rc wrote: I'd like to help out on this and also the SPI analysis work you spoke of. Per the samples I had some thoughts that instead of just jumping straight to them is to add some more for baby steps in bring up. For example I'd like to see as starters in a J2SE environment the very simplest of composite with a Java component being loaded with the minimal amount of any wiring. I was wondering if I could use the initeager to somehow just have it instantiate a single instance that would you guessed it display hello world to console. I can take a look at doing this over the next few days in core2. Not sure if that is possible still learning some of this code. If we could get that to work first it would be great for all to use in a debugger to see the system boot strap it self. From there move on to converting the other samples. I think with bigbank we'll need to maybe think (brain storm) some on how to best exhibit the new recursive model. BigBank I think needs a re-write. When we originally wrote it in the spec group, the intention was to show the benefits and ease-of-use for SCA. Since then, it's kind of evolved into a petstore-type application that pulls in SDO and DAS. While I like those technologies, I'd like to see BigBank put on a diet so that there is a version people just interested in SCA can reference. Also, I'd like it to show more of the value-add around SCA as opposed to just invoking a web service since people outside of the SCA collaboration and Tuscany project have questioned me as to why Tuscany is needed if there are things like: http://seam.demo.jboss.com/home.seam. For me, the value in SCA is around assembly, policies and conversations, so showcase features could be: - dynamic re-wiring - switching transport protocols - conversations and non-blocking/async behavior - introduction of policy I think we'll want to show both composites being used as components and using composites through inclusion (aka fragments). I also think we need to eventually start showing some more examples with some interesting complex properties being set. Jean-Sebastien Delfino wrote: The last few weeks we've been talking about composites and recursive composition so much... and today I looked for a sample showing the new recursive composition model in our whole code base, including the head and our various sandboxes... and couldn't find any. I think it'll help all of us get our heads around this new model if we can see a few samples. Could somebody point me to a recursive composition sample if we have any and I missed it? Is anybody curious and interested in trying to port a few of our existing samples to the new recursive model? I guess the update of the SCA spec describing the recursive composition is not public yet, but the materials presented at JavaOne are public as far as I know, and should be sufficient to develop samples leveraging the new recursive composition model. If anybody is interested in developing sample scenarios that demonstrate the value of the recursive composition, please let me know, we can work together on this. I'd like to start this activity in parallel with the SPI analysis work that I'm currently doing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any recursive composition sample?
I pretty much agree with most of this, but I like the general pattern of having the simplest of samples to show a particular technology or some aspect of a technology and then something that brings it all together which was for M1 BigBank. You may have a point that this is too much for one sample, but generally these three technologies look in the minds of people to be sort of separate and I still like the idea of a sample that shows them all coming together. Jim Marino wrote: On Jun 21, 2006, at 4:48 AM, cr22rc wrote: I'd like to help out on this and also the SPI analysis work you spoke of. Per the samples I had some thoughts that instead of just jumping straight to them is to add some more for baby steps in bring up. For example I'd like to see as starters in a J2SE environment the very simplest of composite with a Java component being loaded with the minimal amount of any wiring. I was wondering if I could use the initeager to somehow just have it instantiate a single instance that would you guessed it display hello world to console. I can take a look at doing this over the next few days in core2. Not sure if that is possible still learning some of this code. If we could get that to work first it would be great for all to use in a debugger to see the system boot strap it self. From there move on to converting the other samples. I think with bigbank we'll need to maybe think (brain storm) some on how to best exhibit the new recursive model. BigBank I think needs a re-write. When we originally wrote it in the spec group, the intention was to show the benefits and ease-of-use for SCA. Since then, it's kind of evolved into a petstore-type application that pulls in SDO and DAS. While I like those technologies, I'd like to see BigBank put on a diet so that there is a version people just interested in SCA can reference. Also, I'd like it to show more of the value-add around SCA as opposed to just invoking a web service since people outside of the SCA collaboration and Tuscany project have questioned me as to why Tuscany is needed if there are things like: http://seam.demo.jboss.com/home.seam. For me, the value in SCA is around assembly, policies and conversations, so showcase features could be: - dynamic re-wiring - switching transport protocols - conversations and non-blocking/async behavior - introduction of policy I think we'll want to show both composites being used as components and using composites through inclusion (aka fragments). I also think we need to eventually start showing some more examples with some interesting complex properties being set. Jean-Sebastien Delfino wrote: The last few weeks we've been talking about composites and recursive composition so much... and today I looked for a sample showing the new recursive composition model in our whole code base, including the head and our various sandboxes... and couldn't find any. I think it'll help all of us get our heads around this new model if we can see a few samples. Could somebody point me to a recursive composition sample if we have any and I missed it? Is anybody curious and interested in trying to port a few of our existing samples to the new recursive model? I guess the update of the SCA spec describing the recursive composition is not public yet, but the materials presented at JavaOne are public as far as I know, and should be sufficient to develop samples leveraging the new recursive composition model. If anybody is interested in developing sample scenarios that demonstrate the value of the recursive composition, please let me know, we can work together on this. I'd like to start this activity in parallel with the SPI analysis work that I'm currently doing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-485) Missing xsd element in Tuscany-model.config file causes failure.
[ http://issues.apache.org/jira/browse/TUSCANY-485?page=comments#action_12417133 ] Andrew Borley commented on TUSCANY-485: --- This is a duplicate of TUSCANY-465 - sorry! Missing xsd element in Tuscany-model.config file causes failure. -- Key: TUSCANY-485 URL: http://issues.apache.org/jira/browse/TUSCANY-485 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Reporter: Andrew Borley Priority: Minor If the xsd element is missed out of the Tuscany-model.config file an exception is thrown in ModelLoader::loadModuleFile with message: Invalid path:xsd/file. There may be no xsd files needed by the component, so we should probably be able to cope with this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-486) Document deployment use of Axis2C WS EntryPoint
[ http://issues.apache.org/jira/browse/TUSCANY-486?page=all ] Andrew Borley updated TUSCANY-486: -- Attachment: WS_ENTRYPOINT.txt Initial version of this documentation. Covers: Defining an SCA Module with a WS EntryPoint Deploying a new service in Axis2C XML Schema type to C++ type mapping Notes on supported WS styles message types Document deployment use of Axis2C WS EntryPoint - Key: TUSCANY-486 URL: http://issues.apache.org/jira/browse/TUSCANY-486 Project: Tuscany Type: Task Components: C++ SCA Versions: Cpp-M1 Reporter: Andrew Borley Attachments: WS_ENTRYPOINT.txt Need documentation explaining how to expose an SCA component as a WS EntryPoint in Axis2C -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about XSD substitution support in SDO2
Sequence is the only public API today to SET substitution element instance and GET the substitution element instance. I am proposing mapping substituted property to Sequence, e.g. implementation property returns Sequence INSTEAD OF a normal type. If we can do that, SDO users are enabled to set and get substitution element instance which can't be done today. After we do that, we can hide/discard implementationGroup or just delegate implementation to implementationGroup. I guess the proposal needs to change the spec, unfortunately. -- Sincerely Yang ZHONG
[jira] Created: (TUSCANY-487) Java 5.0 dependency in StAX2SAXAdapter.java
Java 5.0 dependency in StAX2SAXAdapter.java --- Key: TUSCANY-487 URL: http://issues.apache.org/jira/browse/TUSCANY-487 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: John Colgrave Priority: Minor The first line of the getAttributes method in StAX2SAXAdapter.java is an assert which can only be compiled in Java 5.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about XSD substitution support in SDO2
I'm a fan of not only richness, but also simpleness. Let me refine my proposal a little bit not to break the simpleness of the Programming Model. We can still return normal type for get/set( implementation) for users don't care substitution element instance and keep the simple PM. At the same time, we can make getSequence( implementation) to return a Sequence for users to set/get substitution element instance. The new proposal won't change the spec a lot except for the new feature/support appending. On 6/21/06, Yang ZHONG [EMAIL PROTECTED] wrote: Sequence is the only public API today to SET substitution element instance and GET the substitution element instance. I am proposing mapping substituted property to Sequence, e.g. implementation property returns Sequence INSTEAD OF a normal type. If we can do that, SDO users are enabled to set and get substitution element instance which can't be done today. After we do that, we can hide/discard implementationGroup or just delegate implementation to implementationGroup. I guess the proposal needs to change the spec, unfortunately. -- Sincerely Yang ZHONG -- Sincerely Yang ZHONG
[jira] Updated: (TUSCANY-482) Potential trap in SCA web service entry point
[ http://issues.apache.org/jira/browse/TUSCANY-482?page=all ] Ed Slattery updated TUSCANY-482: Attachment: service_robustness.patch Patch to fix the wsdl useage, and also the case where the proxy is not able to find an implementation Potential trap in SCA web service entry point - Key: TUSCANY-482 URL: http://issues.apache.org/jira/browse/TUSCANY-482 Project: Tuscany Type: Bug Components: C++ SCA Environment: all Reporter: Ed Slattery Attachments: service_robustness.patch In EntryPointProxy - at or around line 108. The invoke method gets a wsdl, and uses it as a pointer. If the wsdl doesnt exist, this returns zero and causes a crash of the axis server. It would be better to fail in some more tidy way, and log the error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-487) Java 5.0 dependency in StAX2SAXAdapter.java
[ http://issues.apache.org/jira/browse/TUSCANY-487?page=comments#action_12417142 ] Yang ZHONG commented on TUSCANY-487: assert is introduced by 1.4, you may want to get the latest 1.4 compiler and set the compliance to 1.4 or above. Java 5.0 dependency in StAX2SAXAdapter.java --- Key: TUSCANY-487 URL: http://issues.apache.org/jira/browse/TUSCANY-487 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: John Colgrave Priority: Minor The first line of the getAttributes method in StAX2SAXAdapter.java is an assert which can only be compiled in Java 5.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about XSD substitution support in SDO2
It's not a bad idea, given the current SDO API. But, let me tell you the direction that the spec seems to be headed with Sequences. There is currently a proposal to deprecate the getSequence(String), getSequence(int) and getSequence(Property) methods. The feeling is that getSequence(), which returns the mixed-content will be the only SDO Sequence API. If that goes through, then we would need to either a) say that SDO doesn't provide support for the things that EMF uses FeatureMap (Sequence) properties for, or b) we need to provide methods somewhere (in maybe XSDHelper) to access the required information. Assuming option b is necessary, maybe your suggestion could be handled with a method on XSDHelper that returns the substitution property - for example: DataObject myObject = ... Property substitution = XSDHelper.INSTANCE.getSubstitionProperty(myObject, myObject.getProperty(implementation)); Thoughts? Does anyone else have an opinion on this issue? Frank. Yang ZHONG [EMAIL PROTECTED] wrote on 06/21/2006 12:05:06 PM: I'm a fan of not only richness, but also simpleness. Let me refine my proposal a little bit not to break the simpleness of the Programming Model. We can still return normal type for get/set( implementation) for users don't care substitution element instance and keep the simple PM. At the same time, we can make getSequence( implementation) to return a Sequence for users to set/get substitution element instance. The new proposal won't change the spec a lot except for the new feature/support appending. On 6/21/06, Yang ZHONG [EMAIL PROTECTED] wrote: Sequence is the only public API today to SET substitution element instance and GET the substitution element instance. I am proposing mapping substituted property to Sequence, e.g. implementation property returns Sequence INSTEAD OF a normal type. If we can do that, SDO users are enabled to set and get substitution element instance which can't be done today. After we do that, we can hide/discard implementationGroup or just delegate implementation to implementationGroup. I guess the proposal needs to change the spec, unfortunately. -- Sincerely Yang ZHONG -- Sincerely Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Introduction
Hello Darius, I am looking forward to seeing your patch for T-250. Attach it to the JIRA when you have something ready and I will take a look. Thanks! --Kevin Darius Dejesus wrote: Still getting used to this, so sorry if it is a repeat... Hello Tuscany Folks, My name is Darius DeJesus, I'm an Intern from R.I.T. in NY,working for the summer, and look forward to helping with the Tuscany Project. I've already started looking into some JIRA's, and if no one else is currently assigned to it, I'd like to work on Tuscany-250. That's all for now, and I look forward to this experience. -D - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] More improvements to SDO/StAX support
Frank Budinsky wrote: I can't seem to find the cycles to look at this right now, so in the interest of getting something going here can some other StAX-savvy committer (maybe Jeremy) take a look at Raymond's patch and commit it if it looks like a reasonable start.? We can then look at addressing the issues (e.g., substitution group, which involves a spec discussion) later. Had a weather eye on this so sure - I'll try and get to this today. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: downloads
Tom, Welcome to Tuscany. I am not aware of any way to figure out the number of downloads. Hopefully you have downloaded Tuscany by now and can share your experience. We are looking for feedback as well as help :) You can find the list of known issues on this page http://issues.apache.org/jira/browse/TUSCANY You can also find how information on how to submit patches on this page http://incubator.apache.org/tuscany/patches.html Please don't hestiate to post any questions you might have. Haleh On 6/13/06, Tom Gould [EMAIL PROTECTED] wrote: Hi: I am new to Tuscany and open source in general. I have yet to download the latest and greatest software, but I intend on doing so shortly. Prior to downloading, I am wondering if there is a way to determine how many people have downloaded the software as of yet and what types of issues (if any) they have come across? thanks tg
Re: M1 release post-mortem discussion
This thread started with an intention to do a post-mortem on M1. Is there something we can learn from and improve on for subsequent releases? Thoughts? On 6/13/06, cr22rc [EMAIL PROTECTED] wrote: Not sure if this can help and I didn't thoroughly test it, but checked in tuscany/sandbox/cr22rc/buildm2repo/buildm2repo.zip http://svn.apache.org/viewvc/incubator/tuscany/sandbox/cr22rc/buildm2repo/buildm2repo.zip?view=markuppathrev=413899 Which if you unzip in the binary distro has poms and a shell and bat file that issue maven commands to add to your local repo. Once again I ran them and they said build successful.. but that's all I did. Jean-Sebastien Delfino wrote: [snip] Daniel Kulp wrote: Anyone have a preference as to where to deploy the M1 stuff? I think Sebastian had deployed something to his public_html dir. Does it make sense to just put the released stuff there as well for now? (until M2) The M1 jars are at http://people.apache.org/~jsdelfino/maven2/. You may be able to use this until we find a better place and a better version numbering scheme. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about XSD substitution support in SDO2
Great idea, at least I am happy as long as we offer both richness and simpleness to SDO users, regarding substitution. On 6/21/06, Frank Budinsky [EMAIL PROTECTED] wrote: It's not a bad idea, given the current SDO API. But, let me tell you the direction that the spec seems to be headed with Sequences. There is currently a proposal to deprecate the getSequence(String), getSequence(int) and getSequence(Property) methods. The feeling is that getSequence(), which returns the mixed-content will be the only SDO Sequence API. If that goes through, then we would need to either a) say that SDO doesn't provide support for the things that EMF uses FeatureMap (Sequence) properties for, or b) we need to provide methods somewhere (in maybe XSDHelper) to access the required information. Assuming option b is necessary, maybe your suggestion could be handled with a method on XSDHelper that returns the substitution property - for example: DataObject myObject = ... Property substitution = XSDHelper.INSTANCE.getSubstitionProperty(myObject, myObject.getProperty(implementation)); Thoughts? Does anyone else have an opinion on this issue? Frank. Yang ZHONG [EMAIL PROTECTED] wrote on 06/21/2006 12:05:06 PM: I'm a fan of not only richness, but also simpleness. Let me refine my proposal a little bit not to break the simpleness of the Programming Model. We can still return normal type for get/set( implementation) for users don't care substitution element instance and keep the simple PM. At the same time, we can make getSequence( implementation) to return a Sequence for users to set/get substitution element instance. The new proposal won't change the spec a lot except for the new feature/support appending. On 6/21/06, Yang ZHONG [EMAIL PROTECTED] wrote: Sequence is the only public API today to SET substitution element instance and GET the substitution element instance. I am proposing mapping substituted property to Sequence, e.g. implementation property returns Sequence INSTEAD OF a normal type. If we can do that, SDO users are enabled to set and get substitution element instance which can't be done today. After we do that, we can hide/discard implementationGroup or just delegate implementation to implementationGroup. I guess the proposal needs to change the spec, unfortunately. -- Sincerely Yang ZHONG -- Sincerely Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sincerely Yang ZHONG
Re: Version number in pom.xml
[snip] Daniel Kulp wrote: Simon, Unfortunately, with the way Maven 2 works, if you don't have a version number at the beginning, you are asking for problems, especially for maven plugins. I've gone over this with the Maven folks a couple times now. The maven version numbers should ALWAYS be: #.#[.#]*[-text][-SNAPSHOT] or #.#[.#]-# (for updates to a release), like 1.0-1 or something. After thinking about it, I might suggest: 0.92-incubating-M2-SNAPSHOT where we use the SCA version number. That would kind of keep us from going to a 1.0 release until the spec is 1.0. I'm not sure if that's a bad thing or not. Dan I like that 0.92-incubating-M2-SNAPSHOT. If there's no objection I'll change incubating-M1 to that tomorrow morning. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version number in pom.xml
Daniel Kulp wrote: Simon, Unfortunately, with the way Maven 2 works, if you don't have a version number at the beginning, you are asking for problems, especially for maven plugins. I've gone over this with the Maven folks a couple times now. The maven version numbers should ALWAYS be: #.#[.#]*[-text][-SNAPSHOT] or #.#[.#]-# (for updates to a release), like 1.0-1 or something. After thinking about it, I might suggest: 0.92-incubating-M2-SNAPSHOT where we use the SCA version number. That would kind of keep us from going to a 1.0 release until the spec is 1.0. I'm not sure if that's a bad thing or not. Sounds like the maven requirements set the format and we just need to pick the version number and whether it's all #.# or if we have Mx text in it as well. I think there is a good chance that we will deliver multiple releases at the same version level of the spec (especially when the spec matures and updates more slowly). As a result, I don't think that we should pin the version of our release to the spec number. Most projects have a [major].[minor].[bugfix] type version number with rules for bumping major and minor numbers based on compatibility between releases. We should do something similar. There is also the don't use 1.X or x.0 of any software rule, so perhaps we should get beyond 1.0 as soon as possible. I remember people not wanting to use OpenEJB just because it had a 0.9 version number - they kept waiting for 1.0 to come out. In light of all that, I think we should go with the basic 1.0-incubating-SNAPSHOT for the Tuscany implementations. Having said that I do think tracking the spec version would be useful in the org.osoa jars (sdo and sca APIs). I would suggest for them we go with 0.92-incubating-SNAPSHOT based on the revision number of the spec document. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-487) Java 5.0 dependency in StAX2SAXAdapter.java
[ http://issues.apache.org/jira/browse/TUSCANY-487?page=comments#action_12417156 ] John Colgrave commented on TUSCANY-487: --- I was using Eclipse 3.2RC4 and I did not realise that I had to restart Eclipse before the changes in compliance would take effect, even when doing a clean of all my projects. Having set the compliance to 1.4 and restarted I can compile the file. Sorry to have wasted your time. Java 5.0 dependency in StAX2SAXAdapter.java --- Key: TUSCANY-487 URL: http://issues.apache.org/jira/browse/TUSCANY-487 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: John Colgrave Priority: Minor The first line of the getAttributes method in StAX2SAXAdapter.java is an assert which can only be compiled in Java 5.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-487) Java 5.0 dependency in StAX2SAXAdapter.java
Hi, Even the assert won't be an issue, there are more things to check. I have one case at least. Now we have references to javax.xml.stream.XMLStreamReader which depends on javax.xml.namespace.NamespaceContext from JSE 5.0. I guess the best approach is to spin the StAX feature off as a separate project. Thanks, Raymond - Original Message - From: John Colgrave (JIRA) tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Sent: Wednesday, June 21, 2006 11:38 AM Subject: [jira] Commented: (TUSCANY-487) Java 5.0 dependency in StAX2SAXAdapter.java [ http://issues.apache.org/jira/browse/TUSCANY-487?page=comments#action_12417156 ] John Colgrave commented on TUSCANY-487: --- I was using Eclipse 3.2RC4 and I did not realise that I had to restart Eclipse before the changes in compliance would take effect, even when doing a clean of all my projects. Having set the compliance to 1.4 and restarted I can compile the file. Sorry to have wasted your time. Java 5.0 dependency in StAX2SAXAdapter.java --- Key: TUSCANY-487 URL: http://issues.apache.org/jira/browse/TUSCANY-487 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: John Colgrave Priority: Minor The first line of the getAttributes method in StAX2SAXAdapter.java is an assert which can only be compiled in Java 5.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-487) Java 5.0 dependency in StAX2SAXAdapter.java
Raymond Feng wrote: Now we have references to javax.xml.stream.XMLStreamReader which depends on javax.xml.namespace.NamespaceContext from JSE 5.0. I guess the best approach is to spin the StAX feature off as a separate project. I think NamespaceContext is also available in some of the optional libraries for 1.4 (one of the web-services pack thingies). Those libraries moved in to the Java5 API but I think they are available separately as well with 1.4 level compatibility - we may just need to add the right dependencies. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] More improvements to SDO/StAX support
Jeremy Boynes wrote: Frank Budinsky wrote: I can't seem to find the cycles to look at this right now, so in the interest of getting something going here can some other StAX-savvy committer (maybe Jeremy) take a look at Raymond's patch and commit it if it looks like a reasonable start.? We can then look at addressing the issues (e.g., substitution group, which involves a spec discussion) later. I had a first look and this really helps - thanks Raymond. Before I apply it, there are a few areas marked FIXME or HACK - are those permanent hacks or should we expect an update soon? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SPI interfaces
Hi,
I guess one of the concerns is that some of the base classes create
additional contracts which are not captured by the interfaces. It ends up
that the extension developers have to understand more.
Let's use the StAXElementLoader and LoaderExtension as an example.
Interface StAXElementLoader only requires the load method to be
implemented while LoaderExtension defines a contract on how a
StAXElementLoader register/deregister with the LoaderRegistry. This is
achieved by java annotations.
For this particular case, I can see two ways to get an extension picked up
by the runtime: declarative or programmatic. Some further questions will be:
1) Should the extension developers have a choice to use either java
annotations or external XML configuration?
2) Should the extension metadata (for example, the XML element name that a
loader can handle) be captured in a model and java annotation is just a
convenient way to supply the value?
Thanks,
Raymond
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, June 21, 2006 2:08 AM
Subject: Re: Tuscany SPI interfaces
Jim Marino wrote:
I think you missed something. With core2, most people will extend from
the helper abstract classes in the SPI extension package (this was also
the case with the previous core). For example:
I didn't miss this class, as I said that's exactly what I'm trying to
avoid. I want to implement the SPI interfaces without having to extend
base implementation classes.
public class FooAtomicComponent extends AtomicComponentExtensionObject{
public FooAtomicComponent(String name, CompositeComponent? parent,
ScopeContainer scopeContainer, WireService wireService) {
super(name, parent, scopeContainer, wireService);
}
public Object getServiceInstance() throws TargetException {
return null;
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws TargetException
{
return null;
}
public ListClass? getServiceInterfaces() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName, Method
operation) {
return null;
}
}
I generally don't like to count methods without looking at what they do
(e.g. some could just be setter/getter types). The above class contains 5
methods, which I believe are reasonable and we don't want to separate
out. Invoker is very simple too:
- Two methods to invoke, one for message invocations, and one for raw
payloads. Generally, the first will just pull the payload and invoke the
second
- A setter/getter pair for whether the invocation is cacheable
- A boolean if the invoker can be optimized away and the target can be
called through straight invocation without a proxy. Generally false.
- A clone method
The Spring and Groovy samples in the sandbox demonstrate both of these.
Jim
On Jun 21, 2006, at 1:37 AM, Jean-Sebastien Delfino wrote:
I'm trying to implement the sample ruby extension and running into some
issues.
I'm implementing an AtomicComponentContext (with the code in the head
stream) and also trying the equivalent AtomicComponent with some of the
code in the sandbox. I want to be able to implement my extension class
without having to depend on base Tuscany runtime implementation classes,
so I'm just implementing the SPI interfaces.
Unless I missed something (and it's very possible since I don't
understand all the pieces yet) here's what I found:
- with the code in the head, my AtomicComponentContext needs to
implement 15 methods;
- with the code in the sandbox, I have to implement 25 methods.
And this is just one class, I'm not even implementing the builders or
invokers yet... I think that in both cases this is too much.
It looks like the experiment in the sandbox is attempting to provide a
simpler programming model for these extensions by hiding some of the
complexity in base implementation classes, but I think it will be better
to define a set of independent interfaces and make some of them
optional. In other words if my extension does not wish to implement one
of the interfaces, then it just doesn't need to, and the runtime should
assume some default behavior, instead of forcing me to implement all the
25 methods...
Another thought is to allow the contract to be implemented with multiple
objects specialized in each aspect instead of one big object with 25
methods.
As I'm going through the implementation of the ruby component
implementation extension, I'm trying to come up with a short list of
requirements and methods that I think we really need to implement, and
with that list I'd like us to prototype simpler SPI interfaces. If
anybody is interested in helping, please feel free to jump in, it would
really be great if we could do a binding extension in parallel, and also
if
Re: Any recursive composition sample?
Yea that sounds good in terms of the really simple samples. I'd like to have a slim BigBank that just shows SCA though since I think it is important that people realize they can pick and choose technologies. I probably imagine SDO and DAS would say the same thing about SCA too. Jim On Jun 21, 2006, at 7:55 AM, cr22rc wrote: I pretty much agree with most of this, but I like the general pattern of having the simplest of samples to show a particular technology or some aspect of a technology and then something that brings it all together which was for M1 BigBank. You may have a point that this is too much for one sample, but generally these three technologies look in the minds of people to be sort of separate and I still like the idea of a sample that shows them all coming together. Jim Marino wrote: On Jun 21, 2006, at 4:48 AM, cr22rc wrote: I'd like to help out on this and also the SPI analysis work you spoke of. Per the samples I had some thoughts that instead of just jumping straight to them is to add some more for baby steps in bring up. For example I'd like to see as starters in a J2SE environment the very simplest of composite with a Java component being loaded with the minimal amount of any wiring. I was wondering if I could use the initeager to somehow just have it instantiate a single instance that would you guessed it display hello world to console. I can take a look at doing this over the next few days in core2. Not sure if that is possible still learning some of this code. If we could get that to work first it would be great for all to use in a debugger to see the system boot strap it self. From there move on to converting the other samples. I think with bigbank we'll need to maybe think (brain storm) some on how to best exhibit the new recursive model. BigBank I think needs a re-write. When we originally wrote it in the spec group, the intention was to show the benefits and ease-of- use for SCA. Since then, it's kind of evolved into a petstore-type application that pulls in SDO and DAS. While I like those technologies, I'd like to see BigBank put on a diet so that there is a version people just interested in SCA can reference. Also, I'd like it to show more of the value-add around SCA as opposed to just invoking a web service since people outside of the SCA collaboration and Tuscany project have questioned me as to why Tuscany is needed if there are things like: http:// seam.demo.jboss.com/home.seam. For me, the value in SCA is around assembly, policies and conversations, so showcase features could be: - dynamic re-wiring - switching transport protocols - conversations and non-blocking/async behavior - introduction of policy I think we'll want to show both composites being used as components and using composites through inclusion (aka fragments). I also think we need to eventually start showing some more examples with some interesting complex properties being set. Jean-Sebastien Delfino wrote: The last few weeks we've been talking about composites and recursive composition so much... and today I looked for a sample showing the new recursive composition model in our whole code base, including the head and our various sandboxes... and couldn't find any. I think it'll help all of us get our heads around this new model if we can see a few samples. Could somebody point me to a recursive composition sample if we have any and I missed it? Is anybody curious and interested in trying to port a few of our existing samples to the new recursive model? I guess the update of the SCA spec describing the recursive composition is not public yet, but the materials presented at JavaOne are public as far as I know, and should be sufficient to develop samples leveraging the new recursive composition model. If anybody is interested in developing sample scenarios that demonstrate the value of the recursive composition, please let me know, we can work together on this. I'd like to start this activity in parallel with the SPI analysis work that I'm currently doing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SPI interfaces
On Jun 21, 2006, at 1:30 PM, Raymond Feng wrote:
Hi,
I guess one of the concerns is that some of the base classes create
additional contracts which are not captured by the interfaces. It
ends up that the extension developers have to understand more.
Actually, I think they have to understand less. Using the base
classes, they do not need to worry about how to register and
deregister the loaders. Do you feel the loader extensions are too
complicated? If so, what would an easier one look like?
Let's use the StAXElementLoader and LoaderExtension as an
example. Interface StAXElementLoader only requires the load
method to be implemented while LoaderExtension defines a contract
on how a StAXElementLoader register/deregister with the
LoaderRegistry. This is achieved by java annotations.
For this particular case, I can see two ways to get an extension
picked up by the runtime: declarative or programmatic. Some further
questions will be:
1) Should the extension developers have a choice to use either java
annotations or external XML configuration?
2) Should the extension metadata (for example, the XML element name
that a loader can handle) be captured in a model and java
annotation is just a convenient way to supply the value?
We had decided the system service model would be based on annotations
a while back. I'm happy to revisit but I don't see any value in
allowing for external configuration of *component type* data. This is
also consistent with the SCA programming model which views external
component type metadata for Java CI POJOs to be primarily for
legacy code.
Thanks,
Raymond
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, June 21, 2006 2:08 AM
Subject: Re: Tuscany SPI interfaces
Jim Marino wrote:
I think you missed something. With core2, most people will extend
from the helper abstract classes in the SPI extension package
(this was also the case with the previous core). For example:
I didn't miss this class, as I said that's exactly what I'm trying
to avoid. I want to implement the SPI interfaces without having to
extend base implementation classes.
public class FooAtomicComponent extends
AtomicComponentExtensionObject{
public FooAtomicComponent(String name, CompositeComponent?
parent, ScopeContainer scopeContainer, WireService wireService) {
super(name, parent, scopeContainer, wireService);
}
public Object getServiceInstance() throws TargetException {
return null;
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws
TargetException {
return null;
}
public ListClass? getServiceInterfaces() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName,
Method operation) {
return null;
}
}
I generally don't like to count methods without looking at what
they do (e.g. some could just be setter/getter types). The above
class contains 5 methods, which I believe are reasonable and we
don't want to separate out. Invoker is very simple too:
- Two methods to invoke, one for message invocations, and one
for raw payloads. Generally, the first will just pull the payload
and invoke the second
- A setter/getter pair for whether the invocation is cacheable
- A boolean if the invoker can be optimized away and the target
can be called through straight invocation without a proxy.
Generally false.
- A clone method
The Spring and Groovy samples in the sandbox demonstrate both of
these.
Jim
On Jun 21, 2006, at 1:37 AM, Jean-Sebastien Delfino wrote:
I'm trying to implement the sample ruby extension and running
into some issues.
I'm implementing an AtomicComponentContext (with the code in the
head stream) and also trying the equivalent AtomicComponent with
some of the code in the sandbox. I want to be able to implement
my extension class without having to depend on base Tuscany
runtime implementation classes, so I'm just implementing the SPI
interfaces.
Unless I missed something (and it's very possible since I don't
understand all the pieces yet) here's what I found:
- with the code in the head, my AtomicComponentContext needs to
implement 15 methods;
- with the code in the sandbox, I have to implement 25 methods.
And this is just one class, I'm not even implementing the
builders or invokers yet... I think that in both cases this is
too much.
It looks like the experiment in the sandbox is attempting to
provide a simpler programming model for these extensions by
hiding some of the complexity in base implementation classes,
but I think it will be better to define a set of independent
interfaces and make some of them optional. In other words if my
extension does not wish to implement one of the interfaces, then
Re: Tuscany SPI interfaces
Raymond Feng wrote: Hi, I guess one of the concerns is that some of the base classes create additional contracts which are not captured by the interfaces. It ends up that the extension developers have to understand more. I agree that that would be a concern. That wasn't the intention here. The intention was that the base classes would aid the extension developer by providing default implementations of parts of the contract that would be common to typical extensions. The contracts should be fully defined by the interfaces; the extensions just happen to provide common implementations. Let's use the StAXElementLoader and LoaderExtension as an example. Interface StAXElementLoader only requires the load method to be implemented while LoaderExtension defines a contract on how a StAXElementLoader register/deregister with the LoaderRegistry. Not quite - there is a bi-directional contract between the LoaderRegistry and each StAXElementLoader. Implementations of StAXElementLoader register with a loader implementation using the LoaderRegistry interface; in turn the loader implementation calls back to registered StAXElementLoader implementations to handle an element in a XML stream. The contract is fully defined by the StAXElementLoader and LoaderRegistry interfaces. LoaderExtension does not add anything to that, it just provides a default implementation of a registration mechanism. This is achieved by java annotations. The way the default works is by using the lifecycle model from the SCA specification. It starts with the assumption that the extension will be provided as a composite. When the composite starts, the spec says that all components inside it designated as eager-init are automatically started. When a Java implementation is started, its init method must be called. Currently the only way an init method can be specified is via an @Init annotation; that's really an omission from the spec - there should be a way to specify that in the componentType sidefile as well. LoaderExtension uses this mechanism to register the component with the LoaderRegistry. As a provider, you just create your loader component as a subclass of LoaderExtension and include it in your composite - when the composite is started the init method is called and you automatically get registered with the LoaderRegistry; when your composite stops you are automatically unregistered. Of course, you don't have to use that. You can register a StAXElementLoader with the LoaderRegistry at any time just by calling its register method. The bootstrap code does this to register the primordial set of loaders. This ties back to the goals we had at the top. The contract here is specified in the SPI interfaces (LoaderRegistry and StAXElementLoader); the LoaderExtension base class provides a default implementation based on the SCA lifecycle model but it is just a default - you can register in any way supported by the LoaderRegistry contract. For this particular case, I can see two ways to get an extension picked up by the runtime: declarative or programmatic. Some further questions will be: 1) Should the extension developers have a choice to use either java annotations or external XML configuration? They should - the spec does not have mechanism to represent lifecycle in XML and that's a problem with the spec. That would be a good proposal to put forward. 2) Should the extension metadata (for example, the XML element name that a loader can handle) be captured in a model and java annotation is just a convenient way to supply the value? When a loader registers it explicitly specifies the element it wants to handle (it can actually register multiple times). This is part of the LoaderRegistry contract. The default implementation in LoaderExtension gets that from the sub-class by calling the getXMLType() abstract method. How that method determines the type is up to the extension developer. The implementations we have now just return the QName as that seemed really simple and they are typically specialized to handle one element. However, how they actually do it is down to them. It certainly would be possible for a more generic implementation to load it from a resource, an annotation, having it be injected as a SCA Property value, by parsing some other XML config file and so on. For example, I know you were working on a loader implementation that used SDO. Once you know the set of elements you want SDO to handle you would just need to register your loader with the LoaderRegistry for each of them. You probably would not want to use LoaderExtension at all. If I can help get this SDO loader integrated, please let me know (if you have posted a patch and I've forgotten please send me a pointer to it). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SPI interfaces
Hi, Jeremy. Thanks for the clarification. For the SDO loader, I have posted a patch before ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03792.html ). Please review and apply. Thank you for bringing up the issue on how we support more flexible loader registrations. There are some potential use cases: 1) Register a loader by one or more element QNames (In the SDO loader impl, a QName for now is required to create a loader instance for the given element) 2) Register a loader by one or more type QNames 3) Register a loader by one or more namespaces 4) Register a loader by wildcards against QNames Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 21, 2006 3:03 PM Subject: Re: Tuscany SPI interfaces Raymond Feng wrote: Hi, I guess one of the concerns is that some of the base classes create additional contracts which are not captured by the interfaces. It ends up that the extension developers have to understand more. I agree that that would be a concern. That wasn't the intention here. The intention was that the base classes would aid the extension developer by providing default implementations of parts of the contract that would be common to typical extensions. The contracts should be fully defined by the interfaces; the extensions just happen to provide common implementations. Let's use the StAXElementLoader and LoaderExtension as an example. Interface StAXElementLoader only requires the load method to be implemented while LoaderExtension defines a contract on how a StAXElementLoader register/deregister with the LoaderRegistry. Not quite - there is a bi-directional contract between the LoaderRegistry and each StAXElementLoader. Implementations of StAXElementLoader register with a loader implementation using the LoaderRegistry interface; in turn the loader implementation calls back to registered StAXElementLoader implementations to handle an element in a XML stream. The contract is fully defined by the StAXElementLoader and LoaderRegistry interfaces. LoaderExtension does not add anything to that, it just provides a default implementation of a registration mechanism. This is achieved by java annotations. The way the default works is by using the lifecycle model from the SCA specification. It starts with the assumption that the extension will be provided as a composite. When the composite starts, the spec says that all components inside it designated as eager-init are automatically started. When a Java implementation is started, its init method must be called. Currently the only way an init method can be specified is via an @Init annotation; that's really an omission from the spec - there should be a way to specify that in the componentType sidefile as well. LoaderExtension uses this mechanism to register the component with the LoaderRegistry. As a provider, you just create your loader component as a subclass of LoaderExtension and include it in your composite - when the composite is started the init method is called and you automatically get registered with the LoaderRegistry; when your composite stops you are automatically unregistered. Of course, you don't have to use that. You can register a StAXElementLoader with the LoaderRegistry at any time just by calling its register method. The bootstrap code does this to register the primordial set of loaders. This ties back to the goals we had at the top. The contract here is specified in the SPI interfaces (LoaderRegistry and StAXElementLoader); the LoaderExtension base class provides a default implementation based on the SCA lifecycle model but it is just a default - you can register in any way supported by the LoaderRegistry contract. For this particular case, I can see two ways to get an extension picked up by the runtime: declarative or programmatic. Some further questions will be: 1) Should the extension developers have a choice to use either java annotations or external XML configuration? They should - the spec does not have mechanism to represent lifecycle in XML and that's a problem with the spec. That would be a good proposal to put forward. 2) Should the extension metadata (for example, the XML element name that a loader can handle) be captured in a model and java annotation is just a convenient way to supply the value? When a loader registers it explicitly specifies the element it wants to handle (it can actually register multiple times). This is part of the LoaderRegistry contract. The default implementation in LoaderExtension gets that from the sub-class by calling the getXMLType() abstract method. How that method determines the type is up to the extension developer. The implementations we have now just return the QName as that seemed really simple and they are typically specialized to handle one element. However, how they actually do it is down to them. It certainly would be possible for a more generic
Re: Tuscany SPI interfaces
Raymond Feng wrote: Hi, Jeremy. Thanks for the clarification. For the SDO loader, I have posted a patch before ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03792.html ). Please review and apply. Thanks - I remember the type scoping discussion that followed and forgot the patch. I'll look at this later today. Thank you for bringing up the issue on how we support more flexible loader registrations. There are some potential use cases: 1) Register a loader by one or more element QNames (In the SDO loader impl, a QName for now is required to create a loader instance for the given element) I think we can do this now by providing your own init method or overriding start() and stop() in LoaderExtension - you just need to call register multiple times. Would that work or did you mean something else? 2) Register a loader by one or more type QNames We had talked about extending the Loader contract to support types (I'll see if that is in the patch you referred to above). I think the current approach would work for this as well - seem reasonable? Once we do this I would suggest we also rename StAXElementLoader to StAXLoader (as it will be able to handle more than just elements). 3) Register a loader by one or more namespaces 4) Register a loader by wildcards against QNames I'd like to discuss these a little more in conjunction with the extensibility story for SDO itself. I can see the value in SDO but this may be overkill for SCA. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] More improvements to SDO/StAX support
Thank for applying the patch.
Here's one more patch addressing several issues I discovered recently.
1) Fix a preifx/namespace mapping issue when a unqualified local element is
loaded
2) Fix a duplicate START_DOCUMENT issue with XMLDocumentStreamReader
3) Fix the problem with getTextLength() with XMLDocumentStreamReader and
enforce IllegalStateException for some methods per spec
For some TODO/FIXME/HACKs, we require SDO to provide addtional metadata so
that the XMLStreamReader for SDO can produce the exact XML document.It' work
in progress.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, June 21, 2006 12:05 PM
Subject: Re: [PATCH] More improvements to SDO/StAX support
Jeremy Boynes wrote:
Frank Budinsky wrote:
I can't seem to find the cycles to look at this right now, so in the
interest of getting something going here can some other StAX-savvy
committer (maybe Jeremy) take a look at Raymond's patch and commit it if
it looks like a reasonable start.? We can then look at addressing the
issues (e.g., substitution group, which involves a spec discussion)
later.
I had a first look and this really helps - thanks Raymond.
Before I apply it, there are a few areas marked FIXME or HACK - are
those permanent hacks or should we expect an update soon?
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index:
main/java/org/apache/tuscany/sdo/util/resource/DataObjectXMLStreamReader.java
===
---
main/java/org/apache/tuscany/sdo/util/resource/DataObjectXMLStreamReader.java
(revision 416102)
+++
main/java/org/apache/tuscany/sdo/util/resource/DataObjectXMLStreamReader.java
(working copy)
@@ -862,7 +862,7 @@
*/
private void registerNamespace(String prefix, String uri) {
if (!uri.equals(namespaceContext.getNamespaceURI(prefix))) {
-namespaceContext.put(prefix, uri);
+namespaceContext.registerMapping(prefix, uri);
declaredNamespaceMap.put(prefix, uri);
}
}
@@ -1301,7 +1301,7 @@
// namespaces are having no prefixes
if (!uri.equals(namespaceContext.getNamespaceURI(prefix))) {
// this namespace is not there. Need to declare it
-namespaceContext.put(prefix, uri);
+namespaceContext.registerMapping(prefix, uri);
}
}
@@ -1416,19 +1416,22 @@
protected static class DelegatingNamespaceContext implements
NamespaceContext {
private NamespaceContext parent;
-private Map nsMap = new HashMap();
+private Map prefixToNamespaceMapping = new HashMap();
public DelegatingNamespaceContext(NamespaceContext parent) {
super();
this.parent = parent;
-nsMap.put(xml, http://www.w3.org/XML/1998/namespace;);
-nsMap.put(xmlns, http://www.w3.org/2000/xmlns/;);
-nsMap.put(xsi, http://www.w3.org/2001/XMLSchema-instance;);
+prefixToNamespaceMapping.put(xml,
http://www.w3.org/XML/1998/namespace;);
+prefixToNamespaceMapping.put(xmlns,
http://www.w3.org/2000/xmlns/;);
+prefixToNamespaceMapping.put(xsi,
http://www.w3.org/2001/XMLSchema-instance;);
}
public String getNamespaceURI(String prefix) {
-String ns = (String) nsMap.get(prefix);
+if (prefix == null)
+throw new IllegalArgumentException(Prefix is null);
+
+String ns = (String) prefixToNamespaceMapping.get(prefix);
if (ns != null)
return ns;
else if (parent != null)
@@ -1440,7 +1443,7 @@
public String getPrefix(String nsURI) {
if (nsURI == null)
throw new IllegalArgumentException(Namespace is null);
-for (Iterator i = nsMap.entrySet().iterator(); i.hasNext();) {
+for (Iterator i = prefixToNamespaceMapping.entrySet().iterator();
i.hasNext();) {
Map.Entry entry = (Map.Entry) i.next();
if (entry.getValue().equals(nsURI)) {
return (String) entry.getKey();
@@ -1454,17 +1457,22 @@
public Iterator getPrefixes(String nsURI) {
List prefixList = new ArrayList();
-for (Iterator i = nsMap.entrySet().iterator(); i.hasNext();) {
+for (Iterator i = prefixToNamespaceMapping.entrySet().iterator();
i.hasNext();) {
Map.Entry entry = (Map.Entry) i.next();
if (entry.getValue().equals(nsURI)) {
prefixList.add(entry.getKey());
}
}
+if (parent != null) {
+for (Iterator i = parent.getPrefixes(nsURI); i.hasNext();) {
+prefixList.add(i.next());
Re: [PATCH] More improvements to SDO/StAX support
Raymond Feng wrote: Thank for applying the patch. Here's one more patch addressing several issues I discovered recently. 1) Fix a preifx/namespace mapping issue when a unqualified local element is loaded 2) Fix a duplicate START_DOCUMENT issue with XMLDocumentStreamReader 3) Fix the problem with getTextLength() with XMLDocumentStreamReader and enforce IllegalStateException for some methods per spec Thanks - applied. For some TODO/FIXME/HACKs, we require SDO to provide addtional metadata so that the XMLStreamReader for SDO can produce the exact XML document.It' work in progress. OK - hopefully Frank can pick those up. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-487) Java 5.0 dependency in StAX2SAXAdapter.java
Jeremy Boynes wrote: I think NamespaceContext is also available in some of the optional libraries for 1.4 (one of the web-services pack thingies). Those libraries moved in to the Java5 API but I think they are available separately as well with 1.4 level compatibility - we may just need to add the right dependencies. A version is also available from Geronimo: http://www.ibiblio.org/maven2/org/apache/geronimo/specs/geronimo-qname_1.1_spec/1.0/geronimo-qname_1.1_spec-1.0.jar contains both QName and NamespaceContext -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: move of container.java to core2
Jim Marino wrote: On Jun 20, 2006, at 10:37 AM, Jean-Sebastien Delfino wrote: Jim Marino wrote: In trying to eliminate reliance on core2 by container.java in the sandbox and have it only rely on the extensibility SPI, it occurred to me that this would mandate moving a lot of implementation classes from core2 into SPI. I believe having container.java as a separate project rely on core2 is the wrong approach. This leaves three options: - move the required classes to SPI - make container.java not dependent on core classes by duplicating them - merging container.java with core. I think moving the classes to SPI is not the best approach since they are implementations. Having duplicate classes does not seem to be the optimal approach either as that will result in a maintenance burden and a lot of code repetition. As background, the sharing of classes between core2 and container.java arises from the fact that the runtime uses a POJO model to assemble system services, and hence there is commonality between the two. I prefer to do the latter as it appears to be the cleanest. Also, java.container is not a very good example of how to extend the recursive core due to its advanced capabilities. I'd rather include a simple Java container geared to demonstrating how to extend the runtime. It would be helpful if people provide input over the next day...I plan to implement choice 3 tomorrow if there are no alternatives. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I would prefer another option: Define a clean SPI contract with just interfaces so that containers (component implementation extensions) do not have to depend on internal classes from the core project. I thought that it was the reason for having an SPI project separate from core. I think that the core runtime and the java container should be decoupled with clean interface-based contracts between the two. What are the technical issues preventing us from achieving that? That's exactly what we have, a clean SPI with mostly interfaces. Container.java and core, however, both use java Pojo's (system services, and Java CI components) so there are some common reflection and injection related classes. It doesn't make sense to duplicate those classes and related test cases and maintain exact replicas in two different projects of a significant amount of code. On the other hand, keeping container.java separate and referencing those core classes sends an unclear message to extension developers. The other option, putting the implementation classes in SPI is in my view also wrong for two reasons. First, they are implementation-related, Second, they are not things we want to expose in the SPI. So, to recap, we have a separate SPI extension package that does not require extension developers to reference the core implementation. Core, for example, is built on SPI. The issue I was bringing up in this thread is that as core and container.java share a significant amount of implementation, and container.java is central to both SCA and the Java Tuscany implementation, it makes sense to combine the two as opposed to duplicating the shared implementation. Jim --Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If I understand correctly, container.java and core both share utility classes that handle reflection and handling of Java annotations. Since we are a Java runtime other extensions and contributions to Tuscany will probably need this kind of utilities so I'd like to propose that we package them in tuscany-common.jar. This way they won't get mixed up with the SPIs (I agree with you that putting implementation classes in the SPI JAR is not good, I think the SPI JAR should just contain interfaces), and we can keep the java implementation extension and the core separate, which I think is important. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Checkstyle and PMD
I like the idea of running these but remain concerned by the time it takes on *every* build. They seem to add 10-15 seconds per module which is a long time compared to the 2-5 seconds it takes to run the unit tests. This is an impact for people like me who frequently build from the command line rather than from inside an IDE. To make things worse, I can't seem to build individual modules - I get: [INFO] An error has occurred in Checkstyle report generation. Embedded error: failed to load suppressions location: tuscany-suppressions.xml /home/jeremy/tuscany/sandbox/jboynes/sca/core2/suppressions_1_0.dtd (No such file or directory) I assume this is a working-directory problem but it does make testing a single module problematic. We had talked originally about just running these before checking in - Jim/Dan do you know how to set up mvn to do that or should I start to dig into it? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-120) Axis2 WS binding support for entryPoint without pre-existing WSDL
[ http://issues.apache.org/jira/browse/TUSCANY-120?page=all ] Venkatakrishnan updated TUSCANY-120: Attachment: xsdgen.zip Hi, To address this, I have started with generation of XSDs from static SDOs for now. If this part is thro, I suppose integrating it with WSDL generation can be managed. Before I go futher I want to do a sanity check over what I have implemented here on whether it is the right approach, on whether I have done the right things upto now... hence I am attaching whatever I have done for inputs / comments from the community. Here is what I did ... - Firstly I have assumed that the user will be able to input the SDO Factory class and obviously the classnames of the static SDOs for which xsds are to be generated - I followed the specifications the SDO v2.0.1 specs document - section titled Generation of XSD from SDO Type and Property (Page 107) - I have implemented for most basic rules specified therein but have quite some yet to be addressed. - I have tested with two sets of SDOs 1) that Raymond had attached previous in this JIRA (CreditReport classes) and 2) SDOs generated using the Tuscany - XSD2JavaGenerator tool from the sequences.xsd (an xsd that I picked up from the sdo-tools project) Here are my findings with the outputs generated: - - the outputs generated for the CreditReport sample is ok. - the outputs generated for sequences.xsd has quite a few discrepencies when compared with the original one. I'd like to have comments on whether I have interpretted the specs properly or is it something we must start fixing with annotations (additional information) appended to the generated SDOs. I have attached my entire eclipse project directory with all relevant classes and outputs. I have also attached the .classpath and .project files just in case any of you would like to import this project into your eclipse IDEs and try. Thanks. Axis2 WS binding support for entryPoint without pre-existing WSDL -- Key: TUSCANY-120 URL: http://issues.apache.org/jira/browse/TUSCANY-120 Project: Tuscany Type: Bug Components: Java SCA Axis Binding Versions: Java-Mx Reporter: ant elder Assignee: Raymond Feng Fix For: Java-Mx Attachments: java2wsdl-codegen.zip, xsdgen.zip Where the entryPoint doesn't use interface.wsdl then the pre-existing WSDL document shouldn't be required. Axis2 can generate WSDL at runtime based on the service interface so the Axis2 binding can use that to support the following: entryPoint name=AccountService interface.java interface=org.apache.tuscany.binding.axis2.assembly.tests.bigbank.account.services.account.AccountService/ binding.ws/ referenceAccountServiceComponent/reference /entryPoint See ML discussion: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SPI interfaces
[snip] ant elder wrote: +1 Where are you doing this and how can we start helping? A long time ago I had a go at something like this for the JavaScript component, the interfaces it had were along the lines of the ones below. probably a bit old now with all the other changes. One thing I found hard was having a nice way to have interfaces be either Java classes or WSDL portTypes particularly with components invoking service references. I'm not going to do this in the main head stream since this is prototyping and design investigation work. I just created an m2-design directory in my sandbox for this. I'll put the ruby component implementation extension there as soon as it is in a reasonable enough shape. There's a lot of interesting design and prototyping work where I think you can help: - Review the ruby implementation extension that I'm going to put there and help understand what aspects are missing, where interfaces can be improved, simplified and made more approachable. - Implement a simple binding extension (System.out/System.in or just TCP/IP sockets for example) to help understand the binding extension programming model, and see what's common with implementation extensions. - The whole interface definition space, like you said we need a nice way to deal with Java and WSDL interfaces, we also need to understand how somebody can extend Tuscany to provide support for additional interface definition languages (e.g. a ruby base class or a ruby module). - The interaction with databindings and how a component implementation extension or binding extensions specifies what data representation it can work with. This is just a short list of things that come to mind, but the list will grow quickly :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SPI interfaces
Hi, I have made some progress here. 1) Started to implement a very simple TCP/IP socket binding 2) Prototyped the databinding framework which can be used to hook with Tuscany message handler/interceptor. (please see my previous note). Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 21, 2006 7:10 PM Subject: Re: Tuscany SPI interfaces [snip] ant elder wrote: +1 Where are you doing this and how can we start helping? A long time ago I had a go at something like this for the JavaScript component, the interfaces it had were along the lines of the ones below. probably a bit old now with all the other changes. One thing I found hard was having a nice way to have interfaces be either Java classes or WSDL portTypes particularly with components invoking service references. I'm not going to do this in the main head stream since this is prototyping and design investigation work. I just created an m2-design directory in my sandbox for this. I'll put the ruby component implementation extension there as soon as it is in a reasonable enough shape. There's a lot of interesting design and prototyping work where I think you can help: - Review the ruby implementation extension that I'm going to put there and help understand what aspects are missing, where interfaces can be improved, simplified and made more approachable. - Implement a simple binding extension (System.out/System.in or just TCP/IP sockets for example) to help understand the binding extension programming model, and see what's common with implementation extensions. - The whole interface definition space, like you said we need a nice way to deal with Java and WSDL interfaces, we also need to understand how somebody can extend Tuscany to provide support for additional interface definition languages (e.g. a ruby base class or a ruby module). - The interaction with databindings and how a component implementation extension or binding extensions specifies what data representation it can work with. This is just a short list of things that come to mind, but the list will grow quickly :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
