Re: svn commit: r409302 - in /incubator/tuscany/sandbox/jboynes/sca: core2/src/main/java/org/apache/tuscany/core/loader/ core2/src/main/java/org/apache/tuscany/core/system/loader/ spi/src/main/java/or

[Raymond Feng]

Hi, Jeremy.

Can we make the loaderRegistry "protected" instead of "private" in 
ComponentTypeLoaderExtension.java? The sub-class may need to access it, for 
example, delegate to the registered ComponentTypeElementLoader to parse 
"componentType" element.


Thanks,
Raymond

- Original Message - 
From: <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, May 24, 2006 9:51 PM
Subject: svn commit: r409302 - in /incubator/tuscany/sandbox/jboynes/sca: 
core2/src/main/java/org/apache/tuscany/core/loader/ 
core2/src/main/java/org/apache/tuscany/core/system/loader/ 
spi/src/main/java/org/apache/tuscany/spi/extension/ 
spi/src/main/java/org/ap...




Author: jboynes
Date: Wed May 24 21:51:10 2006
New Revision: 409302

URL: http://svn.apache.org/viewvc?rev=409302&view=rev
Log:
add extension base class for ComponentTypeLoader

Added:

incubator/tuscany/sandbox/jboynes/sca/spi/src/main/java/org/apache/tuscany/spi/extension/ComponentTypeLoaderExtension.java 
(with props)

Modified:

incubator/tuscany/sandbox/jboynes/sca/core2/src/main/java/org/apache/tuscany/core/loader/LoaderRegistryImpl.java

incubator/tuscany/sandbox/jboynes/sca/core2/src/main/java/org/apache/tuscany/core/system/loader/SystemComponentTypeLoader.java

incubator/tuscany/sandbox/jboynes/sca/spi/src/main/java/org/apache/tuscany/spi/loader/LoaderRegistry.java

Modified: 
incubator/tuscany/sandbox/jboynes/sca/core2/src/main/java/org/apache/tuscany/core/loader/LoaderRegistryImpl.java
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/core2/src/main/java/org/apache/tuscany/core/loader/LoaderRegistryImpl.java?rev=409302&r1=409301&r2=409302&view=diff

==
---  
incubator/tuscany/sandbox/jboynes/sca/core2/src/main/java/org/apache/tuscany/core/loader/LoaderRegistryImpl.java 
(original)
+++ 
incubator/tuscany/sandbox/jboynes/sca/core2/src/main/java/org/apache/tuscany/core/loader/LoaderRegistryImpl.java 
Wed May 24 21:51:10 2006

@@ -71,6 +71,10 @@
componentTypeLoaders.put(key, loader);
}

+public > void unregisterLoader(Class 
key) {

+componentTypeLoaders.remove(key);
+}
+
@SuppressWarnings("unchecked")
public > void loadComponentType(I 
implementation, DeploymentContext deploymentContext) {

Class key = (Class) implementation.getClass();

Modified: 
incubator/tuscany/sandbox/jboynes/sca/core2/src/main/java/org/apache/tuscany/core/system/loader/SystemComponentTypeLoader.java
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/core2/src/main/java/org/apache/tuscany/core/system/loader/SystemComponentTypeLoader.java?rev=409302&r1=409301&r2=409302&view=diff

==
---  
incubator/tuscany/sandbox/jboynes/sca/core2/src/main/java/org/apache/tuscany/core/system/loader/SystemComponentTypeLoader.java 
(original)
+++ 
incubator/tuscany/sandbox/jboynes/sca/core2/src/main/java/org/apache/tuscany/core/system/loader/SystemComponentTypeLoader.java 
Wed May 24 21:51:10 2006

@@ -18,15 +18,19 @@

import java.net.URL;

-import org.apache.tuscany.spi.loader.ComponentTypeLoader;
-import org.apache.tuscany.spi.deployer.DeploymentContext;
import org.apache.tuscany.core.system.model.SystemImplementation;
import org.apache.tuscany.core.util.JavaIntrospectionHelper;
+import org.apache.tuscany.spi.deployer.DeploymentContext;
+import org.apache.tuscany.spi.extension.ComponentTypeLoaderExtension;

/**
 * @version $Rev$ $Date$
 */
-public class SystemComponentTypeLoader implements 
ComponentTypeLoader {
+public class SystemComponentTypeLoader extends 
ComponentTypeLoaderExtension {

+protected Class getTypeClass() {
+return SystemImplementation.class;
+}
+
public void load(SystemImplementation implementation, 
DeploymentContext deploymentContext) {

Class implClass = implementation.getImplementationClass();
URL resource = 
implClass.getResource(JavaIntrospectionHelper.getBaseName(implClass) + 
".componentType");


Added: 
incubator/tuscany/sandbox/jboynes/sca/spi/src/main/java/org/apache/tuscany/spi/extension/ComponentTypeLoaderExtension.java
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/spi/src/main/java/org/apache/tuscany/spi/extension/ComponentTypeLoaderExtension.java?rev=409302&view=auto

==
---  
incubator/tuscany/sandbox/jboynes/sca/spi/src/main/java/org/apache/tuscany/spi/extension/ComponentTypeLoaderExtension.java 
(added)
+++ 
incubator/tuscany/sandbox/jboynes/sca/spi/src/main/java/org/apache/tuscany/spi/extension/ComponentTypeLoaderExtension.java 
Wed May 24 21:51:10 2006

@@ -0,0 +1,49 @@
+/**
+ *
+ * Copyright 2006 The Apache Software Foundation or its licensors as 
applicable

+ *
+ *  Licensed under the Apache License, Version 2.0 (the "License");
+ *  you may not use this file except in compliance with the Lic

Re: [VOTE] Publish Tuscany M1 release - 2nd vote

[Jeremy Boynes]

On 5/24/06, ant elder <[EMAIL PROTECTED]> wrote:

The NOTICE file doesn't include mention of Woodstox or JSON-RPC-Java and all
the stuff included with the Celtix binding - Spring, Jetty, ActiveMQ (thats
a pre-Apache release right?), and all those Sun jars (which presumably we
really are allowed to be distributing?)?



I believe all the jars like Spring, Jetty, ActiveMQ etc. are released
under the Apache license and hence strictly may not need to be in the
NOTICE file as we are not changing the license on them. However, in
the interest of erring on the side of caution I think we should add
them to future releases.

The Sun jars come from the GlassFish JAX-WS project which is listed in
the NOTICE.


Reading about the NOTICE file it wasn't completely clear to me what must be
included so if this is going over old ground and those things don't need to
be included then +1 from me for this M1 distribution.



Thanks for spotting the Apache ones. I don't think we need to change
anything there for this release so unless anyone disagrees I would
suggest we send what we have to the IPMC for an official vote once the
72 hours is up.

--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r409076 - in /incubator/tuscany/sandbox/jboynes/sca/containers/container.spring: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/

[Jim Marino]

On May 24, 2006, at 3:04 PM, Jeremy Boynes wrote:



On 5/24/06, Raymond Feng <[EMAIL PROTECTED]> wrote:



Hi,

Thanks for the explanations.

I can help to port/develop the implementation/componentType  
loaders. As the
first step, I'm trying JavaImplementationLoader and  
JavaComponentTypeLoader.


Here're a few more questions/comments:

1) ComponentTypeLoader.load(...) should take DeploymentContext in  
addition

to Implementation.




Yes - it was late last night :-)



2) LoaderRegistry doesn't have an "unregisterLoader()" method to  
unregister

ComponentTypeLoader. Is it automatically removed when the
ImplementationLoader is delisted?




No, we need to add unregister methods here (again it was late :-) )
and on the BuilderRegistry as well



3) What's the replacement for "org/apache/tuscany/core/config/**"  
which uses

to host the class like "Java5ComponentTypeIntrospector"?





Jim added a more general annotation processing framework into core in
the trunk. The component type loaders should use that for
introspecting the implementation.


Yea the idea with that is it's visitor based which allows people to  
extend it with custom processors (i.e. the runtime doesn't know about  
any annotations). Jeremy mentioned he was going to plug this into the  
load process, so when that's done we can look at how that fits into  
the loader work.




--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r409076 - in /incubator/tuscany/sandbox/jboynes/sca/containers/container.spring: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/

[Jeremy Boynes]

On 5/24/06, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi,

Thanks for the explanations.

I can help to port/develop the implementation/componentType loaders. As the
first step, I'm trying JavaImplementationLoader and JavaComponentTypeLoader.

Here're a few more questions/comments:

1) ComponentTypeLoader.load(...) should take DeploymentContext in addition
to Implementation.


Yes - it was late last night :-)


2) LoaderRegistry doesn't have an "unregisterLoader()" method to unregister
ComponentTypeLoader. Is it automatically removed when the
ImplementationLoader is delisted?


No, we need to add unregister methods here (again it was late :-) )
and on the BuilderRegistry as well


3) What's the replacement for "org/apache/tuscany/core/config/**" which uses
to host the class like "Java5ComponentTypeIntrospector"?



Jim added a more general annotation processing framework into core in
the trunk. The component type loaders should use that for
introspecting the implementation.

--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r409076 - in /incubator/tuscany/sandbox/jboynes/sca/containers/container.spring: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/

[Raymond Feng]

Hi,

Thanks for the explanations.

I can help to port/develop the implementation/componentType loaders. As the 
first step, I'm trying JavaImplementationLoader and JavaComponentTypeLoader.


Here're a few more questions/comments:

1) ComponentTypeLoader.load(...) should take DeploymentContext in addition 
to Implementation.
2) LoaderRegistry doesn't have an "unregisterLoader()" method to unregister 
ComponentTypeLoader. Is it automatically removed when the 
ImplementationLoader is delisted?
3) What's the replacement for "org/apache/tuscany/core/config/**" which uses 
to host the class like "Java5ComponentTypeIntrospector"?


Thanks,
Raymond

- Original Message - 
From: "Jeremy Boynes" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, May 24, 2006 11:16 AM
Subject: Re: svn commit: r409076 - in 
/incubator/tuscany/sandbox/jboynes/sca/containers/container.spring: ./ src/ 
src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ 
src/main/java/org/apache/tuscany/ src/main/java/org/apache/tuscany/containe



On 5/24/06, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi, Jim/Jeremy.

I don't see XXXImplementationLoader (except SystemImplementationLoader) 
any

more in the sandbox code. Are they just not implmented or do we now have a
new model to populate the implementation metadata based on the bean
properties for the implementation class?



I am still porting loaders over from the current core and help doing
that would be appreciated (e.g. JavaImplementationLoader). One
difference with these is that the LoaderRegistry has been enhanced to
support componentType loading so the implmentation loader can call
back for that rather than having to do it itself.

I don't see TuscanyRuntime either, what's the new way to bootstrap 
Tuscany?


I am actively working on this. I am refactoring the bootstrap process
to get rid of the remaining duplicate code in the different host
environments (j2se, tomcat) and introduce an extensible bootstrapper.
I'm also separating the loaders/builders used during bootstrap from
those that will be used once the runtime is up - this will provide
full configuration of the deployment infrastructure from SCDL rather
than as a mixture of Java code and SCDL.

I also added a "launcher" that allows a J2SE application to be
bootstrapped without requiring the Tuscany runtime on the classpath -
this will help prevent library conflicts between applications and our
implementation.



Sorry to ask questions on the sandbox code, but it would be really helpful
for me to understand the new contract.



Keep asking ...
--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-427) Test case files need to end with TestCase to be executed

[Frank Budinsky (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-427?page=comments#action_12413181 
] 

Frank Budinsky commented on TUSCANY-427:


Is the change in TextUtil.txt really the right solution? A better question is 
do we really need to have the copyright headers in the test files>? If we don't 
then we should just change the test files. If we do, then we'll need to add 
copyrights to all the test files in the impl project as well.


> Test case files need to end with TestCase to be executed
> 
>
>  Key: TUSCANY-427
>  URL: http://issues.apache.org/jira/browse/TUSCANY-427
>  Project: Tuscany
> Type: Bug

>   Components: Java SDO Implementation, Java SDO Tools
> Versions: Java-Mx
> Reporter: Fuhwei Lwo
> Priority: Minor
>  Attachments: TestUtil.txt
>
> TypeRoundTripTest.java in sdo/impl project and StaticSequenceNoEmfTest.java 
> were never executed because their file names are not ending with TestCase so 
> they were not ran during the build.

-- 
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]

Spring integration chat transcript

[Jim Marino]

jmarino: so Raymond, I checked in some skeletal code last night
[11:15am] rfeng: yes, I did a brief reading
[11:16am] jmarino: k good .did you also have a chance to take a look  
at the Groovy extension?
[11:16am] rfeng: so the basic idea is to model a set of spring beans  
as a composite?

[11:16am] rfeng: yes
[11:16am] ant_away is now known as ant_.
[11:16am] jmarino: yes
[11:16am] jmarino: the spring beans will be in a composite
[11:17am] jmarino: Spring 2 has a namespace handler as well...
[11:17am] rfeng: Can a SCA component wire to a spring bean in the  
composite?
[11:17am] jmarino: this can be used to notify the SCA runtime to  
prepare a service or reference3

[11:17am] rfeng: yes, I added that support in the 2nd patch
[11:17am] jmarino: reference
[11:17am] jmarino: how does it work?
[11:18am] jmarino: no an SCA component cannot wire directly to a  
bean.. that would violate SCA
[11:18am] rfeng: basically, similar as our StaxElementLoader +  
ObjectFactory

[11:18am] jmarino: can you walk me through that first?
[11:18am] rfeng: sure
[11:18am] jmarino: we can come back to the wiring question in a sec
[11:19am] rfeng: ok, let's look at this bean def:
[11:19am] rfeng: class="helloworld.SpringHelloWorldImpl">

[11:19am] rfeng: 
[11:19am] rfeng: World
[11:19am] rfeng: 
[11:19am] rfeng: 
[11:19am] rfeng: name="JavaHelloWorldComponent" />
[11:19am] rfeng: the 2nd one will be handled by a tuscany namespace  
handler

[11:20am] jmarino: so what happens?
[11:21am] rfeng: the registration is done by contributing to META-INF/ 
spring.handlers, spring.schemas

[11:21am] rfeng: when somebody call beanFactory.getBean(id)
[11:22am] rfeng: the namespace handler will be invoked to provide a  
bean def which can be the bean itself or a factory bean

[11:22am] jmarino: why is SCA involved at this stage?
[11:22am] rfeng: in this case, we allow Spring to call SCA services  
using its own PM

[11:22am] jmarino: I assume they look up "helloWorld1"?
[11:23am] rfeng: maybe we're looking into different aspects
[11:23am] jmarino: "service" is entryPoint for me
[11:23am] jmarino: that may be the problem
[11:24am] jmarino: a "reference" is an external service
[11:24am] jmarino: so let's take another example
[11:24am] rfeng: ok, let's do this way
[11:24am] jmarino: I have a foo Spring bean
[11:24am] rfeng: 1) SCA talks to Spring
[11:24am] rfeng: 2) Spring talks to SCA
[11:24am] jmarino: yes so we are starting with 2
[11:25am] rfeng: ok
[11:25am] jmarino: so I have  a foo bean...
[11:25am] jmarino: that is "wired" in spring to a reference (external  
service)

[11:25am] rfeng: ok
[11:25am] jmarino: when I do getBean("foo") *Spring* returns the foo  
bean

[11:25am] jmarino: in the process, it needs to resolve the reference
[11:25am] jmarino: to "bar"
[11:25am] rfeng: say foo requires bar (ref)
[11:25am] jmarino: yes
[11:26am] jmarino: at that point the spring context needs to talk to  
something to get bar

[11:26am] rfeng: and bar is a SCA service
[11:26am] jmarino: bar is an SCA "reference" that may be wired to  
something

[11:26am] jmarino: it is opaque to Spring
[11:26am] rfeng: sure
[11:27am] jmarino: there is an SCA composite that needs to return the  
reference
[11:27am] jmarino: Spring sees this composite as a hierarchical  
application context

[11:27am] jmarino: Spring delegates to it to get the bar reference
[11:27am] rfeng: so in spring, foo --> bar, let's assume wire by id
[11:28am] rfeng: it will try to resolve the ref by calling  
context.getBean("bar")

[11:28am] jmarino: what is calling context.getBean("bar")?
[11:29am] rfeng: Spring, calling appContext.getBean("bar"), right?
[11:29am] jmarino: internally maybe that is how it does the  
resolution (at some point it does do that)

[11:29am] jmarino: but we don't need to worry about that
[11:30am] jmarino: the Spring app context
[11:30am] jmarino: foo is in will have a parent app context...
[11:30am] jmarino: set by SCA...
[11:30am] jmarino: that app context will be responsibly for returning  
"bar"

[11:30am] jmarino: the app context is actually the SCA composite
[11:30am] rfeng: I have a slight different view
[11:31am] jmarino: k shoot
[11:31am] rfeng: I thought the context is the regular spring context
[11:31am] jmarino: what is bar, another bean?
[11:31am] rfeng: and by using the extensible XML config, modeling bar  
as another bean

[11:31am] rfeng: with the SCA ns
[11:32am] rfeng: I'm open, just try to understand your view
[11:32am] jmarino: yes I've seen that approach but I'm not sure  
that's what we want

[11:32am] jmarino: that bean will then have to resolve out to SCA anyway
[11:32am] rfeng: right
[11:33am] jmarino: I don't think we need two things (one in Spring,  
one in SCA)

[11:33am] rfeng: ok
[11:33am] jmarino: makes changing things tricky...
[11:33am] jmarino: also I want to do something a bit different...
[11:33am] rfeng: sure
[11:33am] jmarino: I want to go from the Spring AO

[jira] Updated: (TUSCANY-186) Need APIs for CommandFactory (and probably CommandGroupFactory) to accept Config instance in addition to the current API for FileStream

[Brent Daniel (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-186?page=all ]

Brent Daniel updated TUSCANY-186:
-

Attachment: commandgroup.txt

CommandFactory was addressed earlier. This patch addresses CommandGroupFactory

> Need APIs for CommandFactory (and probably CommandGroupFactory)  to accept 
> Config instance in addition to the current API for FileStream
> 
>
>  Key: TUSCANY-186
>  URL: http://issues.apache.org/jira/browse/TUSCANY-186
>  Project: Tuscany
> Type: New Feature

>   Components: Java DAS RDB
> Versions: Java-Mx
> Reporter: Kevin Williams
>  Fix For: Java-Mx
>  Attachments: commandgroup.txt
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r409076 - in /incubator/tuscany/sandbox/jboynes/sca/containers/container.spring: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/

[Jeremy Boynes]

On 5/24/06, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi, Jim/Jeremy.

I don't see XXXImplementationLoader (except SystemImplementationLoader) any
more in the sandbox code. Are they just not implmented or do we now have a
new model to populate the implementation metadata based on the bean
properties for the implementation class?



I am still porting loaders over from the current core and help doing
that would be appreciated (e.g. JavaImplementationLoader). One
difference with these is that the LoaderRegistry has been enhanced to
support componentType loading so the implmentation loader can call
back for that rather than having to do it itself.


I don't see TuscanyRuntime either, what's the new way to bootstrap Tuscany?


I am actively working on this. I am refactoring the bootstrap process
to get rid of the remaining duplicate code in the different host
environments (j2se, tomcat) and introduce an extensible bootstrapper.
I'm also separating the loaders/builders used during bootstrap from
those that will be used once the runtime is up - this will provide
full configuration of the deployment infrastructure from SCDL rather
than as a mixture of Java code and SCDL.

I also added a "launcher" that allows a J2SE application to be
bootstrapped without requiring the Tuscany runtime on the classpath -
this will help prevent library conflicts between applications and our
implementation.



Sorry to ask questions on the sandbox code, but it would be really helpful
for me to understand the new contract.



Keep asking ...
--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r409076 - in /incubator/tuscany/sandbox/jboynes/sca/containers/container.spring: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/

[Jim Marino]

Hi Raymond,

Comments inline...

On May 24, 2006, at 9:30 AM, Raymond Feng wrote:


Hi, Jim/Jeremy.

I don't see XXXImplementationLoader (except  
SystemImplementationLoader) any more in the sandbox code. Are they  
just not implmented or do we now have a new model to populate the  
implementation metadata based on the bean properties for the  
implementation class?


Jeremy is working on this so I'll let him explain...basically there  
are some loaders in there but others need to be added.


I don't see TuscanyRuntime either, what's the new way to bootstrap  
Tuscany?


Jeremy has a tighter bootstrap and deployment mechanism. Again, I'll  
let him explain.


Sorry to ask questions on the sandbox code, but it would be really  
helpful for me to understand the new contract.


No need to say "sorry" - these are all good questions to be asking.  
I'm probably going to be more useful answering questions about the  
simplified extension model, scope containers, etc. so feel free to  
ask any questions as they arise.


Jim


Thanks,
Raymond

- Original Message - From: <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, May 23, 2006 10:57 PM
Subject: svn commit: r409076 - in /incubator/tuscany/sandbox/ 
jboynes/sca/containers/container.spring: ./ src/ src/main/ src/main/ 
java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/ 
org/apache/tuscany/ src/main/java/org/apache/tuscany/container/ src...





Author: jmarino
Date: Tue May 23 22:57:33 2006
New Revision: 409076

URL: http://svn.apache.org/viewvc?rev=409076&view=rev
Log:
Spring integration strawman based on Raymond's implementation  
ported to core2


Added:
   incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
LICENSE.txt (with props)
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
README.txt (with props)
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
pom.xml (with props)
   incubator/tuscany/sandbox/jboynes/sca/containers/ 
container.spring/src/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/main/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/main/java/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/main/java/org/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/main/java/org/apache/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/main/java/org/apache/tuscany/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/main/java/org/apache/tuscany/container/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/main/java/org/apache/tuscany/container/spring/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/main/java/org/apache/tuscany/container/spring/ 
SpringCompositeContext.java
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/main/java/org/apache/tuscany/container/spring/SpringInvoker.java
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/main/resources/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/org/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/org/apache/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/org/apache/tuscany/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/org/apache/tuscany/container/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/org/apache/tuscany/container/spring/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/org/apache/tuscany/container/spring/ 
SpringInvocationTestCase.java
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/org/apache/tuscany/container/spring/ 
SpringReferenceTestCase.java
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/org/apache/tuscany/container/spring/mock/
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/org/apache/tuscany/container/spring/mock/TestBean.java
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/java/org/apache/tuscany/container/spring/mock/ 
TestBeanImpl.java
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/ 
src/test/resources/


Added: incubator/tuscany/sandbox/jboynes/sca/containers/ 
container.spring/LICENSE.txt
URL: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/ 
jboynes/sca/containers/container.spring/LICENSE.txt? 
rev=409076&view=auto
= 
=
---  incubator/tuscany/sandbox/jboynes/sca/containers/ 
container.spring/LICENSE.txt (added)
+++ incubator/tuscany/

Re: svn commit: r409076 - in /incubator/tuscany/sandbox/jboynes/sca/containers/container.spring: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/

[Raymond Feng]

Hi, Jim/Jeremy.

I don't see XXXImplementationLoader (except SystemImplementationLoader) any 
more in the sandbox code. Are they just not implmented or do we now have a 
new model to populate the implementation metadata based on the bean 
properties for the implementation class?


I don't see TuscanyRuntime either, what's the new way to bootstrap Tuscany?

Sorry to ask questions on the sandbox code, but it would be really helpful 
for me to understand the new contract.


Thanks,
Raymond

- Original Message - 
From: <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, May 23, 2006 10:57 PM
Subject: svn commit: r409076 - in 
/incubator/tuscany/sandbox/jboynes/sca/containers/container.spring: ./ src/ 
src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ 
src/main/java/org/apache/tuscany/ 
src/main/java/org/apache/tuscany/container/ src...




Author: jmarino
Date: Tue May 23 22:57:33 2006
New Revision: 409076

URL: http://svn.apache.org/viewvc?rev=409076&view=rev
Log:
Spring integration strawman based on Raymond's implementation ported to 
core2


Added:
   incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/LICENSE.txt 
(with props)


incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/README.txt 
(with props)


incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/pom.xml 
(with props)

   incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/main/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/main/java/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/main/java/org/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/main/java/org/apache/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/main/java/org/apache/tuscany/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/main/java/org/apache/tuscany/container/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/main/java/org/apache/tuscany/container/spring/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/main/java/org/apache/tuscany/container/spring/SpringCompositeContext.java

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/main/java/org/apache/tuscany/container/spring/SpringInvoker.java

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/main/resources/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/org/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/org/apache/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/org/apache/tuscany/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/org/apache/tuscany/container/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/org/apache/tuscany/container/spring/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/org/apache/tuscany/container/spring/SpringInvocationTestCase.java

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/org/apache/tuscany/container/spring/SpringReferenceTestCase.java

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/org/apache/tuscany/container/spring/mock/

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/org/apache/tuscany/container/spring/mock/TestBean.java

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/java/org/apache/tuscany/container/spring/mock/TestBeanImpl.java

incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/src/test/resources/

Added: 
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/LICENSE.txt
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/LICENSE.txt?rev=409076&view=auto

==
---  
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/LICENSE.txt 
(added)
+++ 
incubator/tuscany/sandbox/jboynes/sca/containers/container.spring/LICENSE.txt 
Tue May 23 22:57:33 2006

@@ -0,0 +1,202 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  "License" shall mean the terms and conditions for use, 
reproduction,
+  and distribution as defined by Sections 1 through 9 of this 
document.

+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  

Re: Getting list of components in a module

[ant elder]

Jim, this would be unmanaged code, not in a component, so it doesn't look
like there is any API for this. The idea of TUSCANY-417 is an interactive
JavaScript shell  along the lines of what Jeremy described as a "first-class
client environment for JavaScript".

  ...ant

On 5/24/06, Jim Marino <[EMAIL PROTECTED]> wrote:


Can you explain why you need the list of components? For managed code
(i.e. in a component) the spec defines a way to get the metadata
associated with a module.

Jim

On May 24, 2006, at 1:30 AM, ant elder wrote:

> I've a J2SE client that needs to get a list of all the components
> defined in
> the current module, is that possible? There used to be the getMetaData
> method but thats been removed now.  If there is no easy way right
> now could
> i add something?
>
>   ...ant
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-427) Test case files need to end with TestCase to be executed

[Fuhwei Lwo (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-427?page=all ]

Fuhwei Lwo updated TUSCANY-427:
---

Attachment: TestUtil.txt

Once StaticSequenceNoEmfTest.java in sdo/tools project is executed, 
TestUtil.txt patch is needed for the test to work.

> Test case files need to end with TestCase to be executed
> 
>
>  Key: TUSCANY-427
>  URL: http://issues.apache.org/jira/browse/TUSCANY-427
>  Project: Tuscany
> Type: Bug

>   Components: Java SDO Implementation, Java SDO Tools
> Versions: Java-Mx
> Reporter: Fuhwei Lwo
> Priority: Minor
>  Attachments: TestUtil.txt
>
> TypeRoundTripTest.java in sdo/impl project and StaticSequenceNoEmfTest.java 
> were never executed because their file names are not ending with TestCase so 
> they were not ran during the build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-427) Test case files need to end with TestCase to be executed

[Fuhwei Lwo (JIRA)]

Test case files need to end with TestCase to be executed


 Key: TUSCANY-427
 URL: http://issues.apache.org/jira/browse/TUSCANY-427
 Project: Tuscany
Type: Bug

  Components: Java SDO Implementation, Java SDO Tools  
Versions: Java-Mx
Reporter: Fuhwei Lwo
Priority: Minor


TypeRoundTripTest.java in sdo/impl project and StaticSequenceNoEmfTest.java 
were never executed because their file names are not ending with TestCase so 
they were not ran during the build.

-- 
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] Resolved: (TUSCANY-426) Null pointer exception loading schema with ref to already defined type

[Pete Robbins (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-426?page=all ]
 
Pete Robbins resolved TUSCANY-426:
--

Resolution: Fixed

> Null pointer exception loading schema with ref to already defined type
> --
>
>  Key: TUSCANY-426
>  URL: http://issues.apache.org/jira/browse/TUSCANY-426
>  Project: Tuscany
> Type: Bug

>   Components: C++ SDO
> Versions: Cpp-current
> Reporter: Pete Robbins
> Assignee: Pete Robbins
>  Fix For: Cpp-current

>
> Bug in XSDHelperImpl handling reference to type not being defined in this 
> pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-426) Null pointer exception loading schema with ref to already defined type

[Pete Robbins (JIRA)]

Null pointer exception loading schema with ref to already defined type
--

 Key: TUSCANY-426
 URL: http://issues.apache.org/jira/browse/TUSCANY-426
 Project: Tuscany
Type: Bug

  Components: C++ SDO  
Versions: Cpp-current
Reporter: Pete Robbins
 Assigned to: Pete Robbins 
 Fix For: Cpp-current


Bug in XSDHelperImpl handling reference to type not being defined in this pass.

-- 
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] Resolved: (TUSCANY-425) The conversion for Xpath "@Property" is not being resolved to "Property" as per Spec

[Frank Budinsky (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-425?page=all ]
 
Frank Budinsky resolved TUSCANY-425:


Resolution: Fixed

Fixed in revision 409180.

> The conversion for Xpath "@Property" is not being resolved to "Property" as 
> per Spec
> 
>
>  Key: TUSCANY-425
>  URL: http://issues.apache.org/jira/browse/TUSCANY-425
>  Project: Tuscany
> Type: Bug

>   Components: Java SDO Implementation
> Versions: Java-M1
>  Environment: All environments
> Reporter: Hasan Muhammad
> Priority: Critical
>  Attachments: XPathBug_NewFiles.jar, xpath_bug.patch
>
> According to the SDO specification, when the Xpath expression "@property" is 
> used to find the value of the property, in the SDO layer, "@" has no meaning. 
> Hence it should be ignored and this expression must be resolved to be just 
> "property", and the value returned. But this is not happening, and the whole 
> of the expression is being taken as a the property resulting in a "Not a 
> valid feature" excpetion. 

-- 
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: Getting list of components in a module

[Jim Marino]

Can you explain why you need the list of components? For managed code  
(i.e. in a component) the spec defines a way to get the metadata  
associated with a module.


Jim

On May 24, 2006, at 1:30 AM, ant elder wrote:

I've a J2SE client that needs to get a list of all the components  
defined in

the current module, is that possible? There used to be the getMetaData
method but thats been removed now.  If there is no easy way right  
now could

i add something?

  ...ant




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Getting list of components in a module

[Jeremy Boynes]

On 5/24/06, ant elder <[EMAIL PROTECTED]> wrote:

Its for this: http://issues.apache.org/jira/browse/TUSCANY-417. Which would
be based on the Rhino shell: http://www.mozilla.org/rhino/shell.html, which
to quote from that site provides "... an interactive environment for
exploratory programming.".

Ideally the shell environment would be configured automatically from the SCA
config so you can do something like the following without having to do
explicit locateService calls:

js> print(Helloworld.getGreetings("ant"));
hellp ant
js>



Would it be possible to promote this further and have a first-class
client environment for JavaScript? In this environment there would be
pure JavaScript objects representing references to other services; for
example, in your example above "Helloworld" would be a JavaScript
object implementing the service interface.

In this mode, there would be no need for the application code to
access the list of components, they would just be there ready to be
used. Each object would be the JavaScript equivalent of the proxies
that are injected into a Java component to represent its references.

I would imagine this would be the same as the model used inside a
browser, just using its native JS implementation rather than Rhino.
Actually, this could be start of a JavaScript Client/Implementation
spec - would you be interested in proposing it to the spec
collaboration?

--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Getting list of components in a module

[ant elder]

Its for this: http://issues.apache.org/jira/browse/TUSCANY-417. Which would
be based on the Rhino shell: http://www.mozilla.org/rhino/shell.html, which
to quote from that site provides "... an interactive environment for
exploratory programming.".

Ideally the shell environment would be configured automatically from the SCA
config so you can do something like the following without having to do
explicit locateService calls:

js> print(Helloworld.getGreetings("ant"));
hellp ant
js>

  ...ant

On 5/24/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On 5/24/06, ant elder <[EMAIL PROTECTED]> wrote:
> I've a J2SE client that needs to get a list of all the components
defined in
> the current module, is that possible? There used to be the getMetaData
> method but thats been removed now.  If there is no easy way right now
could
> i add something?

The spec and programming model try to discourage that kind of
operation. The main reason for this is that it is transferring control
from SCA back into the application which means you lose many of the
benefits at the core of SCA itself.

For example, one of the most common reasons something wants a list of
components is so that it can perform routing decisions. This bypasses
the SCA wiring model used to assemble the different services together.
It means that you need to change the application code when the wiring
requirements change.

It was these kind of issues that led to the spec folks wanting to
reconsider the metadata story which is why getMetaData() went away.
Until that's worked out I wouldn't be in favour of adding it back it.

Having said that, there may be other ways to achieve the larger
purpose here. Could you provide some more information on what led to
this need and perhaps folks here could suggest an alternative?.

--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-425) The conversion for Xpath "@Property" is not being resolved to "Property" as per Spec

[Hasan Muhammad (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-425?page=all ]

Hasan Muhammad updated TUSCANY-425:
---

Attachment: XPathBug_NewFiles.jar

This attachment contains the testcase and resource files.

> The conversion for Xpath "@Property" is not being resolved to "Property" as 
> per Spec
> 
>
>  Key: TUSCANY-425
>  URL: http://issues.apache.org/jira/browse/TUSCANY-425
>  Project: Tuscany
> Type: Bug

>   Components: Java SDO Implementation
> Versions: Java-M1
>  Environment: All environments
> Reporter: Hasan Muhammad
> Priority: Critical
>  Attachments: XPathBug_NewFiles.jar, xpath_bug.patch
>
> According to the SDO specification, when the Xpath expression "@property" is 
> used to find the value of the property, in the SDO layer, "@" has no meaning. 
> Hence it should be ignored and this expression must be resolved to be just 
> "property", and the value returned. But this is not happening, and the whole 
> of the expression is being taken as a the property resulting in a "Not a 
> valid feature" excpetion. 

-- 
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-425) The conversion for Xpath "@Property" is not being resolved to "Property" as per Spec

[Hasan Muhammad (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-425?page=all ]

Hasan Muhammad updated TUSCANY-425:
---

Attachment: xpath_bug.patch

The fix is in DataObjectUtil class where the XPath is being processed

> The conversion for Xpath "@Property" is not being resolved to "Property" as 
> per Spec
> 
>
>  Key: TUSCANY-425
>  URL: http://issues.apache.org/jira/browse/TUSCANY-425
>  Project: Tuscany
> Type: Bug

>   Components: Java SDO Implementation
> Versions: Java-M1
>  Environment: All environments
> Reporter: Hasan Muhammad
> Priority: Critical
>  Attachments: XPathBug_NewFiles.jar, xpath_bug.patch
>
> According to the SDO specification, when the Xpath expression "@property" is 
> used to find the value of the property, in the SDO layer, "@" has no meaning. 
> Hence it should be ignored and this expression must be resolved to be just 
> "property", and the value returned. But this is not happening, and the whole 
> of the expression is being taken as a the property resulting in a "Not a 
> valid feature" excpetion. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-425) The conversion for Xpath "@Property" is not being resolved to "Property" as per Spec

[Hasan Muhammad (JIRA)]

The conversion for Xpath "@Property" is not being resolved to "Property" as per 
Spec


 Key: TUSCANY-425
 URL: http://issues.apache.org/jira/browse/TUSCANY-425
 Project: Tuscany
Type: Bug

  Components: Java SDO Implementation  
Versions: Java-M1
 Environment: All environments
Reporter: Hasan Muhammad
Priority: Critical


According to the SDO specification, when the Xpath expression "@property" is 
used to find the value of the property, in the SDO layer, "@" has no meaning. 
Hence it should be ignored and this expression must be resolved to be just 
"property", and the value returned. But this is not happening, and the whole of 
the expression is being taken as a the property resulting in a "Not a valid 
feature" excpetion. 

-- 
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: Getting list of components in a module

[Jeremy Boynes]

On 5/24/06, ant elder <[EMAIL PROTECTED]> wrote:

I've a J2SE client that needs to get a list of all the components defined in
the current module, is that possible? There used to be the getMetaData
method but thats been removed now.  If there is no easy way right now could
i add something?


The spec and programming model try to discourage that kind of
operation. The main reason for this is that it is transferring control
from SCA back into the application which means you lose many of the
benefits at the core of SCA itself.

For example, one of the most common reasons something wants a list of
components is so that it can perform routing decisions. This bypasses
the SCA wiring model used to assemble the different services together.
It means that you need to change the application code when the wiring
requirements change.

It was these kind of issues that led to the spec folks wanting to
reconsider the metadata story which is why getMetaData() went away.
Until that's worked out I wouldn't be in favour of adding it back it.

Having said that, there may be other ways to achieve the larger
purpose here. Could you provide some more information on what led to
this need and perhaps folks here could suggest an alternative?.

--
Jeremy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Publish Tuscany M1 release - 2nd vote

[rick rineholt]

+1 From me too.   ... come on folks, Lets get the vote
out :-)
Kevin Williams wrote:
> +1
> BB and DAS stand-alone samples still look good on XP
and OS X
>
>
> Jean-Sebastien Delfino wrote:
>
>> Hi!
>>
>> I created source and binary distributions of the
latest Tuscany 
>> Milestone 1 release candidate level (SVN revision
r408581) and placed 
>> them in my home directory:
>>
http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1-src.tar.gz

>>
>>
http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1-src.zip

>>
>>
http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1.tar.gz

>>
>>
http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1.zip

>>
>>
>> I also tagged this level of code as 
>>
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060522.
>>
>> Solid progress has been made to produce this
Milestone release, and I 
>> think it is in a good shape. The list of JIRA
issues resolved and 
>> closed in this Milestone 1 release is here:
>>
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&fixfor=12311030&fixfor=12311061&version=12311030&version=12311061&status=5&status=6&sorter/field=priority&sorter/order=DESC

>>
>>
>> The only difference between this release candidate
and the previous 
>> release candidate is the fix for JIRA TUSCANY-414
(feedback from the 
>> incubator list, see
http://issues.apache.org/jira/browse/TUSCANY-414).
>> I moved the previous release candidate to 
>>
http://people.apache.org/~jsdelfino/test-incubating-M1/RC-history/RC4.
>>
>> Instructions on setting up your environment to use
Tuscany and 
>> getting started with the Tuscany samples are in the
README.txt and 
>> GettingStarted.htm files contained in the
distributions. These files 
>> can also be downloaded from here:
>>
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060522/java/README.txt

>>
>>
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060522/java/GettingStarted.htm

>>
>>
>> I tested the binary and source distributions in the
following 
>> environments:
>> Redhat Enterprise Linux 4 - Java JDK 5.0 update 06
- Maven 2.0.4 - 
>> Apache Ant 1.6.5
>> Windows XP SP2 - Java JDK 5.0 update 06 - Maven
2.0.4 - Apache Ant 1.6.5
>>
>> Please vote to publish the Milestone 1 release
distributions. Please 
>> take some time to download the distributions,
review them and test 
>> them in your environment before voting.
>>
>> The vote is open for the next 72 hours, please vote
by Thursday May 
>> 25, 10am PDT. At least three +1 votes are required,
and only the 
>> votes from Tuscany committers are binding. If the
majority of all 
>> votes is positive, I will send a summary of that
vote to the 
>> Incubator's general list to formally request the
Incubator PMC to 
>> approve the Tuscany Milestone 1 release. For your
reference the 
>> Incubator release policy guidelines are available
at 
>>
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases.
>>
>
>
>
>
-
> To unsubscribe, e-mail:
[EMAIL PROTECTED]
> For additional commands, e-mail:
[EMAIL PROTECTED]
>
>


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-419) Template XML for JavaScript components

[Venkatakrishnan (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-419?page=all ]

Venkatakrishnan updated TUSCANY-419:


Attachment: tuscany-sca-tools patch 24-May.txt
tuscany-sca-plugins patch 24-May.txt

Hi... here are a couple of patches that will be required for this feature.

1) A tool that would generate and xml instance from an xsd (either an xsd file 
or a wsdl file)

2) A maven plugin for this tool.  Here is a sample of how this plugin could be 
used: -

org.apache.tuscany.sca.plugins
tuscany-plugin-xmlfromxsd


  
${basedir}/src/main/resources/wsdl/interopdoc.wsdl
ComplexDocument
  
http://soapinterop.org/


generate




  

Hope this helps!

> Template XML for JavaScript components
> --
>
>  Key: TUSCANY-419
>  URL: http://issues.apache.org/jira/browse/TUSCANY-419
>  Project: Tuscany
> Type: New Feature

>   Components: Java SCA JavaScript Container
> Versions: Java-M2
> Reporter: ant elder
> Priority: Critical
>  Fix For: Java-M2
>  Attachments: tuscany-sca-plugins patch 24-May.txt, tuscany-sca-tools patch 
> 24-May.txt
>
> Provide a template XML facility for JavaScript components

-- 
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]

AJAX binding

[ant elder]

I've started work in the sandbox on improving the JSON-RPC binding so that
it supports server components invoking functions on the client browser by
using externalService definitions.

I'm wondering what to do with this now, should it replace the old JSON-RPC
binding, should i move it from the sandbox to to the main branch to keep
developing it, is anyone else at all interested in this type of function in
Tuscany?

The binding and a chat sample are at:
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ajax

The very basic chat sample lets multiple people viewing an HTML page to chat
to each other - what anyone types is sent to everyone else viewing the page.


The sample HTML page shows how its done, and is at:
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ajax/ajaxchat/src/main/webapp/AJAXChat.html

and the associated sca.module file is:
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ajax/ajaxchat/src/main/resources/sca.module

In the client HTML all you do is include a script definition for the Tuscany
AJAX scritp:

  

and that makes available to the HTML page scripts all entryPoints and
externalServices with ajax bindings in the web app. EntryPoints enable the
the browser client to invoke SCA components on the server, externalServices
enable server SCA components to invoke methods on the browser client.

Scripts invoke entryPoints just like any JavaScript function, in the chat
sample there's one entryPoint called "ChatService",
and its used in the sendChat function with the statement:

 ChatService.chat(msg);

ExternalServices are slightly different. The HTML page scripts need to
define functions for each operation on the externalService
interface. In the chat sample there's a single externalService defined named
"ChatBroadcastService", and that has a single method
called "chat", so in the HTML script a function is defined for that:

  ChatBroadcastService.chat = function(msg) {
 var chatLog = document.getElementById('chatLog');
 chatLog.innerHTML = msg + '' + chatLog.innerHTML;
  }

To receive the externalService method calls the HTML script needs to open a
connection to the sever, thats done with the SCA.open call which in the chat
sample is done in the onLoad method:

 

There's also a corresponding SCA.close function which can be called
explicitly, or the connection is closed when the browser closes the page.

This is slightly different to the way the existing JSON-RPC binding (which
only supports entryPoints) works. In the JSON-RPC binding the entryPoints
are bound to an SCA object, so for example with the JSON-RPC binding the
ChatService entryPoint would be invoked with the SCA. prefix:

SCA.ChatService.chat(msg);

Can easily also do this for entryPoints and externalSevrices in the the AJAX
binding, perhaps including the SCA. prefix makes things clearer, does anyone
have a preference?

Any comments?

  ...ant

Re: [VOTE] Publish Tuscany M1 release - 2nd vote

[ant elder]

The NOTICE file doesn't include mention of Woodstox or JSON-RPC-Java and all
the stuff included with the Celtix binding - Spring, Jetty, ActiveMQ (thats
a pre-Apache release right?), and all those Sun jars (which presumably we
really are allowed to be distributing?)?

Reading about the NOTICE file it wasn't completely clear to me what must be
included so if this is going over old ground and those things don't need to
be included then +1 from me for this M1 distribution.

  ...ant

On 5/22/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Hi!

I created source and binary distributions of the latest Tuscany
Milestone 1 release candidate level (SVN revision r408581) and placed
them in my home directory:

http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1-src.tar.gz

http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1-src.zip




http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1.tar.gz


http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubating-M1.zip


I also tagged this level of code as
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060522 .

Solid progress has been made to produce this Milestone release, and I
think it is in a good shape. The list of JIRA issues resolved and closed
in this Milestone 1 release is here:
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&fixfor=12311030&fixfor=12311061&version=12311030&version=12311061&status=5&status=6&sorter/field=priority&sorter/order=DESC



The only difference between this release candidate and the previous
release candidate is the fix for JIRA TUSCANY-414 (feedback from the
incubator list, see http://issues.apache.org/jira/browse/TUSCANY-414).
I moved the previous release candidate to
http://people.apache.org/~jsdelfino/test-incubating-M1/RC-history/RC4
.

Instructions on setting up your environment to use Tuscany and getting
started with the Tuscany samples are in the README.txt and
GettingStarted.htm files contained in the distributions. These files can
also be downloaded from here:
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060522/java/README.txt



http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060522/java/GettingStarted.htm


I tested the binary and source distributions in the following
environments:
Redhat Enterprise Linux 4 - Java JDK 5.0 update 06 - Maven 2.0.4 -
Apache Ant 1.6.5
Windows XP SP2 - Java JDK 5.0 update 06 - Maven 2.0.4 - Apache Ant 1.6.5

Please vote to publish the Milestone 1 release distributions. Please
take some time to download the distributions, review them and test them
in your environment before voting.

The vote is open for the next 72 hours, please vote by Thursday May 25,
10am PDT. At least three +1 votes are required, and only the votes from
Tuscany committers are binding. If the majority of all votes is
positive, I will send a summary of that vote to the Incubator's general
list to formally request the Incubator PMC to approve the Tuscany
Milestone 1 release. For your reference the Incubator release policy
guidelines are available at
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases.

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Getting list of components in a module

[ant elder]

I've a J2SE client that needs to get a list of all the components defined in
the current module, is that possible? There used to be the getMetaData
method but thats been removed now.  If there is no easy way right now could
i add something?

  ...ant

Re: [VOTE] Publish Tuscany M1 release - 2nd vote

[Daniel Kulp]

+1

Dan


On Monday 22 May 2006 13:39, Jean-Sebastien Delfino wrote:
> Hi!
>
> I created source and binary distributions of the latest Tuscany
> Milestone 1 release candidate level (SVN revision r408581) and placed
> them in my home directory:
> http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubati
>ng-M1-src.tar.gz
>
> http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubati
>ng-M1-src.zip
>
> http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubati
>ng-M1.tar.gz
>
> http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-incubati
>ng-M1.zip
>
>
> I also tagged this level of code as
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060522
>.
>
> Solid progress has been made to produce this Milestone release, and I
> think it is in a good shape. The list of JIRA issues resolved and
> closed in this Milestone 1 release is here:
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pi
>d=12310210&fixfor=12311030&fixfor=12311061&version=12311030&version=1231
>1061&status=5&status=6&sorter/field=priority&sorter/order=DESC
>
>
> The only difference between this release candidate and the previous
> release candidate is the fix for JIRA TUSCANY-414 (feedback from the
> incubator list, see http://issues.apache.org/jira/browse/TUSCANY-414).
> I moved the previous release candidate to
> http://people.apache.org/~jsdelfino/test-incubating-M1/RC-history/RC4.
>
> Instructions on setting up your environment to use Tuscany and getting
> started with the Tuscany samples are in the README.txt and
> GettingStarted.htm files contained in the distributions. These files
> can also be downloaded from here:
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060522
>/java/README.txt
>
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java-M1-20060522
>/java/GettingStarted.htm
>
>
> I tested the binary and source distributions in the following
> environments: Redhat Enterprise Linux 4 - Java JDK 5.0 update 06 -
> Maven 2.0.4 - Apache Ant 1.6.5
> Windows XP SP2 - Java JDK 5.0 update 06 - Maven 2.0.4 - Apache Ant
> 1.6.5
>
> Please vote to publish the Milestone 1 release distributions. Please
> take some time to download the distributions, review them and test them
> in your environment before voting.
>
> The vote is open for the next 72 hours, please vote by Thursday May 25,
> 10am PDT. At least three +1 votes are required, and only the votes from
> Tuscany committers are binding. If the majority of all votes is
> positive, I will send a summary of that vote to the Incubator's general
> list to formally request the Incubator PMC to approve the Tuscany
> Milestone 1 release. For your reference the Incubator release policy
> guidelines are available at
> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727  C: 508-380-7194
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]