[jira] Updated: (TUSCANY-120) Axis2 WS binding support for entryPoint without pre-existing WSDL

[Venkatakrishnan (JIRA)]

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

Venkatakrishnan updated TUSCANY-120:


Attachment: Tuscany-Java2WSDL-Patch-Jul-17.diff

I did not include a testcase for demonstrating the specification of schema 
locations externally.  I have now included that in this patch.  So please use 
this patch instead of the previous one.  

My sincere apologies for this confusion.  

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
>  Issue Type: Bug
>  Components: Java SCA Axis Binding
>Affects Versions: Java-Mx
>Reporter: ant elder
> Assigned To: Raymond Feng
> Fix For: Java-Mx
>
> Attachments: java2wsdl-codegen.zip, 
> Tuscany-Java2WSDL-Patch-Jul-16.diff, Tuscany-Java2WSDL-Patch-Jul-17.diff, 
> Tuscany-Java2WSDL-SDO-Jun-29.diff, 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: 
> 
>  interface="org.apache.tuscany.binding.axis2.assembly.tests.bigbank.account.services.account.AccountService"/>
> 
> AccountServiceComponent
> 
> 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: WorkManager in JavaComponentBuilder

[Meeraj Kunnumpurath]

Jim,

Could you pls have a look and apply the attached patch.

Ta
Meeraj

 

-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] 
Sent: 15 July 2006 22:50
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder

Jim,

I think it's ok, if I understand it right.

I think the Tuscany runtime components should only know about the
WorkScheduler abstraction. We will configure a Jsr237 or JCA work
scheduler based on the host environment and configure it with an
appropriate work manager provided by the host environment. If no work
managers are available, by default we will use the Jsr237WorkScheduler
configured with the ThreadPoolWorkManager.

BTW, If you are working on this tonight (or today for you), could you
pls remove the synchronized keyword from the ThreadPoolWorkManager
callback methods. The underlying collection I use for keeping track of
the listeners is thread-safe.

Ta
Meeraj

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:56
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder

Thanks Meeraj,

I forgot about the abstraction conversation about a week back...So I'm
just thinking about how to get this into a system service. What do you
think of this:

1. Add @Autowire to the Jsr237WorkScheduler constructor as in

@Constructor("workManager")
  public Jsr237WorkScheduler(@Autowire WorkManager jsr237WorkManager) {
//...
  }

2. Configure ThreadPoolWorkManager as a system service.

The runtime will autowire them together.

3. Have JavaComponentBuilder (or better, ComponentBuilderExtension) have
an autowire to WorkScheduler


For Step 1, we need to add the @Constructor tag for now - I need to make
a few changes to the annotation processing to allow just specifying
@Autowire on the param.

Jim



On Jul 15, 2006, at 1:41 PM, Meeraj Kunnumpurath wrote:

> Jim/Ignacio,
>
> There is abstract called WorkScheduler in the SPI, that hides whether 
> you are using a JCA or commonj work manager. The two implementations 
> are JcaWorkScheduler and Jsr237WorkScheduler. The Jsr237WorkScheduler 
> can be injected with a ThreadPoolWorkManager. This way, depending on 
> the host environment we can inject a work manager provided by the 
> environment.
>
> Ta
> Meeraj
>
> -Original Message-
> From: Jim Marino [mailto:[EMAIL PROTECTED]
> Sent: 15 July 2006 21:38
> To: tuscany-dev@ws.apache.org
> Subject: Re: WorkManager in JavaComponentBuilder
>
> Forgot to mention (you may already know this):
>
> You can use Meeraj's work manager, ThreadPoolWorkManager, as the 
> system service.
>
> Jim
>
>
> On Jul 15, 2006, at 1:34 PM, Jim Marino wrote:
>
>> Ignacio,
>>
>> Can you check the package name of WorkManager? It should be 
>> commonj.work.WorkManager as opposed to 
>> javax.resource.spi.work.WorkManager? Using comonj on my machine 
>> compiles and runs.
>>
>> Once you get past that, you'll need to have the work manager system 
>> service deployed as part of the runtime.  Could you add this to the 
>> system.scdl in the launcher project under ../main/resource/META-INF/ 
>> tuscany? Once you have changed JavaComponentBuilder to add the 
>> autowire, the WorkManager should be picked up.
>>
>> If you could submit the changes as a patch, I'll add them to the 
>> repo.
>>
>> Thanks,
>> Jim
>>
>>
>>
>> On Jul 15, 2006, at 12:43 PM, Ignacio Silva-Lepe wrote:
>>
>>> All I do is to run mvn from chianti/sca, after adding the autowire 
>>> to
>
>>> JavaComponentBuilder
>>> - Original Message - From: "Jim Marino"
>>> <[EMAIL PROTECTED]>
>>> To: 
>>> Sent: Saturday, July 15, 2006 2:59 PM
>>> Subject: Re: WorkManager in JavaComponentBuilder
>>>
>>>

 On Jul 15, 2006, at 11:45 AM, Ignacio Silva-Lepe wrote:

> To allow JavaAtomicComponent to create a new 
> AsyncJavaTargetInvoker, it needs to supply the new target invoker 
> with a work manager. My first try (which may not be the 
> appropriate
>
> thing to do) was to get a work manager autowired into 
> JavaComponentBuilder, which then passes it to JavaAtomicComponent.
 That is how I would do it.

> However when I do this I get a NoClassDefFoundError when the build
>
> tries to run the samples (local.wire, local.wire.cdi, calculator).
>
> I could add the dependency to each sample's pom.xml, which seems 
> to
>
> eliminate the  error sample by sample. Or I could add the 
> dependency to the entire  samples directory's pom.xml, which at 
> the
>
> moment has no  dependencies. Or I could just be doing the wrong 
> thing and I should  supply the work manager in some other way.
> Thoughts?

 The work manager dependency shouldn't be surfaced to the samples 
 since it is an implementation detail of the runtime.  How are you 
 executing the samples? I'm wondering if the appropriate jars are 
 not
>
 being put on the classpath?

 Jim



>

C++ Some inconsistencies in the prereqs in several files.

[Rick]

cpp\sdo\projects\tuscany_sdo\build_instructions.txt
 The versions required are these:
 libxml2-2.6.20.win32
 iconv-1.9.1.win32
 zlib-1.2.2.win32

cpp/sdo/GettingStarted.html
has
 libxml2 version 2.6.20
(no mention of the others)

cpp\build.txt
Prereqs:
- libxml2 (tested with version 2.6.19)
(no mention of the others)

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

Re: C++ Some inconsistencies in the prereqs in several files.

[Pete Robbins]

thanks. I'll correct those

Cheers,


On 17/07/06, Rick <[EMAIL PROTECTED]> wrote:


cpp\sdo\projects\tuscany_sdo\build_instructions.txt
The versions required are these:
 libxml2-2.6.20.win32
 iconv-1.9.1.win32
 zlib-1.2.2.win32

cpp/sdo/GettingStarted.html
has
libxml2 version 2.6.20
(no mention of the others)

cpp\build.txt
Prereqs:
- libxml2 (tested with version 2.6.19)
(no mention of the others)

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





--
Pete

[jira] Updated: (TUSCANY-532) M1 documentation improvements

[Andrew Borley (JIRA)]

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

Andrew Borley updated TUSCANY-532:
--

Attachment: TUSCANY-532-6.patch

Patch 532-6 adds a GettingStarted doc for the SDO sample and a run_sdo_misc.cmd 
file to set up paths, etc on Windows

> M1 documentation improvements
> -
>
> Key: TUSCANY-532
> URL: http://issues.apache.org/jira/browse/TUSCANY-532
> Project: Tuscany
>  Issue Type: Improvement
>  Components: C++ Build
>Affects Versions: Cpp-M1
>Reporter: Andrew Borley
> Attachments: TUSCANY-532-2.patch, TUSCANY-532-3.patch, 
> TUSCANY-532-4.patch, TUSCANY-532-5.patch, TUSCANY-532-6.patch, 
> TUSCANY-532.patch
>
>
> Clear up documentation by addressing the various issues raised on the mailing 
> list.

-- 
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: Component start order

[Jeremy Boynes]

On Jul 14, 2006, at 12:43 PM, Jeremy Boynes wrote:



Instead I'd like to propose we support an init-level indicator like  
the run level from Unix systems. Components would be started in  
ascending order of the init level they provided.


This could be done as an attribute on the  element,  
something like:


 ...
 ...

This would also allow us to eagerly initialize components without  
having to use an @Init annotation.


I added support for this over the weekend, at least on the  
 definition. Support is in the runtime to support this on  
a componentType but I have not changed the loader yet. I have not  
done anything with annotations as from what we were talking about it  
sounded like we would need spec changes. The boolean eager=true  
option on @Init is implemented as setting an initLevel of 50.


--
Jeremy


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

Re: Loading extensions in chianti

[Jeremy Boynes]

On Jul 13, 2006, at 9:36 AM, Jeremy Boynes wrote:

I was thinking of how to load extensions into a chianti runtime and  
had the following ideas:


The first idea was to have a directory into which people could  
place composites (as jar files or whatever the packaging unit is)  
which is scanned by a system service included with the boot  
runtime. All the composites found there are used to create  
components that are added in to the system composite.


This approach should work now for the standalone runtime. If you  
create an "extension" directory where you extract the archive any  
composite jars placed in there will be added into the runtime. I  
tested this with the eagerinit sample and it worked but please let me  
know if there are any issues.


I've not looked at the other approach using maven dependencies - is  
anyone interested in it?

--
Jeremy


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

Re: Chianti extension manual

[Eric Le Goff]

I guess docbook (http://www.docbook.org/) is often used for this kind of docs
My 2 cents.

On 7/13/06, Jim Marino <[EMAIL PROTECTED]> wrote:

I've started a manual for extending Chianti. It's obviously very
rough and missing many pieces but comments and contributions are
welcome. If you plan on editing it, please let me know so we don't
collide.

Also, this is a good point to raise the question of how we want to
construct user manuals. I seem to recall Hibernate having a good
process which results in the output of multiple formats, including
pdf, single page html, and multi-page html.  Any suggestions? For the
time being, I've left it in Word but plan to switch to a more "open"
format.

Jim


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





--
Eric LE GOFF

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

Re: WorkManager in JavaComponentBuilder

[Ignacio Silva-Lepe]

I'm a bit confused by this. I added:








to system.scdl as per Jim's directions, did a mvn clean and mvn of sca and
nothing seems to be happening (I even do a mvn clean and mvn of the top to
no avail). Not sure whether or where I should be adding the code below by
Meeraj. Here's where I autowire into JavaComponentBuilder:

   @Autowire
   public void setWorkManager(WorkManager workManager) {
   this.workManager = workManager;
   }

Any ideas?
Thanks
- Original Message - 
From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]>

To: 
Sent: Saturday, July 15, 2006 4:45 PM
Subject: RE: WorkManager in JavaComponentBuilder


The injection sequence should be something like,

WorkManager workManager = new ThreadPoolWorkManager(10);
WorkScheduler workScheuler = new Jsr237WorkScheduler(workManager);
AsyncTargetInvoker invoker = new  AsyncTargetInvoker(workScheuler); //
Sorry I don't know the signature for the constructor

As Jim rightly mentioned you need the commonj classes.

Ta
Meeraj

-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:42
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder

Jim/Ignacio,

There is abstract called WorkScheduler in the SPI, that hides whether
you are using a JCA or commonj work manager. The two implementations are
JcaWorkScheduler and Jsr237WorkScheduler. The Jsr237WorkScheduler can be
injected with a ThreadPoolWorkManager. This way, depending on the host
environment we can inject a work manager provided by the environment.

Ta
Meeraj

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:38
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder

Forgot to mention (you may already know this):

You can use Meeraj's work manager, ThreadPoolWorkManager, as the system
service.

Jim


On Jul 15, 2006, at 1:34 PM, Jim Marino wrote:


Ignacio,

Can you check the package name of WorkManager? It should be
commonj.work.WorkManager as opposed to
javax.resource.spi.work.WorkManager? Using comonj on my machine
compiles and runs.

Once you get past that, you'll need to have the work manager system
service deployed as part of the runtime.  Could you add this to the
system.scdl in the launcher project under ../main/resource/META-INF/
tuscany? Once you have changed JavaComponentBuilder to add the
autowire, the WorkManager should be picked up.

If you could submit the changes as a patch, I'll add them to the repo.

Thanks,
Jim




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

RE: WorkManager in JavaComponentBuilder

[Meeraj Kunnumpurath]

Ignacio,

I think, the JavaComponentBuilder should be using an implementation of
the org.apache.tuscany.spi.services.work.WorkScheduler interface, rather
than the commonj WorkManager directly. This will allow us to switch to a
JCA, commonj or any other implementation that is available based on the
host in which tuscany runs.

For example a possible dependency hierarchy would be
JavaComponentBuilder -> Jsr237WorkScheduler -> ThreadPoolWorkManager
(This is using a commonj work scheduler using our own thread pool based
commonj work manager implementation. If the host system uses Geronimo
JCA work manager, this could be JavaComponentBuilder -> JcaWorkScheduler
-> GeronimoWorkManager. The gist is for the work scheduler to abstract
the work management implementation mechanism.

hth
Meeraj

-Original Message-
From: Ignacio Silva-Lepe [mailto:[EMAIL PROTECTED] 
Sent: 17 July 2006 16:37
To: Tuscany Dev
Subject: Re: WorkManager in JavaComponentBuilder

I'm a bit confused by this. I added:








to system.scdl as per Jim's directions, did a mvn clean and mvn of sca
and nothing seems to be happening (I even do a mvn clean and mvn of the
top to no avail). Not sure whether or where I should be adding the code
below by Meeraj. Here's where I autowire into JavaComponentBuilder:

@Autowire
public void setWorkManager(WorkManager workManager) {
this.workManager = workManager;
}

Any ideas?
Thanks
- Original Message -
From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, July 15, 2006 4:45 PM
Subject: RE: WorkManager in JavaComponentBuilder


The injection sequence should be something like,

WorkManager workManager = new ThreadPoolWorkManager(10);
WorkScheduler workScheuler = new Jsr237WorkScheduler(workManager);
AsyncTargetInvoker invoker = new  AsyncTargetInvoker(workScheuler); //
Sorry I don't know the signature for the constructor

As Jim rightly mentioned you need the commonj classes.

Ta
Meeraj

-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:42
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder

Jim/Ignacio,

There is abstract called WorkScheduler in the SPI, that hides whether
you are using a JCA or commonj work manager. The two implementations are
JcaWorkScheduler and Jsr237WorkScheduler. The Jsr237WorkScheduler can be
injected with a ThreadPoolWorkManager. This way, depending on the host
environment we can inject a work manager provided by the environment.

Ta
Meeraj

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:38
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder

Forgot to mention (you may already know this):

You can use Meeraj's work manager, ThreadPoolWorkManager, as the system
service.

Jim


On Jul 15, 2006, at 1:34 PM, Jim Marino wrote:

> Ignacio,
>
> Can you check the package name of WorkManager? It should be
> commonj.work.WorkManager as opposed to
> javax.resource.spi.work.WorkManager? Using comonj on my machine
> compiles and runs.
>
> Once you get past that, you'll need to have the work manager system
> service deployed as part of the runtime.  Could you add this to the
> system.scdl in the launcher project under ../main/resource/META-INF/
> tuscany? Once you have changed JavaComponentBuilder to add the
> autowire, the WorkManager should be picked up.
>
> If you could submit the changes as a patch, I'll add them to the repo.
>
> Thanks,
> Jim



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


This message has been checked for all email viruses by MessageLabs.




*

You can find us at www.voca.com

*
This communication is confidential and intended for 
the exclusive use of the addressee only. You should 
not disclose its contents to any other person.
If you are not the intended recipient please notify 
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX


This message has been checked for all email viruses by MessageLabs.

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

[C++] Visual C++ Express Edition compiling SDO

[Rick]

Tried compiling the Tuscany SDO CPP with MS Visual C++ 2005 Express 
Edition  http://msdn.microsoft.com/vstudio/express/visualC/default.aspx
which you can download for free, but need to eventually register for (no 
charge though).
I got it to compile/link have not tested it yet.  Here are the changes I 
needed to do. I also don't know if they present an issue with the 6/7 MS 
developer or Linux compiler


Index: sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp

===

--- sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp(revision 422669)

+++ sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp(working copy)

@@ -537,9 +537,9 @@


if (propertyName == 0 || strlen(propertyName) == 0) return 0;

-char*tokenend= strchr(propertyName,'/');
-char *bracket= strchr(propertyName,'[');
-char*dot= strchr(propertyName,'.');
+char*tokenend= (char*) strchr(propertyName,'/');
+char *bracket=  (char*) strchr(propertyName,'[');
+char*dot=  (char*) strchr(propertyName,'.');
char*   copy;
   


Index: sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp

===

--- sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp(revision 
422669)


+++ sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp(working copy)

@@ -1871,7 +1871,7 @@

if (!strcmp(tl[i].getURI(),"commonj.sdo")) continue;

const char *uri = tl[i].getURI();
-char *c = strchr(uri,'.');
+char *c = (char*)strchr(uri,'.');

if (c == 0)
{
@@ -1922,7 +1922,7 @@


const char *uri = tl[i].getURI();
const char *name = tl[i].getName();
-char* the_uri = strchr(uri,'.');
+char* the_uri = (char*) strchr(uri,'.');

if (the_uri == 0)
{
@@ -1993,7 +1993,7 @@


if (!strcmp(tl[i].getURI(),"commonj.sdo")) continue;
const char *uri = tl[i].getURI();
-char *c = strchr(uri,'.');
+char *c = (char*) strchr(uri,'.');

if (c == 0)
{
Index: sdo/runtime/core/src/commonj/sdo/DataObjectImpl.cpp

===

--- sdo/runtime/core/src/commonj/sdo/DataObjectImpl.cpp(revision 422669)

+++ sdo/runtime/core/src/commonj/sdo/DataObjectImpl.cpp(working copy)

@@ -1313,7 +1313,7 @@

DataObjectImpl* cont = d->getContainerImpl();
if (cont != 0)
{
-pc = strrchr(path,'/');
+pc = (char*) strrchr(path,'/');
if (pc != 0)pc++;
}
const Property& pcont = cont->getProperty(pc);
@@ -2108,7 +2108,7 @@

}

DataObjectImpl* d;
-char*  i = strchr(path,'/');
+char*  i = (char*) strchr(path,'/');
char* remaining = 0;
char* token = 0;


Index: sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp
===
--- sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp   (revision 422669)
+++ sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp   (working copy)
@@ -537,9 +537,9 @@
 
 if (propertyName == 0 || strlen(propertyName) == 0) return 0;
 
-char*tokenend= strchr(propertyName,'/');
-char *bracket= strchr(propertyName,'[');
-char*dot= strchr(propertyName,'.');
+char*tokenend= (char*) strchr(propertyName,'/');
+char *bracket=  (char*) strchr(propertyName,'[');
+char*dot=  (char*) strchr(propertyName,'.');
 char*   copy;
 
 
Index: sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp
===
--- sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp(revision 
422669)
+++ sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp(working copy)
@@ -1871,7 +1871,7 @@
 if (!strcmp(tl[i].getURI(),"commonj.sdo")) continue;
 
 const char *uri = tl[i].getURI();
-char *c = strchr(uri,'.');
+char *c = (char*)strchr(uri,'.');
 
 if (c == 0)
 {
@@ -1922,7 +1922,7 @@
 
 const char *uri = tl[i].getURI();
 const char *name = tl[i].getName();
-char* the_uri = strchr(uri,'.');
+char* the_uri = (char*) strchr(uri,'.');
 
 if (the_uri == 0)
 {
@@ -1993,7 +1993,7 @@
 
 if (!strcmp(tl[i].getURI(),"commonj.sdo")) continue;
 const char *uri = tl[i].getURI();
-char *c = strchr(uri,'.');
+char *c = (char*) strchr(uri,'.');
 
   

Re: Queries on certain M2 concepts

[Jim Marino]

Hi comments inline
On Jul 16, 2006, at 10:17 PM, rakesh dash wrote:


Hello,

I am starting to understand the basics of certain M2 related
concepts and am trying to navigate the src tree of the run time.
It would be great if someone may clarify few of my basic queries on  
it. My
apologies in advance, if I have misinterpreted any concept wrongly.  
Please

rectify it and clarify. Thanks in advance.

1. Due to various reasons the existing core architecture was  
considered to
have substantial refactoring.It would be great if an one to one  
mapping
could be established between these reasons and how the new update  
in the

core/runime may solve it.This may help us to get a good understanding.

We did a long presentation on this a while back. Unfortunately, it  
was not recorded (a good reason why mailing list discussion is better  
than presentations). There are slides from this under sandbox/chianti/ 
doc that lay out the reasoning behind the refactors and basic chianti  
architecture. I would have a look there and post questions to the  
list as they arise.



2. How the new model reduces the number of SCA concepts?
For example-composite seems to be more bulkier than the previous  
'module' in
M1. In the 'composite' model most of the concepts are similar to  
the module.

An added properties field is present. While composite adds more
functionality, it seems to be making the simplest SCA component more
complicated.
I think it actually reduces the number of concepts since we no longer  
have the module component specialization. The design is also more  
symmetrical.


Just a side note, a module and a composite are different concepts,  
the former being more about a unit of deployment, which is something  
we haven't addressed very well in the spec as of yet.



As a different instance, the wiring concept has inbound and outbound
concepts which has interceptors and other features. Again making  
things

complicated.Please clarify.

We have these two concepts for several reasons:
- In SCA, policies can be applied to the source (outbound) or target  
(inbound) side of a wire
- We need to have the ability to re-wire at runtime, e.g. change a  
target and reconstitute the wire. IMO having two sides like this  
actually reduces the complexity in performing this operation


That said, I do agree the runtime invocation model is complex. The  
important question is whether it is more complex than it needs to be.  
That said, we always need to look at simplifying the design without  
loosing capabilities. I do think, however, there is always going to  
be a base level of complexity to meet the use cases we have in mind  
(see below). It would be good to have more eyes on simplifying the  
design so any help would be greatly appreciated.




3. While I am not sure of how the target Invoker dispatches a  
request to the

target implementation, I think the TargetInvoker will have address or
reference for the Target instance using which it may locate the target
implementation.
In the slides mentioned above, there is a section which explains  
this. One of the key things about the runtime (and SCA in general) is  
that it attempts to perform static analysis on wires since it most  
often knows the source and target, optimizing where appropriate. This  
is one of the key differences with other approaches such as JBI.   
Hence, most of the time a TargetInvoker (which is per operation, not  
per service) is set to the target *component* and no dynamic routing  
is necessary. The one detail here is that it is not necessarily set  
to the target component *instance*; during an invocation it is the  
job of the component to delegate to its scope container to return the  
correct instance.


There are two caveats to the above. First, one optimization is that  
certain target invokers may cache the target instance (e.g. when  
invoking from a "lesser" scope to a "larger" scope, session--- 
>module). The other caveat is that for callbacks we will need a way  
to dereference the correct callback instance. I'm not sure this is  
the job of the target invoker, though.


Now is it possible to represent this address or reference in such a  
format

which can be stored and saved in file?
I would say it has to be "serializable" in some form supported by the  
transport binding (in the case of in-VM, Java serializable, other  
protocol bindings may have different requirements).

This may give another option using
which the wire invocation handler(at the source)may locate the target
address. This may avoid storing always storing the TargetInvoker to  
the
source wire invocation handler everytime before an invocation is  
initiated.
Again, I think the important thing here is static optimization. For  
*all* component-to-component invocations in SCA, the source and  
targets are known since all remote wiring must be done through  
composite references and services. Hence, there is no reason to  
perform an address lookup at this le

Re: WorkManager in JavaComponentBuilder

[Jim Marino]

Yep will do. Give me a few hours to catch up on some stuff and I'll  
check it in.  Thanks!


Jim


On Jul 17, 2006, at 2:25 AM, Meeraj Kunnumpurath wrote:


Jim,

Could you pls have a look and apply the attached patch.

Ta
Meeraj



-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 22:50
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder

Jim,

I think it's ok, if I understand it right.

I think the Tuscany runtime components should only know about the
WorkScheduler abstraction. We will configure a Jsr237 or JCA work
scheduler based on the host environment and configure it with an
appropriate work manager provided by the host environment. If no work
managers are available, by default we will use the Jsr237WorkScheduler
configured with the ThreadPoolWorkManager.

BTW, If you are working on this tonight (or today for you), could you
pls remove the synchronized keyword from the ThreadPoolWorkManager
callback methods. The underlying collection I use for keeping track of
the listeners is thread-safe.

Ta
Meeraj

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:56
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder

Thanks Meeraj,

I forgot about the abstraction conversation about a week back...So I'm
just thinking about how to get this into a system service. What do you
think of this:

1. Add @Autowire to the Jsr237WorkScheduler constructor as in

@Constructor("workManager")
  public Jsr237WorkScheduler(@Autowire WorkManager  
jsr237WorkManager) {

//...
  }

2. Configure ThreadPoolWorkManager as a system service.

The runtime will autowire them together.

3. Have JavaComponentBuilder (or better, ComponentBuilderExtension)  
have

an autowire to WorkScheduler


For Step 1, we need to add the @Constructor tag for now - I need to  
make

a few changes to the annotation processing to allow just specifying
@Autowire on the param.

Jim



On Jul 15, 2006, at 1:41 PM, Meeraj Kunnumpurath wrote:


Jim/Ignacio,

There is abstract called WorkScheduler in the SPI, that hides whether
you are using a JCA or commonj work manager. The two implementations
are JcaWorkScheduler and Jsr237WorkScheduler. The Jsr237WorkScheduler
can be injected with a ThreadPoolWorkManager. This way, depending on
the host environment we can inject a work manager provided by the
environment.

Ta
Meeraj

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:38
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder

Forgot to mention (you may already know this):

You can use Meeraj's work manager, ThreadPoolWorkManager, as the
system service.

Jim


On Jul 15, 2006, at 1:34 PM, Jim Marino wrote:


Ignacio,

Can you check the package name of WorkManager? It should be
commonj.work.WorkManager as opposed to
javax.resource.spi.work.WorkManager? Using comonj on my machine
compiles and runs.

Once you get past that, you'll need to have the work manager system
service deployed as part of the runtime.  Could you add this to the
system.scdl in the launcher project under ../main/resource/META-INF/
tuscany? Once you have changed JavaComponentBuilder to add the
autowire, the WorkManager should be picked up.

If you could submit the changes as a patch, I'll add them to the
repo.

Thanks,
Jim



On Jul 15, 2006, at 12:43 PM, Ignacio Silva-Lepe wrote:


All I do is to run mvn from chianti/sca, after adding the autowire
to



JavaComponentBuilder
- Original Message - From: "Jim Marino"
<[EMAIL PROTECTED]>
To: 
Sent: Saturday, July 15, 2006 2:59 PM
Subject: Re: WorkManager in JavaComponentBuilder




On Jul 15, 2006, at 11:45 AM, Ignacio Silva-Lepe wrote:


To allow JavaAtomicComponent to create a new
AsyncJavaTargetInvoker, it needs to supply the new target invoker
with a work manager. My first try (which may not be the
appropriate



thing to do) was to get a work manager autowired into
JavaComponentBuilder, which then passes it to  
JavaAtomicComponent.

That is how I would do it.

However when I do this I get a NoClassDefFoundError when the  
build


tries to run the samples (local.wire, local.wire.cdi,  
calculator).



I could add the dependency to each sample's pom.xml, which seems
to



eliminate the  error sample by sample. Or I could add the
dependency to the entire  samples directory's pom.xml, which at
the



moment has no  dependencies. Or I could just be doing the wrong
thing and I should  supply the work manager in some other way.
Thoughts?


The work manager dependency shouldn't be surfaced to the samples
since it is an implementation detail of the runtime.  How are you
executing the samples? I'm wondering if the appropriate jars are
not



being put on the classpath?

Jim



-- 
-



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

Website work

[Jeremy Boynes]

On IRC this morning we chatted about the changes to the site to  
address some of the comments we had at ApacheConEU.


Last week I checked the toolkit from the incubator site into sandbox/ 
jboynes/site as a possibly simpler alternative to using maven to  
generate the site. A few people offered to help flesh this out with  
content:

* jboynes on layout and nav
* slaws on "what is SCA"
* kgoodson on "what is SDO"
* kevin on DAS
* cr22rc on toolkit stuff
* dwheeler on images

We could really use some help with non-Java content. I know the C++  
people are busy with getting a release out but if you could take a  
couple minutes to see what we're doing it would be appreciated.


Given the different people looking at this, I will move the directory  
out to sandbox/site


--
Jeremy


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

Tuscany weekly IRC chat log (July-06-2006)

[Simon Laws]

Here is the discussion from today's IRC chat (sorry about the slightly wonky
format as I had to cut and paste from my client). The topics of discussion
were content updates to the Tuscany web site and the process by which the
web site is produced. In summary we are going to progress the following this
week.

   jboyneslayout and nav,
   slaws   "what is SCA",
   kgoodson "what is SDO"
   kevinDAS
   cr22rc   help with the web site production toolkit and site content
as time allows
  dwheelerimage stuff

Of course everyone is invited to help out here so don't be shy.

Simon



shall we pick up where we were on improving the website with a
clickable picture before OSCon?
   what other topics?
   -->|kevin (n= [EMAIL PROTECTED]) has joined
#tuscany
   i'm just back on line form leave and saw mail about the
website, e.g. the nice clickable picture, but i'm confused about what the
status is and who is doing what - can you give a quick update
   The OSCON is coming, I guess we need to improve the web site
as we agreed last time, right?
   -->|simonnash (n= [EMAIL PROTECTED] ) has joined #tuscany
   hi
   hi simon - kelivin is just kicking off a discussion on
website progress
   hi, sorry, I'm back as well
   hi simon, it's a little quiet, but we are just about to
take stock of where the website improvemnt is/is going -- there don't seem
tyo be any other topics at the moment -- jeremy has had to disappear
   we have a clckable on the wiki, yes?
   i liked raymonds picture, with the clickable links, there
was aanother picture on the mailing list i think that I cant locate at the
moment which was a higher level modular diagram
   hes, clickable 
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca.htm

   the other one is for tuscany architectural layers, I guess
   yes - high level - was attached as a zip to a mail
   can somebody upload it to WIKI as well?
   yes, am i right in thinking that the one you, rfeng, have
done would be linked to from the higher level one?
   high level one was on a mail from Venkata Krishnan
   the one I prototyped is for SCA composite PM
   -->|jmarino ([EMAIL PROTECTED] ) has joined #tuscany
   can;t find it in the dev archive for some reason
   have found it, i will attach to wiki
   ok - great
   I checked the toolkit from the incubator site into my
sandbox - has anyone had a chance to look at it?
   sorry jeremy - have been out - is this the toolkit for
building the website?
   wiki seems not to want to create a new page, waiting
..
   slaws: yes, the toolkit I mentioned last time which has
been picked up by a couple of projects (including the incubator)
   just point to the new URL you want to place the new page,
then you'll see the option to create the new page
   jboynes: ok - ta - haven't tried it yet but can give it a
whirl
   ok
   anyone else interested or does anyone have any
alternatives?
   yes i'm intersted but i don't really know what it buys us
   it's simpler than mvn
   so, coming back to my first question, who is doing what on
the website?
   I set up the toolkit thing and was waiting for feedback
   just a command to run for mvn
   ?
   xdocs are a pain ... does it get us away from that ?
   I'm stuck in something else this week
   you can use xml or html
   ok - and rfeng made the clickable diagram and we also have a
top level diagram contributed - anything else?
   I believe I was going to try and come up with a prettier
diagram(s) for the clickable diagram interface.
   I need to look at the other TK too see what it buys us
   based on the ones we have
   finally i have the architecture diag n the wiki ...
   
http://wiki.apache.org/ws/Tuscany/ClickableImages?action=show

   to do the site now it's mvn site ... and then mvn
site-deploy (which publishes it )
   I think the big difference is that there's less going on
than with mvn site
   everything is in one place and not spread around different
modules
   most of the site is just under site
   the one thing we don't get with mvn I think is tabs on the
top... don't think you can do that.
   with the toolkit you get raw html so can do anything
   but you need to do everything ..
   just to summarize, we were looking for the tabs of
http://geronimo.apache.org/ with the image navigation style of
http://incubator.apache.org/servicemix/
   perhaps it would be worth extending the strawman to include
tabs etc (at least the high level nav)
   I *assume* for OSCON we are going with M1 ?
   i think that is a safe assumption in terms of getting people
to download and try it
   there will be C++ also
   (correction to my above summary, servicemix 

[PATCH] Tuscany-543 DAS: Consider using a URI to identify Static SDO Types in config model

[Brent Daniel]

Attached is a patch to switch our runtime and existing static type
tests over to using an SDO type URI in the config rather than the name
of a single Type.

Brent
Index: src/test/java/org/apache/tuscany/das/rdb/test/ExceptionTests.java
===
--- src/test/java/org/apache/tuscany/das/rdb/test/ExceptionTests.java   
(revision 422736)
+++ src/test/java/org/apache/tuscany/das/rdb/test/ExceptionTests.java   
(working copy)
@@ -61,7 +61,19 @@
 
 }
 
+public void testUnregisteredTypes() throws Exception {
+   DAS das = DAS.FACTORY.createDAS(getConfig("staticCustomer.xml"), 
getConnection());
+Command readCustomers = das.createCommand("select * from CUSTOMER 
where ID = 1");   
 
+try {
+readCustomers.executeQuery();
+
+fail("Exception should be thrown");
+} catch (RuntimeException ex) {
+assertEquals("SDO Types have not been registered for URI 
http:///org.apache.tuscany.das.rdb.test/customer.xsd";, ex.getMessage());
+}
+}
+
 public void testMissingMapping() throws Exception {
SDOUtil.registerStaticTypes(CustomerFactory.class);
DAS das = DAS.FACTORY.createDAS(getConfig("staticCustomer.xml"), 
getConnection());
Index: 
src/test/java/org/apache/tuscany/das/rdb/test/commands/ReadCustomersStaticTypesCommand.java
===
--- 
src/test/java/org/apache/tuscany/das/rdb/test/commands/ReadCustomersStaticTypesCommand.java
 (revision 422736)
+++ 
src/test/java/org/apache/tuscany/das/rdb/test/commands/ReadCustomersStaticTypesCommand.java
 (working copy)
@@ -48,7 +48,7 @@
t.setTypeName("Customer");
mapping.getTable().add(t);

-   
mapping.setDataObjectModel("org.apache.tuscany.das.rdb.test.customer.Customer");
+   
mapping.setDataObjectModel("http:///org.apache.tuscany.das.rdb.test/customer.xsd";);
}

public ReadCustomersStaticTypesCommand() {
Index: src/test/resources/staticCustomer.xml
===
--- src/test/resources/staticCustomer.xml   (revision 422736)
+++ src/test/resources/staticCustomer.xml   (working copy)
@@ -16,7 +16,7 @@
  -->
 http:///org.apache.tuscany.das.rdb/config.xsd"; 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
-dataObjectModel="org.apache.tuscany.das.rdb.test.customer.Customer">
+dataObjectModel="http:///org.apache.tuscany.das.rdb.test/customer.xsd";>
   

 
Index: src/test/resources/companyMappingWithConverters.xml
===
--- src/test/resources/companyMappingWithConverters.xml (revision 422736)
+++ src/test/resources/companyMappingWithConverters.xml (working copy)
@@ -15,7 +15,8 @@
   limitations under the License.
  -->
 http:///org.apache.tuscany.das.rdb/config.xsd"; 
-xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
dataObjectModel="org.apache.tuscany.das.rdb.test.company.CompanyType">
+xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
+dataObjectModel="org.apache.tuscany.das.rdb.test/company.xsd">
   
   
 
Index: src/test/resources/staticCustomerOrder.xml
===
--- src/test/resources/staticCustomerOrder.xml  (revision 422736)
+++ src/test/resources/staticCustomerOrder.xml  (working copy)
@@ -16,7 +16,7 @@
  -->
 http:///org.apache.tuscany.das.rdb/config.xsd"; 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
-dataObjectModel="org.apache.tuscany.das.rdb.test.customer.Customer">
+dataObjectModel="http:///org.apache.tuscany.das.rdb.test/customer.xsd";>
 
   

Index: src/test/resources/basicStaticCustomer.xml
===
--- src/test/resources/basicStaticCustomer.xml  (revision 422736)
+++ src/test/resources/basicStaticCustomer.xml  (working copy)
@@ -16,7 +16,7 @@
  -->
 http:///org.apache.tuscany.das.rdb/config.xsd"; 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
-dataObjectModel="org.apache.tuscany.das.rdb.test.customer.Customer">
+dataObjectModel="http:///org.apache.tuscany.das.rdb.test/customer.xsd";>
   
  

Index: 
src/main/java/org/apache/tuscany/das/rdb/graphbuilder/schema/ESchemaMaker.java
===
--- 
src/main/java/org/apache/tuscany/das/rdb/graphbuilder/schema/ESchemaMaker.java  
(revision 422736)
+++ 
src/main/java/org/apache/tuscany/das/rdb/graphbuilder/schema/ESchemaMaker.java  
(working copy)
@@ -183,10 +183,12 @@
return "http:///org.apache.tuscany.das.rdb/das";;
}
 
-   public Type createTypes(Type aType) {
+   public Type createTypes(String uri) {
Type rootType = SDOUtil.createType(typeHelper, getURI() + 
"/Dat

Re: Tuscany weekly IRC chat log (July-06-2006)

[Simon Laws]

That of course should read July-17-06

On 7/17/06, Simon Laws <[EMAIL PROTECTED]> wrote:


Here is the discussion from today's IRC chat (sorry about the slightly
wonky format as I had to cut and paste from my client). The topics of
discussion were content updates to the Tuscany web site and the process by
which the web site is produced. In summary we are going to progress the
following this week.

jboyneslayout and nav,
slaws   "what is SCA",
kgoodson "what is SDO"
kevinDAS
cr22rc   help with the web site production toolkit and site
content as time allows
   dwheelerimage stuff

Of course everyone is invited to help out here so don't be shy.

Simon



shall we pick up where we were on improving the website with
a clickable picture before OSCon?
what other topics?
-->|kevin (n= [EMAIL PROTECTED]) has joined
#tuscany
i'm just back on line form leave and saw mail about the
website, e.g. the nice clickable picture, but i'm confused about what the
status is and who is doing what - can you give a quick update
The OSCON is coming, I guess we need to improve the web
site as we agreed last time, right?
-->|simonnash (n= [EMAIL PROTECTED] ) has joined #tuscany
hi
hi simon - kelivin is just kicking off a discussion on
website progress
hi, sorry, I'm back as well
hi simon, it's a little quiet, but we are just about to
take stock of where the website improvemnt is/is going -- there don't seem
tyo be any other topics at the moment -- jeremy has had to disappear
we have a clckable on the wiki, yes?
i liked raymonds picture, with the clickable links,
there was aanother picture on the mailing list i think that I cant locate at
the moment which was a higher level modular diagram
hes, clickable  
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca.htm


the other one is for tuscany architectural layers, I guess
yes - high level - was attached as a zip to a mail
can somebody upload it to WIKI as well?
yes, am i right in thinking that the one you, rfeng,
have done would be linked to from the higher level one?
high level one was on a mail from Venkata Krishnan
the one I prototyped is for SCA composite PM
-->|jmarino (n= [EMAIL PROTECTED] ) has joined #tuscany
can;t find it in the dev archive for some reason
have found it, i will attach to wiki
ok - great
I checked the toolkit from the incubator site into my
sandbox - has anyone had a chance to look at it?
sorry jeremy - have been out - is this the toolkit for
building the website?
wiki seems not to want to create a new page, waiting
..
slaws: yes, the toolkit I mentioned last time which has
been picked up by a couple of projects (including the incubator)
just point to the new URL you want to place the new page,
then you'll see the option to create the new page
jboynes: ok - ta - haven't tried it yet but can give it a
whirl
ok
anyone else interested or does anyone have any
alternatives?
yes i'm intersted but i don't really know what it buys
us
it's simpler than mvn
so, coming back to my first question, who is doing what on
the website?
I set up the toolkit thing and was waiting for feedback
just a command to run for mvn
?
xdocs are a pain ... does it get us away from that ?
I'm stuck in something else this week
you can use xml or html
ok - and rfeng made the clickable diagram and we also have
a top level diagram contributed - anything else?
I believe I was going to try and come up with a prettier
diagram(s) for the clickable diagram interface.
I need to look at the other TK too see what it buys us
based on the ones we have
finally i have the architecture diag n the wiki ...
 http://wiki.apache.org/ws/Tuscany/ClickableImages?action=show

to do the site now it's mvn site ... and then mvn
site-deploy (which publishes it )
I think the big difference is that there's less going on
than with mvn site
everything is in one place and not spread around
different modules
most of the site is just under site
the one thing we don't get with mvn I think is tabs on the
top... don't think you can do that.
with the toolkit you get raw html so can do anything
but you need to do everything ..
just to summarize, we were looking for the tabs of
http://geronimo.apache.org/ with the image navigation style of
http://incubator.apache.org/servicemix/
perhaps it would be worth extending the strawman to
include tabs etc (at least the high level nav)
I *assume* for OSCON we are going with M1 ?
i t

Re: Website work

[Jeremy Boynes]

lresende also offered to help with das

On Jul 17, 2006, at 10:01 AM, Jeremy Boynes wrote:

On IRC this morning we chatted about the changes to the site to  
address some of the comments we had at ApacheConEU.


Last week I checked the toolkit from the incubator site into  
sandbox/jboynes/site as a possibly simpler alternative to using  
maven to generate the site. A few people offered to help flesh this  
out with content:

* jboynes on layout and nav
* slaws on "what is SCA"
* kgoodson on "what is SDO"
* kevin on DAS
* cr22rc on toolkit stuff
* dwheeler on images

We could really use some help with non-Java content. I know the C++  
people are busy with getting a release out but if you could take a  
couple minutes to see what we're doing it would be appreciated.


Given the different people looking at this, I will move the  
directory out to sandbox/site


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

Fwd: Finally posted: src file header and copyright policy

[Jeremy Boynes]

Heads up of an upcoming policy change that means we will need to  
update the license boilerplate in our code.

--
Jeremy

Begin forwarded message:


From: "Cliff Schmidt" <[EMAIL PROTECTED]>
Date: July 16, 2006 11:39:37 PM PDT
To: legal-discuss@apache.org
Subject: Finally posted: src file header and copyright policy

Hey legal-discuss folks,

I've finally posted the "Source Header and Copyright Notice Policy":
http://www.apache.org/legal/src-headers.html.

It's pretty much the same thing I sent to this list a few weeks ago,
plus a FAQ that summarizes the follow-on discussion we had.

As I've mentioned before, my plan is to finish up the other two pieces
and send an email to committers@ with links to all three legal pages.
There's a good possibility I'll have these other two done in the next
couple days, but I thought I'd put this out for legal-discuss review
since it is ready now.

Let me know if you see anything in there that doesn't make sense.

Cliff

-
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See  for
official ASF policies and documents.
-
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] Tuscany-543 DAS: Consider using a URI to identify Static SDO Types in config model

[Brent Daniel]

A couple of updates for this.. Required changes to bigbank were not
included in the original patch. Also, a new test added in the patch
needed to be updated because existing registered static types could
cause it to fail.

These two patches replace the patch file I sent earlier.

Brent

On 7/17/06, Brent Daniel <[EMAIL PROTECTED]> wrote:

Attached is a patch to switch our runtime and existing static type
tests over to using an SDO type URI in the config rather than the name
of a single Type.

Brent



Index: src/test/java/org/apache/tuscany/das/rdb/test/ExceptionTests.java
===
--- src/test/java/org/apache/tuscany/das/rdb/test/ExceptionTests.java   
(revision 422736)
+++ src/test/java/org/apache/tuscany/das/rdb/test/ExceptionTests.java   
(working copy)
@@ -61,7 +61,19 @@
 
 }
 
+public void testUnregisteredTypes() throws Exception {
+   DAS das = DAS.FACTORY.createDAS(getConfig("staticInvalid.xml"), 
getConnection());
+Command readCustomers = das.createCommand("select * from CUSTOMER 
where ID = 1");   
 
+try {
+readCustomers.executeQuery();
+
+fail("Exception should be thrown");
+} catch (RuntimeException ex) {
+assertEquals("SDO Types have not been registered for URI 
invalidURI", ex.getMessage());
+}
+}
+
 public void testMissingMapping() throws Exception {
SDOUtil.registerStaticTypes(CustomerFactory.class);
DAS das = DAS.FACTORY.createDAS(getConfig("staticCustomer.xml"), 
getConnection());
Index: 
src/test/java/org/apache/tuscany/das/rdb/test/commands/ReadCustomersStaticTypesCommand.java
===
--- 
src/test/java/org/apache/tuscany/das/rdb/test/commands/ReadCustomersStaticTypesCommand.java
 (revision 422736)
+++ 
src/test/java/org/apache/tuscany/das/rdb/test/commands/ReadCustomersStaticTypesCommand.java
 (working copy)
@@ -48,7 +48,7 @@
t.setTypeName("Customer");
mapping.getTable().add(t);

-   
mapping.setDataObjectModel("org.apache.tuscany.das.rdb.test.customer.Customer");
+   
mapping.setDataObjectModel("http:///org.apache.tuscany.das.rdb.test/customer.xsd";);
}

public ReadCustomersStaticTypesCommand() {
Index: src/test/resources/staticInvalid.xml
===
--- /dev/null   (revision 0)
+++ src/test/resources/staticInvalid.xml(revision 0)
@@ -0,0 +1,22 @@
+
+
+http:///org.apache.tuscany.das.rdb/config.xsd"; 
+xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
+dataObjectModel="invalidURI">
+  
+   
+
Index: src/test/resources/staticCustomer.xml
===
--- src/test/resources/staticCustomer.xml   (revision 422736)
+++ src/test/resources/staticCustomer.xml   (working copy)
@@ -16,7 +16,7 @@
  -->
 http:///org.apache.tuscany.das.rdb/config.xsd"; 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
-dataObjectModel="org.apache.tuscany.das.rdb.test.customer.Customer">
+dataObjectModel="http:///org.apache.tuscany.das.rdb.test/customer.xsd";>
   

 
Index: src/test/resources/companyMappingWithConverters.xml
===
--- src/test/resources/companyMappingWithConverters.xml (revision 422736)
+++ src/test/resources/companyMappingWithConverters.xml (working copy)
@@ -15,7 +15,8 @@
   limitations under the License.
  -->
 http:///org.apache.tuscany.das.rdb/config.xsd"; 
-xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
dataObjectModel="org.apache.tuscany.das.rdb.test.company.CompanyType">
+xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
+dataObjectModel="org.apache.tuscany.das.rdb.test/company.xsd">
   
   
 
Index: src/test/resources/staticCustomerOrder.xml
===
--- src/test/resources/staticCustomerOrder.xml  (revision 422736)
+++ src/test/resources/staticCustomerOrder.xml  (working copy)
@@ -16,7 +16,7 @@
  -->
 http:///org.apache.tuscany.das.rdb/config.xsd"; 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
-dataObjectModel="org.apache.tuscany.das.rdb.test.customer.Customer">
+dataObjectModel="http:///org.apache.tuscany.das.rdb.test/customer.xsd";>
 
   

Index: src/test/resources/basicStaticCustomer.xml
===
--- src/test/resources/basicStaticCustomer.xml  (revision 422736)
+++ src/test/resources/basicStaticCustomer.xml  (working copy)
@@ -16,7 +16,7 @@
  -->
 http:///org.apache.tuscany.das.rdb/config.xsd"; 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
-dataObjectModel="org.apache.tuscany.das.rdb.test.customer.Customer">
+dataObjectModel="http:///org.apache.tuscany.das.r

Re: System service for creating XMLStreamReader

[Yang ZHONG]

If the intention was to spare some XMLInputFactory instances,
the XMLInputFactory implementation may need to be thread-safe.
I haven't read the spec, however the JavaDoc doesn't guarantee that.

On the other hand, option  2 promotes SPI while API is available, people
sometimes do that for performance reasons.

From my understanding, that doesn't seem the case here. SPI has some cons

over API, such as extra dependencies.
I think we need really good reasons not to use API.

--

Yang ZHONG

Re: Subject: [VOTE] [ RESULT] promote Chianti revolution to main trunk

[Rick]

Hello,
Seems like 72 hours have passed, and also I think I've seen most of the 
commiters respond to the mailing list.  I feel this should bring this 
vote to a close.

Results are:


+1 votes: 7
 Rick Rineholt 
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05011.html
 Jim Marino 
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05016.html
 Kevin Williams 
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05019.html
 Jeremy Boynes 
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05021.html
 ant elder http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05028.html
 Kenneth Tam 
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05030.html
 Pete Robbins 
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05053.html

-0.9 votes 1
 Jean-Sebastien Delfino  
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05044.html

Based on these results, I'd say the vote has passed and Chianti is clear to be 
moved to the main Tuscany SVN trunk.
The current HEAD (java) should be moved to a branch.


Rick wrote:

   Hello fellow committers,
   Last week I was on vacation and felt for sure that when I got back
   I'd see a unified direction for the Java Tuscany SCA code base. I've
   held back discussing any of this for a while because I didn't want
   to add any more fuel to the fire.  I now feel I have to speak up: to
   be honest about this,  I was really disheartened that it has came to
   pass that we as a community so soon moved to having to fall back on 
   "The Rules for Revolutionaries".  While this seems to be acceptable

   path for a Apache project, I don't feel that makes right for
   Tuscany.  I think there is a fundamental difference in the stages of
   projects that followed that route and the stage that Tuscany
   currently is at and survived as a project..  Many of these projects
   were fairly mature, they had a much larger pool of core developers
   to draw on both sides, they had a much larger user base, and for the
   most part they were based on mature specifications.  I agree that in
   some stages in the life time of a project a revolution is
   desperately needed to bring about innovation.  I don't think this is
   the case for Tuscany,  I honestly don't think Tuscany is at the
   stage where it can quite honestly survive such a split and still
   gain traction in gaining commiters and users.

   I'd really like to request that we as a community once again focus
   not as much on the technology which both branches have merit, but
   consider the Tuscany project as a whole will be better served if we
   make a decision on which will be the future today.  Thus I'm
   requesting as has been asked before if we can't take a vote on one
   and once again move forward together as one.

   Specifcly:

   I would like to propose that we make the chanti tree the main trunk
   and turn the current trunk into a maintainance branch. The chianti
   code would be moved to tuscany/java and would be the main
   development tree moving forward; the existing trunk would be moved
   to branches/M1. Please vote if you agree with this proposal - as a
   policy vote, at least 3 +1s and more +1's than -1's would be needed
   to do this

   This is my +1 for this.

   Thanks
   Rick


-
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: RuntimeInfo, was: Loading extensions in chianti

[Kenneth Tam]

Jeremy, can you elaborate a bit on
SystemCompositeComponent.registerJavaObject()? The call to register
the RuntimeInfo in Launcher is the only non-test call I can find, and
the doc suggests that it's sort of a shorthand for what the builder
code might do.

While I'm asking about the Launcher:  Can someone elaborate on the
semantics of the spi.Lifecycle and the behaviour implemented by
AbstractLifecycle, esp wrt deployment?  For example, what would be the
the differences between the order of start() statements currently in
Launcher.bootRuntime():

// create runtime
runtime.start();
// deploy "composite" into runtime
composite.start();

and:

// create runtime
// deploy "composite" into runtime
runtime.start(); // shouldn't this also start the composite deployed into it?

thanks,
k


On 7/14/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

On Jul 13, 2006, at 9:36 AM, Jeremy Boynes wrote:

> I was thinking of how to load extensions into a chianti runtime and
> had the following ideas:
>
> The first idea was to have a directory into which people could
> place composites (as jar files or whatever the packaging unit is)
> which is scanned by a system service included with the boot
> runtime. All the composites found there are used to create
> components that are added in to the system composite.

I started working on this and ran into an issue locating the
extension directory. The basic issue is, how does the runtime know
where it is installed?

One technique I've used before is to have a component in the system
that can provide this type of information. This means that other
components can go to one place rather than try and figure it out for
themselves.

I added a RuntimeInfo SPI into the extension stuff to do this. For
now it just returns the install directory (the parent to the boot
directory) but we can add other runtime stuff as needed.

--
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: WorkManager in JavaComponentBuilder

[Ignacio Silva-Lepe]

Hmm, yes I agree in abstracting out to WorkScheduler. But I still don't seem 
to have all the pieces of the puzzle. I assume I still need to autowire (now 
a WorkScheduler) to JavaComponentBuilder? And that I still need to modify 
system.scdl (now with an instance of WorkScheduler, e.g., 
Jsr237WorkScheduler). I still don't get it to work.
- Original Message - 
From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]>

To: 
Sent: Monday, July 17, 2006 11:48 AM
Subject: RE: WorkManager in JavaComponentBuilder


Ignacio,

I think, the JavaComponentBuilder should be using an implementation of
the org.apache.tuscany.spi.services.work.WorkScheduler interface, rather
than the commonj WorkManager directly. This will allow us to switch to a
JCA, commonj or any other implementation that is available based on the
host in which tuscany runs.

For example a possible dependency hierarchy would be
JavaComponentBuilder -> Jsr237WorkScheduler -> ThreadPoolWorkManager
(This is using a commonj work scheduler using our own thread pool based
commonj work manager implementation. If the host system uses Geronimo
JCA work manager, this could be JavaComponentBuilder -> JcaWorkScheduler
-> GeronimoWorkManager. The gist is for the work scheduler to abstract
the work management implementation mechanism.

hth
Meeraj

-Original Message-
From: Ignacio Silva-Lepe [mailto:[EMAIL PROTECTED]
Sent: 17 July 2006 16:37
To: Tuscany Dev
Subject: Re: WorkManager in JavaComponentBuilder

I'm a bit confused by this. I added:








to system.scdl as per Jim's directions, did a mvn clean and mvn of sca
and nothing seems to be happening (I even do a mvn clean and mvn of the
top to no avail). Not sure whether or where I should be adding the code
below by Meeraj. Here's where I autowire into JavaComponentBuilder:

   @Autowire
   public void setWorkManager(WorkManager workManager) {
   this.workManager = workManager;
   }

Any ideas?
Thanks
- Original Message -
From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, July 15, 2006 4:45 PM
Subject: RE: WorkManager in JavaComponentBuilder


The injection sequence should be something like,

WorkManager workManager = new ThreadPoolWorkManager(10);
WorkScheduler workScheuler = new Jsr237WorkScheduler(workManager);
AsyncTargetInvoker invoker = new  AsyncTargetInvoker(workScheuler); //
Sorry I don't know the signature for the constructor

As Jim rightly mentioned you need the commonj classes.

Ta
Meeraj

-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:42
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder

Jim/Ignacio,

There is abstract called WorkScheduler in the SPI, that hides whether
you are using a JCA or commonj work manager. The two implementations are
JcaWorkScheduler and Jsr237WorkScheduler. The Jsr237WorkScheduler can be
injected with a ThreadPoolWorkManager. This way, depending on the host
environment we can inject a work manager provided by the environment.

Ta
Meeraj

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:38
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder

Forgot to mention (you may already know this):

You can use Meeraj's work manager, ThreadPoolWorkManager, as the system
service.

Jim


On Jul 15, 2006, at 1:34 PM, Jim Marino wrote:


Ignacio,

Can you check the package name of WorkManager? It should be
commonj.work.WorkManager as opposed to
javax.resource.spi.work.WorkManager? Using comonj on my machine
compiles and runs.

Once you get past that, you'll need to have the work manager system
service deployed as part of the runtime.  Could you add this to the
system.scdl in the launcher project under ../main/resource/META-INF/
tuscany? Once you have changed JavaComponentBuilder to add the
autowire, the WorkManager should be picked up.

If you could submit the changes as a patch, I'll add them to the repo.

Thanks,
Jim




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

[jira] Closed: (TUSCANY-543) Consider using a URI to identify Static SDO Types in config model

[Kevin Williams (JIRA)]

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

Kevin Williams closed TUSCANY-543.
--

Resolution: Fixed
  Assignee: Brent Daniel

Verified with revision: 422799

> Consider using a URI to identify Static SDO Types in config model
> -
>
> Key: TUSCANY-543
> URL: http://issues.apache.org/jira/browse/TUSCANY-543
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
>Affects Versions: Java-Mx
>Reporter: Kevin Williams
> Assigned To: Brent Daniel
> Fix For: Java-Mx
>
>
> We currently specify static SDO Types to be used in processing a ResultSet by 
> name.  It might be better to replace this with the URI of the Types 
> registered with SDO.

-- 
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: RuntimeInfo, was: Loading extensions in chianti

[Jeremy Boynes]

On Jul 17, 2006, at 11:04 AM, Kenneth Tam wrote:


Jeremy, can you elaborate a bit on
SystemCompositeComponent.registerJavaObject()? The call to register
the RuntimeInfo in Launcher is the only non-test call I can find, and
the doc suggests that it's sort of a shorthand for what the builder
code might do.



Normally, the builder creates and registers a Component into the  
component tree. When the Component is started or stopped then the  
implementation is activated (e.g. some Java Object may be created).  
However, there are some (but few) occasions where you may already  
have an Object that you want to make available as a service. This API  
lets you wrap such an Object in an Component an add it in.


It's really designed for the bootstrap phase were the bootstrapper  
may have created some Objects to boot the runtime and it now wants to  
make them available. That's what I'm doing here to get the  
RuntimeInfo into the runtime before the builders have been created  
(so that they can use it if necessary).



While I'm asking about the Launcher:  Can someone elaborate on the
semantics of the spi.Lifecycle and the behaviour implemented by
AbstractLifecycle, esp wrt deployment?  For example, what would be the
the differences between the order of start() statements currently in
Launcher.bootRuntime():

// create runtime
runtime.start();
// deploy "composite" into runtime
composite.start();

and:

// create runtime
// deploy "composite" into runtime
runtime.start(); // shouldn't this also start the composite  
deployed into it?


Yes, the two should be equivalent. They may not be due to problems  
with how the DefaultRuntime is implemented but that would be a bug.


IIRC if you register a composite as a child of another running  
composite then the child is immediately started. I think this is a  
problem - you should be able to register a child and leave it  
unstarted (starting it later with a call to start()).


--
Jeremy


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

[C++] Should the deploy directory be under version control

[Jean-Sebastien Delfino]

I'm adjusting the svn:ignore properties in the C++ source tree and just 
noticed that the cpp/sdo/deploy and cpp/sca/deploy directories are under 
version control. These directories are created by the build, do we still 
need them to be under version control?


--
Jean-Sebastien


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

[jira] Assigned: (TUSCANY-552) CompanyWeb sample problem

[Brent Daniel (JIRA)]

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

Brent Daniel reassigned TUSCANY-552:


Assignee: Brent Daniel

> CompanyWeb sample problem
> -
>
> Key: TUSCANY-552
> URL: http://issues.apache.org/jira/browse/TUSCANY-552
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Reporter: Brent Daniel
> Assigned To: Brent Daniel
>
> The companyWeb sample is not working. It looks like its config file was not 
> updated in response to DAS changes. 

-- 
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-552) CompanyWeb sample problem

[Brent Daniel (JIRA)]

CompanyWeb sample problem
-

 Key: TUSCANY-552
 URL: http://issues.apache.org/jira/browse/TUSCANY-552
 Project: Tuscany
  Issue Type: Bug
  Components: Java DAS RDB
Reporter: Brent Daniel


The companyWeb sample is not working. It looks like its config file was not 
updated in response to DAS changes. 

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

[PATCH] Tuscany-552 DAS CompanyWeb sample problem

[Brent Daniel]

Patch for Tuscany-552.

Brent
Index: src/main/resources/CompanyConfig.xml
===
--- src/main/resources/CompanyConfig.xml(revision 421921)
+++ src/main/resources/CompanyConfig.xml(working copy)
@@ -14,9 +14,10 @@
   See the License for the specific language governing permissions and
   limitations under the License.
  -->
-http:///org.apache.tuscany.das.rdb/config.xsd"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
-dataSource="java:comp/env/jdbc/dastest">
+http:///org.apache.tuscany.das.rdb/config.xsd"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
 
+
+
 
 
 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-503) XSD substitution support in SDO2

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-503.


Resolution: Fixed

Patch committed in revision 422835.

> XSD substitution support in SDO2
> 
>
> Key: TUSCANY-503
> URL: http://issues.apache.org/jira/browse/TUSCANY-503
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
> Environment: Java
>Reporter: Yang ZHONG
>Priority: Minor
> Attachments: patch&test.zip
>
>
> Copied from eMail thread "Question about XSD substitution support in SDO2" 
> (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg03963.html):
> Raymond Feng
> Tue, 13 Jun 2006 16:43:09 -0700

-- 
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: Fwd: Finally posted: src file header and copyright policy

[Mike Edwards]

Jeremy,

Glad to see that the policy page covers code like the stuff associated 
with the SCA & SDO specs:


-

Treatment of Third-Party Works

   0. The term "third-party work" refers to a work not submitted 
directly to the ASF by the copyright owner or owner's agent.

   1.
   2. Do not modify or remove any copyright notices or licenses within 
third-party works.
   3. Do ensure that every third-party work includes its associated 
license, even if that requires adding a copy of the license from the 
third-party download site into the distribution.
   4. Do not add the standard Apache License header to the top of 
third-party source files.
   5. Minor modifications/additions to third-party source files should 
typically be licensed under the same terms as the rest of the rest of 
the third-party source for convenience.
  Major modifications/additions to third-party should be dealt with 
on a case-by-case basis by the PMC.


-

Makes it clear that you can include such code - and that you leave alone 
the existing headers and license.



Yours,  Mike.


Jeremy Boynes wrote:
Heads up of an upcoming policy change that means we will need to  update 
the license boilerplate in our code.

--
Jeremy

Begin forwarded message:


From: "Cliff Schmidt" <[EMAIL PROTECTED]>
Date: July 16, 2006 11:39:37 PM PDT
To: legal-discuss@apache.org
Subject: Finally posted: src file header and copyright policy

Hey legal-discuss folks,

I've finally posted the "Source Header and Copyright Notice Policy":
http://www.apache.org/legal/src-headers.html.

It's pretty much the same thing I sent to this list a few weeks ago,
plus a FAQ that summarizes the follow-on discussion we had.

As I've mentioned before, my plan is to finish up the other two pieces
and send an email to committers@ with links to all three legal pages.
There's a good possibility I'll have these other two done in the next
couple days, but I thought I'd put this out for legal-discuss review
since it is ready now.

Let me know if you see anything in there that doesn't make sense.

Cliff

-
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See  for
official ASF policies and documents.
-
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: [C++] Should the deploy directory be under version control

[Pete Robbins]

I think they were added as we had problems with the windows build so I'd
leave them there for now. We can re-check after we get the release done.

Cheers,


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


I'm adjusting the svn:ignore properties in the C++ source tree and just
noticed that the cpp/sdo/deploy and cpp/sca/deploy directories are under
version control. These directories are created by the build, do we still
need them to be under version control?

--
Jean-Sebastien


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





--
Pete

Re: [C++] Visual C++ Express Edition compiling SDO

[Pete Robbins]

I've applied this patch. It works fine in VC6.

Cheers,


On 17/07/06, Rick <[EMAIL PROTECTED]> wrote:


Tried compiling the Tuscany SDO CPP with MS Visual C++ 2005 Express
Edition  http://msdn.microsoft.com/vstudio/express/visualC/default.aspx
which you can download for free, but need to eventually register for (no
charge though).
I got it to compile/link have not tested it yet.  Here are the changes I
needed to do. I also don't know if they present an issue with the 6/7 MS
developer or Linux compiler

Index: sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp

===

--- sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp(revision 422669)

+++ sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp(working copy)

@@ -537,9 +537,9 @@


if (propertyName == 0 || strlen(propertyName) == 0) return 0;

-char*tokenend= strchr(propertyName,'/');
-char *bracket= strchr(propertyName,'[');
-char*dot= strchr(propertyName,'.');
+char*tokenend= (char*) strchr(propertyName,'/');
+char *bracket=  (char*) strchr(propertyName,'[');
+char*dot=  (char*) strchr(propertyName,'.');
char*   copy;


Index: sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp

===

--- sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp(revision
422669)

+++ sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp(working copy)

@@ -1871,7 +1871,7 @@

if (!strcmp(tl[i].getURI(),"commonj.sdo")) continue;

const char *uri = tl[i].getURI();
-char *c = strchr(uri,'.');
+char *c = (char*)strchr(uri,'.');

if (c == 0)
{
@@ -1922,7 +1922,7 @@


const char *uri = tl[i].getURI();
const char *name = tl[i].getName();
-char* the_uri = strchr(uri,'.');
+char* the_uri = (char*) strchr(uri,'.');

if (the_uri == 0)
{
@@ -1993,7 +1993,7 @@


if (!strcmp(tl[i].getURI(),"commonj.sdo")) continue;
const char *uri = tl[i].getURI();
-char *c = strchr(uri,'.');
+char *c = (char*) strchr(uri,'.');

if (c == 0)
{
Index: sdo/runtime/core/src/commonj/sdo/DataObjectImpl.cpp

===

--- sdo/runtime/core/src/commonj/sdo/DataObjectImpl.cpp(revision
422669)

+++ sdo/runtime/core/src/commonj/sdo/DataObjectImpl.cpp(working copy)

@@ -1313,7 +1313,7 @@

DataObjectImpl* cont = d->getContainerImpl();
if (cont != 0)
{
-pc = strrchr(path,'/');
+pc = (char*) strrchr(path,'/');
if (pc != 0)pc++;
}
const Property& pcont = cont->getProperty(pc);
@@ -2108,7 +2108,7 @@

}

DataObjectImpl* d;
-char*  i = strchr(path,'/');
+char*  i = (char*) strchr(path,'/');
char* remaining = 0;
char* token = 0;




Index: sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp
===
--- sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp   (revision 422669)
+++ sdo/runtime/core/src/commonj/sdo/TypeImpl.cpp   (working copy)
@@ -537,9 +537,9 @@

if (propertyName == 0 || strlen(propertyName) == 0) return 0;

-char*tokenend= strchr(propertyName,'/');
-char *bracket= strchr(propertyName,'[');
-char*dot= strchr(propertyName,'.');
+char*tokenend= (char*) strchr(propertyName,'/');
+char *bracket=  (char*) strchr(propertyName,'[');
+char*dot=  (char*) strchr(propertyName,'.');
char*   copy;


Index: sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp
===
--- sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp(revision
422669)
+++ sdo/runtime/core/src/commonj/sdo/DataFactoryImpl.cpp(working
copy)
@@ -1871,7 +1871,7 @@
if (!strcmp(tl[i].getURI(),"commonj.sdo")) continue;

const char *uri = tl[i].getURI();
-char *c = strchr(uri,'.');
+char *c = (char*)strchr(uri,'.');

if (c == 0)
{
@@ -1922,7 +1922,7 @@

const char *uri = tl[i].getURI();
const char *name = tl[i].getName();
-char* the_uri = strchr(uri,'.');
+char* the_uri = (char*) strchr(uri,'.');

if (the_uri == 0)
{
@@ -1993,7 +1993,7 @@

if (!strcmp(tl[i].getURI(),"commonj.sdo")) continue;
const char *uri = tl[i].getURI();
-char *c = strchr(

[C++] Copying over of samples Gettingstarted.html

[Rick]

The windows cpp build doesn't seem to be doing this... note 
GettingStarted.html in the root is there... the samples one is not there.


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

Re: [C++] Copying over of samples Gettingstarted.html

[Pete Robbins]

Just checked. Looks like it is misisng from SCA samples bin distro. Looks ok
in the src distro?

Cheers,


On 17/07/06, Rick <[EMAIL PROTECTED]> wrote:


The windows cpp build doesn't seem to be doing this... note
GettingStarted.html in the root is there... the samples one is not there.

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





--
Pete

Re: [C++] Copying over of samples Gettingstarted.html

[Pete Robbins]

... and the linux src and bin distros for sdo and sca I'm on the case!

On 17/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


 Just checked. Looks like it is misisng from SCA samples bin distro. Looks
ok in the src distro?

Cheers,


 On 17/07/06, Rick <[EMAIL PROTECTED]> wrote:
>
> The windows cpp build doesn't seem to be doing this... note
> GettingStarted.html in the root is there... the samples one is not
> there.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--

Pete





--
Pete

[VOTE] Release Tuscany C++ Milestone 1 (candidate #3)

[Pete Robbins]

I have posted a 3rd candidate for the first C++ release here:
http://people.apache.org/~robbinspg/RC-3


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 at least the next 72 hours.
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 C++
Milestone 1 release. For your reference the Incubator release policy
guidelines are available at
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases .



Release Summary
=

Tuscany SCA C++ provides a runtime implementation for the Service Component
Architecture 0.9 specification, written in C++ and will currently support
C++
component implementation types. This is not yet a complete implementation
and
known restrictions are described below.

Supported SCA Assembly Model features
 *  All features are supported unless listed under the known restrictions
below. See SCA Assembly Model specification.

Supported language bindings
 * Component implementations written in C++. See SCA Client and
   Implementation Model specification.
 * Component interfaces described by C++ classes. See SCA Client and
   Implementation Model specification.

Supported external service and entry point bindings
 * The web service binding is supported. This implementation will support
   web services which using document literal SOAP bindings conforming to
the
   WS-I basic profile (rpc/encoded is not yet supported).

Known restrictions
 * Subsystem: wiring, entry points and external services are not supported.
 * Local service interfaces cannot use overloaded operations (the SCA
   specification limits remote service interfaces to not using
overloaded operations).
 * Each WSDL definition for a web service binding must be in a single WSDL
document.
 * No load time validation of the deployed SCA application (run time
validation only).
 * No metadata API.

A sample is included which demonstrates deploying an SCA module, component
wiring, locating and invoking C++ service from C++ component,  invoking from
a C++ client, and exposing a service as a web service using ws binding.


Cheers,



--
Pete

WorkScheduler autowired to ComponentBuilderExtension

[Jim Marino]

I've added the WorkScheduler as a system service and have it  
autowired to ComponentBuilderExtension. Extensions may now access the  
scheduler through the protected field workScheduler.


Next up is to apply Meeraj's patch to the scheduler...

Jim

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

Moving chianti to trunk

[Jeremy Boynes]

With the vote in favour of switching, I am about to start moving  
chianti into trunk. I will move the current sca parts into a branch  
(branches/pre-chianti) and move the chianti code into trunk. I will  
make the version in the poms 1.0-SNAPSHOT like the SDO tree.


I expect to complete this tomorrow or possibly Wed if there are build  
issues. If anyone has a bunch of uncommitted changes or a big patch  
for submission please speak up soon to avoid merge issues.


Thanks
--
Jeremy

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

Re: [C++] Visual C++ Express Edition compiling SDO

[Jean-Sebastien Delfino]

Pete Robbins wrote:

I've applied this patch. It works fine in VC6.

Cheers,


[snip]


On 17/07/06, Rick <[EMAIL PROTECTED]> wrote:


Tried compiling the Tuscany SDO CPP with MS Visual C++ 2005 Express
Edition  http://msdn.microsoft.com/vstudio/express/visualC/default.aspx
which you can download for free, but need to eventually register for (no
charge though).
I got it to compile/link have not tested it yet.  Here are the changes I
needed to do. I also don't know if they present an issue with the 6/7 MS
developer or Linux compiler






It works fine on Linux as well.

--
Jean-Sebastien


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

Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk

[Jeremy Boynes]

On Jul 17, 2006, at 10:01 PM, Raymond Feng wrote:


Hi, Jeremy.

I have a big patch for the databinding as attached. It includes  
code improvements, more transformers and test cases. Please review  
and apply.


I applied this but it is a big large to review easily - can you break  
down what is going on in there?


I did have a problem with MediatorTestCase failing but rather than  
hold off I commented out the tests. Please can you have a look at  
those and get them working again.


Thanks
Jeremy


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

Re: WorkManager in JavaComponentBuilder

[Jim Marino]

I've applied the patch in 422953. Thanks Meeraj!

Jim


On Jul 17, 2006, at 2:25 AM, Meeraj Kunnumpurath wrote:


Jim,

Could you pls have a look and apply the attached patch.

Ta
Meeraj



-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 22:50
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder

Jim,

I think it's ok, if I understand it right.

I think the Tuscany runtime components should only know about the
WorkScheduler abstraction. We will configure a Jsr237 or JCA work
scheduler based on the host environment and configure it with an
appropriate work manager provided by the host environment. If no work
managers are available, by default we will use the Jsr237WorkScheduler
configured with the ThreadPoolWorkManager.

BTW, If you are working on this tonight (or today for you), could you
pls remove the synchronized keyword from the ThreadPoolWorkManager
callback methods. The underlying collection I use for keeping track of
the listeners is thread-safe.

Ta
Meeraj

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:56
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder

Thanks Meeraj,

I forgot about the abstraction conversation about a week back...So I'm
just thinking about how to get this into a system service. What do you
think of this:

1. Add @Autowire to the Jsr237WorkScheduler constructor as in

@Constructor("workManager")
  public Jsr237WorkScheduler(@Autowire WorkManager  
jsr237WorkManager) {

//...
  }

2. Configure ThreadPoolWorkManager as a system service.

The runtime will autowire them together.

3. Have JavaComponentBuilder (or better, ComponentBuilderExtension)  
have

an autowire to WorkScheduler


For Step 1, we need to add the @Constructor tag for now - I need to  
make

a few changes to the annotation processing to allow just specifying
@Autowire on the param.

Jim



On Jul 15, 2006, at 1:41 PM, Meeraj Kunnumpurath wrote:


Jim/Ignacio,

There is abstract called WorkScheduler in the SPI, that hides whether
you are using a JCA or commonj work manager. The two implementations
are JcaWorkScheduler and Jsr237WorkScheduler. The Jsr237WorkScheduler
can be injected with a ThreadPoolWorkManager. This way, depending on
the host environment we can inject a work manager provided by the
environment.

Ta
Meeraj

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:38
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder

Forgot to mention (you may already know this):

You can use Meeraj's work manager, ThreadPoolWorkManager, as the
system service.

Jim


On Jul 15, 2006, at 1:34 PM, Jim Marino wrote:


Ignacio,

Can you check the package name of WorkManager? It should be
commonj.work.WorkManager as opposed to
javax.resource.spi.work.WorkManager? Using comonj on my machine
compiles and runs.

Once you get past that, you'll need to have the work manager system
service deployed as part of the runtime.  Could you add this to the
system.scdl in the launcher project under ../main/resource/META-INF/
tuscany? Once you have changed JavaComponentBuilder to add the
autowire, the WorkManager should be picked up.

If you could submit the changes as a patch, I'll add them to the
repo.

Thanks,
Jim



On Jul 15, 2006, at 12:43 PM, Ignacio Silva-Lepe wrote:


All I do is to run mvn from chianti/sca, after adding the autowire
to



JavaComponentBuilder
- Original Message - From: "Jim Marino"
<[EMAIL PROTECTED]>
To: 
Sent: Saturday, July 15, 2006 2:59 PM
Subject: Re: WorkManager in JavaComponentBuilder




On Jul 15, 2006, at 11:45 AM, Ignacio Silva-Lepe wrote:


To allow JavaAtomicComponent to create a new
AsyncJavaTargetInvoker, it needs to supply the new target invoker
with a work manager. My first try (which may not be the
appropriate



thing to do) was to get a work manager autowired into
JavaComponentBuilder, which then passes it to  
JavaAtomicComponent.

That is how I would do it.

However when I do this I get a NoClassDefFoundError when the  
build


tries to run the samples (local.wire, local.wire.cdi,  
calculator).



I could add the dependency to each sample's pom.xml, which seems
to



eliminate the  error sample by sample. Or I could add the
dependency to the entire  samples directory's pom.xml, which at
the



moment has no  dependencies. Or I could just be doing the wrong
thing and I should  supply the work manager in some other way.
Thoughts?


The work manager dependency shouldn't be surfaced to the samples
since it is an implementation detail of the runtime.  How are you
executing the samples? I'm wondering if the appropriate jars are
not



being put on the classpath?

Jim



-- 
-



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





-

Re: Moving chianti to trunk

[Venkata Krishnan]

Hi Jeremy,




On 7/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


With the vote in favour of switching, I am about to start moving
chianti into trunk. I will move the current sca parts into a branch
(branches/pre-chianti) and move the chianti code into trunk. I will
make the version in the poms 1.0-SNAPSHOT like the SDO tree.

I expect to complete this tomorrow or possibly Wed if there are build
issues. If anyone has a bunch of uncommitted changes or a big patch
for submission please speak up soon to avoid merge issues.

Thanks
--
Jeremy

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

Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk

[Raymond Feng]

Hi,

I can run the all the test cases successfully using "mvn clean install". Can 
you post me the stacktrace?


The patch includes the following:

1) Refactor the transformer interfaces to have PullTransformer, 
PushTransformer and DataPipe extend from Transformer

2) Add cache to shortest path to the graph
3) Add annotations for databinding
4) Add more transformer implementations
5) Improve Mediator interface and implementation (spinned off from 
TransformerRegistryImpl) (To be integrated as a system service).

6) Add more test casses

Thanks,
Raymond

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

To: 
Sent: Monday, July 17, 2006 10:49 PM
Subject: Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk




On Jul 17, 2006, at 10:01 PM, Raymond Feng wrote:


Hi, Jeremy.

I have a big patch for the databinding as attached. It includes  code 
improvements, more transformers and test cases. Please review  and apply.


I applied this but it is a big large to review easily - can you break 
down what is going on in there?


I did have a problem with MediatorTestCase failing but rather than  hold 
off I commented out the tests. Please can you have a look at  those and 
get them working again.


Thanks
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: Moving chianti to trunk

[Venkata Krishnan]

Hi Jeremy, I have two patches one in SDO-Impl and another in SCA-Tools
(Java2WSDL tooling) that need to be reviewed  and applied to M1+.  The Jiras
are Tuscany-535 and Tuscany-120 respectively.   But then they are to applied
over M1+.  Also,  what is the plan for sca-tools in Chianti?

Thanks

Venkat

On 7/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


With the vote in favour of switching, I am about to start moving
chianti into trunk. I will move the current sca parts into a branch
(branches/pre-chianti) and move the chianti code into trunk. I will
make the version in the poms 1.0-SNAPSHOT like the SDO tree.

I expect to complete this tomorrow or possibly Wed if there are build
issues. If anyone has a bunch of uncommitted changes or a big patch
for submission please speak up soon to avoid merge issues.

Thanks
--
Jeremy

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

Re: Tuscany weekly IRC chat log (July-06-2006)

[Venkata Krishnan]

Hi, I just could not log into the IRC... not sure where the problem actually
was.

Getting to the subject of the image I posted.  I am not sure how to upload
it into the wiki.  To which page should I be attaching it... If somebody can
help me with this info I can post the image there.. Also if there is
anything that you guys want me to do with the me, please let me know.

Thanks.

- Venkat


On 7/17/06, Simon Laws <[EMAIL PROTECTED]> wrote:


That of course should read July-17-06

On 7/17/06, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> Here is the discussion from today's IRC chat (sorry about the slightly
> wonky format as I had to cut and paste from my client). The topics of
> discussion were content updates to the Tuscany web site and the process
by
> which the web site is produced. In summary we are going to progress the
> following this week.
>
> jboyneslayout and nav,
> slaws   "what is SCA",
> kgoodson "what is SDO"
> kevinDAS
> cr22rc   help with the web site production toolkit and site
> content as time allows
>dwheelerimage stuff
>
> Of course everyone is invited to help out here so don't be shy.
>
> Simon
>
>
>
> shall we pick up where we were on improving the website
with
> a clickable picture before OSCon?
> what other topics?
> -->|kevin (n= [EMAIL PROTECTED]) has
joined
> #tuscany
> i'm just back on line form leave and saw mail about the
> website, e.g. the nice clickable picture, but i'm confused about what
the
> status is and who is doing what - can you give a quick update
> The OSCON is coming, I guess we need to improve the web
> site as we agreed last time, right?
> -->|simonnash (n= [EMAIL PROTECTED] ) has joined
#tuscany
> hi
> hi simon - kelivin is just kicking off a discussion on
> website progress
> hi, sorry, I'm back as well
> hi simon, it's a little quiet, but we are just about
to
> take stock of where the website improvemnt is/is going -- there don't
seem
> tyo be any other topics at the moment -- jeremy has had to disappear
> we have a clckable on the wiki, yes?
> i liked raymonds picture, with the clickable links,
> there was aanother picture on the mailing list i think that I cant
locate at
> the moment which was a higher level modular diagram
> hes, clickable 
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca.htm
>
> <
http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29SCADiagram/attachments/sca.htm
>
> the other one is for tuscany architectural layers, I
guess
> yes - high level - was attached as a zip to a mail
> can somebody upload it to WIKI as well?
> yes, am i right in thinking that the one you, rfeng,
> have done would be linked to from the higher level one?
> high level one was on a mail from Venkata Krishnan
> the one I prototyped is for SCA composite PM
> -->|jmarino (n= [EMAIL PROTECTED] ) has joined
#tuscany
> can;t find it in the dev archive for some reason
> have found it, i will attach to wiki
> ok - great
> I checked the toolkit from the incubator site into my
> sandbox - has anyone had a chance to look at it?
> sorry jeremy - have been out - is this the toolkit for
> building the website?
> wiki seems not to want to create a new page, waiting
> ..
> slaws: yes, the toolkit I mentioned last time which has
> been picked up by a couple of projects (including the incubator)
> just point to the new URL you want to place the new page,
> then you'll see the option to create the new page
> jboynes: ok - ta - haven't tried it yet but can give it a
> whirl
> ok
> anyone else interested or does anyone have any
> alternatives?
> yes i'm intersted but i don't really know what it buys
> us
> it's simpler than mvn
> so, coming back to my first question, who is doing what
on
> the website?
> I set up the toolkit thing and was waiting for feedback
> just a command to run for mvn
> ?
> xdocs are a pain ... does it get us away from that ?
> I'm stuck in something else this week
> you can use xml or html
> ok - and rfeng made the clickable diagram and we also
have
> a top level diagram contributed - anything else?
> I believe I was going to try and come up with a
prettier
> diagram(s) for the clickable diagram interface.
> I need to look at the other TK too see what it buys us
> based on the ones we have
> finally i have the architecture diag n the wiki ...
> 
http://wiki.apache.org/ws/Tuscany/ClickableImages?action=show
>
> to do the site now it's mvn site ... and then mvn
> site-deploy (which publishes it )
> I think the big difference is that there's less going
on
> than with mvn site
> everything is in one

[jira] Resolved: (TUSCANY-532) M1 documentation improvements

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-532.
--

Fix Version/s: Cpp-current
   Resolution: Fixed

> M1 documentation improvements
> -
>
> Key: TUSCANY-532
> URL: http://issues.apache.org/jira/browse/TUSCANY-532
> Project: Tuscany
>  Issue Type: Improvement
>  Components: C++ Build
>Affects Versions: Cpp-M1
>Reporter: Andrew Borley
> Fix For: Cpp-current
>
> Attachments: TUSCANY-532-2.patch, TUSCANY-532-3.patch, 
> TUSCANY-532-4.patch, TUSCANY-532-5.patch, TUSCANY-532-6.patch, 
> TUSCANY-532.patch
>
>
> Clear up documentation by addressing the various issues raised on the mailing 
> list.

-- 
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-534) Windows binary release should not be debug version

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-534.
--

Resolution: Fixed

> Windows binary release should not be debug version
> --
>
> Key: TUSCANY-534
> URL: http://issues.apache.org/jira/browse/TUSCANY-534
> Project: Tuscany
>  Issue Type: Improvement
>  Components: C++ Build
>Affects Versions: Cpp-current
>Reporter: Pete Robbins
> Assigned To: Pete Robbins
> Fix For: Cpp-current
>
>
> Change the distribution binary build of windows to be non-debug

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