[jira] Created: (TUSCANY-2063) Errors compiling SDO and SCA while using g++ version 2.95.4

[Dmitry Utkin (JIRA)]

Errors compiling SDO and SCA while using g++ version 2.95.4
---

 Key: TUSCANY-2063
 URL: https://issues.apache.org/jira/browse/TUSCANY-2063
 Project: Tuscany
  Issue Type: Bug
  Components: C++ Build
Affects Versions: Cpp-M3, Cpp-Next
 Environment: gcc-2.95.4
glibc-2.1.3
kernel-glibc-headers-2.4.32
glibc-profile-2.1.3
glibc-devel-2.1.3

Reporter: Dmitry Utkin


In file included from 
../../../../../runtime/core/src/commonj/sdo/SAX2Parser.h:27,
 from 
../../../../../runtime/core/src/commonj/sdo/ChangeSummaryBuilder.h:28,
 from ChangeSummaryBuilder.cpp:22:
../../../../../runtime/core/src/commonj/sdo/SDOXMLString.h:68: parse error 
before `('
../../../../../runtime/core/src/commonj/sdo/SDOXMLString.h:68: syntax error 
before `('
after including :


DataFactoryImpl.cpp:2147: no match for `_IO_ostream_withassign & << 
SDORuntimeException &'
/usr/lib/gcc-lib/i486-linux/2.95.4/../../../../include/g++-3/iostream.h:77: 
candidates are: class ostream & ostream::operator <<(char)
/usr/lib/gcc-lib/i486-linux/2.95.4/../../../../include/g++-3/iostream.h:78: 
class ostream & ostream::operator <<(unsigned char)
[ skipped ]
/usr/lib/gcc-lib/i486-linux/2.95.4/../../../../include/g++-3/iostream.h:106:
 class ostream & ostream::operator <<(ostream & (*)(ostream &))
/usr/lib/gcc-lib/i486-linux/2.95.4/../../../../include/g++-3/iostream.h:107:
 class ostream & ostream::operator <<(ios & (*)(ios &))
/usr/lib/gcc-lib/i486-linux/2.95.4/../../../../include/g++-3/iostream.h:108:
 class ostream & ostream::operator <<(streambuf *)
../../../../../runtime/core/src/commonj/sdo/SDOXMLString.h:72: 
class ostream & commonj::sdo::operator <<(ostream &, const 
commonj::sdo::SDOXMLString &)
../../../../../runtime/core/src/commonj/sdo/RefCountingPointer.h:91:
 class ostream & commonj::sdo::operator <<(ostream &, const 
commonj::sdo::RefCountingPointer &)


and more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Running component service on a running port.

[Raymond Feng]

When you deploy the SCA composite with services configured with web service 
binding, please make sure tuscany-host-webapp-*.jar (but not 
tuscany-host-jetty-*.jar) is packaged in the WEB-INF/lib folder.


Thanks,
Raymond

--
From: "Sandeep Raman" <[EMAIL PROTECTED]>
Sent: Tuesday, March 04, 2008 8:21 PM
To: 
Subject: Running component service on a running port.


Hi,

I want a component service run on an already running servlet container.

I have done the following:

1) Have created two web services and exposed them on port 8080 in tomcat
2) I create then a composite of the two services and create then a service
of the composite as follows:

   
   
   
  http://localhost:8080/TwoWSService"; />
   
   

3) Now if i try to run this composite , the tuscany prepares to start its
jettyserver and there is a conflict as the port is already in use. Now i
dont want to start it on a new port.

4) The only option as per the samples is to create a webapp with an
initial page (JSP/HTML) and go to the context path after deploying. The
JSP does open , but in my case i will require the wsdl to open as soon as
i touch the URL:
http://localhost:8080/TwoWSService?wsdl

How can it be done this way. Can you guide me.

Regards
Sandeep Raman.
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you





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

Re: Classloading code in core contribution processing

[Jean-Sebastien Delfino]

Rajini Sivaram wrote:

Sebastien,

Thank you for the clarification. A few comments inline.


On 3/4/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

Rajini Sivaram wrote:

Jean-Sebastien Delfino wrote:

...
I think that the following issues have been raised in this thread:
a) contribution dependency cycles
b) partial package contributions
c) ability to use contributions without providing a ClassLoader
d) error handling (handling of ClassNotFound and related errors)
e) function layering (contribution code depending on Java support)
f) increased complexity of the classloading path
g) differences between model resolving and classloading semantics
h) reliance on specific classloader implementations

I initially raised (c) and (e) and was really struggling with (f).


(c) has already been fixed (as a response to your first note in the

thread)

- contributions do not require a classloader anymore, only
ClassReferenceModelResolver which loads classes requires a classloader.

Yes, Thanks for fixing that.


(e) has also been (almost) fixed. There is still a classloader object
associated with contributions, but it is set/get only by

contribution-java.

That's the next thing that I think we could fix, as it is odd to have
both a ModelResolver and a ClassLoader in Contribution, and Contribution
should really be independent of the support for Java artifacts.



Rajini raised (a), (b), (d), (g) (and maybe (f) too?).


I raised (a) and (b) as problems with the model resolver.

(a) is definitely an issue, demonstrated in the test case that I've
added to the contribution-multiple module, and there is a simple fix for
it. I think that we just need to detect cycles in one of the "import"
resolvers.

Unless I'm mistaken, (b) seems to work though. I'll investigate more
tomorrow.



I suspected that if contribution A and contribution B provided entries of
the package a.b.c, A and B would both import and export the package a.b.c,
resulting in a cycle. Maybe I was wrong. Anyway, I would expect a solution
for (a) to fix (b) as well.


Ah, yes, the configuration you describe requires both (a) and (b) to 
work. I suspect that (b) currently works, so as you say fixing (a) 
should solve everything.



These are

currently not issues with contribution classloading since the

contribution

classloader does not use model resolvers.

Right, but I'm hoping that after fixing (a) we can get class loading and
model resolution to converge a bit more (more on this below).


I raised (g) and I would like the semantics of import/export to be more
consistent across model resolution and class resolution. I am less keen

on

the solution involving common code.

I did raise (f) as well, but I was looking at complexity from a

different

point of view.  I think most classloading is not initiated by Tuscany,

and

classloading errors are inevitable. It doesn't matter how good

contribution

classloading is, I can always create a set of contributions with
import/export statements which result in class validation errors as a

result

of consistency failures. IMHO, adding model resolver to the classloading
path might make it easier for Tuscany developers to understand

classloading

errors, but it will make it much harder for application developers to

walk

through and debug a NoClassDefFound error, since most application

developers

will have some understanding of classloaders, but little or no

understanding

of Tuscany model resolution code.

I'd like to actually write code for this... as it's difficult to go
through code details in email, but I was thinking that a small change
could help.

I completely agree with you that having a ClassLoader delegate to a
ModelResolver delegating to a ClassLoader etc will cause confusion.

So, how about having ContributionClassLoader implement the ModelResolver
interface?



Yes, that sounds like a good idea - if it can be made to work :-).


OK, I'll do some experiments with that approach in sandbox, and then you 
and others too can look and jump in with any ideas. This is a complex 
area so the more eyes can look at code and help improve it with new 
ideas the better.



Looks like Luciano is providing an , which will allow

resources to be loaded without depending in .
Simon has helped organize the discussion with valid questions on the
actual requirements and scenarios.
Raymond proposed a classloader extensibility mechanism, which should
help with (h).

Please, anybody jump in if you disagree with this summary or think I've
missed or mis-interpreted anything :)


I still dont understand the changes that you are proposing for

contribution

classloading.

I'm proposing the following:

- Have ContributionClassLoader implement the ModelResolver interface,
allowing it and its other ClassLoader friends to be associated with
Contribution, Imports, Exports, everywhere we can store ModelResolvers
right now.

- Merge ClassReferenceModelResolver into ContributionClassLoader, as we
don't need to have a ModelResol

Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario

[Venkata Krishnan]

+1.  I will start looking into this after I am done with some half-finished
things on my plate at the moment.  Thanks.

- Venkat

On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Greg Dritschler wrote:
> > Is the authentication policy going to bear any resemblance to the policy
> > described in section 1.7.3.1 of the Policy spec, or is it completely
> > different?
> >
> > Greg
> >
>
> I think that Tuscany should implement the authorization - I guess that's
> what you meant :) - and security identity policies as described in
> section 1.7.3.1 of the Policy spec, at least.
>
> We could start with just implementing the model and XML reading for the
> elements described in 1.7.3.1 and let the various component
> implementation extensions handle them (or not) in their own way, but
> having the model and XML processors would be a good start IMO.
>
> Any thoughts?
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: mayProvide Intents in binding.ws

[Jean-Sebastien Delfino]

Venkata Krishnan wrote:

Thanks Sebastien.  Its be done already as you might see in
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/META-INF/services/definitions.xml



Great! I was just scanning through email threads and was not sure if 
this one had been closed or not :)

--
Jean-Sebastien

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

Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario

[Jean-Sebastien Delfino]

Greg Dritschler wrote:

Is the authentication policy going to bear any resemblance to the policy
described in section 1.7.3.1 of the Policy spec, or is it completely
different?

Greg



I think that Tuscany should implement the authorization - I guess that's 
what you meant :) - and security identity policies as described in 
section 1.7.3.1 of the Policy spec, at least.


We could start with just implementing the model and XML reading for the 
elements described in 1.7.3.1 and let the various component 
implementation extensions handle them (or not) in their own way, but 
having the model and XML processors would be a good start IMO.


Any thoughts?
--
Jean-Sebastien

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

Re: mayProvide Intents in binding.ws

[Venkata Krishnan]

Thanks Sebastien.  Its be done already as you might see in
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/META-INF/services/definitions.xml

On Wed, Mar 5, 2008 at 11:49 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Venkata Krishnan wrote:
> > Hi,
> >
> > I observe are some intents named 'soap', 'soap11', 'soap12'.  I'd like
> to
> > know if these are supposed to be intents classified as 'mayProvide' for
> > binding.ws.
> >
> > Just to refresh, 'mayProvide' intents are those that can be specified
> for a
> > binding / implementation and that needs no matching policySet. i.e. this
> is
> > typically a capability that the binding / implementation which could be
> > switched on with just the specification of the intent on the binding /
> > implementation.
> >
> > Given this, I don't see any policySets defined for these intents.  So,
> I'd
> > like to add these intent names to the bindingType definition for
> binding.ws.
> > Again, just to refresh, the bindingtype information is something that is
> > typically specified in the definitions.xml file and it contains a list
> of
> > intents that are inherently supported by the binding in question, either
> as
> > 'mustProvide' or 'mayProvide'.
> >
> > Can folks familiar with binding.ws please say if my understanding is on
> > track ?  Thanks.
> >
> > - Venkat
> >
>
> Just noticed this pending question now. My understanding is the same as
> yours, the Web Service binding should declare the soap, soap/1.1 and
> soap/1.2 intents using the @mayProvide attribute.
>
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Investigating assignment of endpoint information to the domain model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes

[Jean-Sebastien Delfino]

Simon Laws wrote:

Thanks Sebastien, Hopefully some insight on the puzzle in line...

Simon

On Mon, Mar 3, 2008 at 9:57 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:


I apologize in advance for the inline comment puzzle, but you had
started with a long email in the first place :)



no problem at all. Thanks for you detailed response.

snip...



I'm happy with workspace.configuration.impl. However applying default
binding configuration to bindings in a composition doesn't have much to
do with the workspace so I'd suggest to push it down to assembly,
possible if you use a signature like I suggested above.



Ok I can do that.



B) The algorithm (A) that calculates service endpoints based on node

default

binding configurations depends on knowing the protocol that a particular
binding is configured to use.

That part I don't get :) We could toy with the idea that SCA bindings
are not the right level of abstraction and that we need a transport
concept (or scheme or protocol, e.g. http) and the ability for multiple
bindings (e.g. ws, atom, json) to share the same transport... But that's
a whole different discussion IMO.

Can we keep this simply on a binding basis? and have a node declare this:


  
  
http://localhost:1234/services"/>
http://localhost:1234/services"/>
http://localhost:/services"/>


Then the  declaration can provide the default config
for all binding.ws on that node,  for all binding.json,
 for all binding.atom etc. As you can see in this example,
different bindings could use different ports... so, trying to share a
common transport will probably be less functional if it forces the
bindings sharing that transport to share a single port.



This is OK until you bring policy into the picture. A policy might affect
the scheme a binding relies on so you may more realistically end up with..


  
  
http://localhost:1234/services"/>
https://localhost:443/services"/>

http://localhost:1234/services"/>
http://localhost:/services"/>


And any particular, for example,  binding.ws might required to be defaulted
with "http://...";, "https://.."; or even not defaulted at all if it's going
to use "jms:...".  The issue with policies of course is that they are not,
currently, applied until later on when the bindings are actually activated.
So just looking at the model you can tell it has associated intents/policy
but not what the implications are for the endpoint.

We can ignore this in the first instance I guess and run with the
restriction that you can't apply policy that affects the scheme to bindings
inside the domain. But I'd be interested on you thoughts on the future
solution none the less. You will notice from the code that I haven't
actually done anything inside the bindings but just proposed that we will
have to ask binding specific questions at some point during URL creation.



Well, I think you're raising an interesting issue, but it seems to be 
independent of any of this node business, more like a general issue with 
the impact of policies on specified binding URIs.


If I understand correctly, and I'm taking the store tutorial Catalog 
component as an example to illustrate the issue:



  
http://somehost:8080/catalog"/>
  


would in fact translate to:


  
https://localhost:443/catalog"/>
  


assuming in this example that "myEncryptionIntent" is realized using 
HTTPS on port 443.


Is that the issue you're talking about?
--
Jean-Sebastien

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

Re: mayProvide Intents in binding.ws

[Jean-Sebastien Delfino]

Venkata Krishnan wrote:

Hi,

I observe are some intents named 'soap', 'soap11', 'soap12'.  I'd like to
know if these are supposed to be intents classified as 'mayProvide' for
binding.ws.

Just to refresh, 'mayProvide' intents are those that can be specified for a
binding / implementation and that needs no matching policySet. i.e. this is
typically a capability that the binding / implementation which could be
switched on with just the specification of the intent on the binding /
implementation.

Given this, I don't see any policySets defined for these intents.  So, I'd
like to add these intent names to the bindingType definition for binding.ws.
Again, just to refresh, the bindingtype information is something that is
typically specified in the definitions.xml file and it contains a list of
intents that are inherently supported by the binding in question, either as
'mustProvide' or 'mayProvide'.

Can folks familiar with binding.ws please say if my understanding is on
track ?  Thanks.

- Venkat



Just noticed this pending question now. My understanding is the same as 
yours, the Web Service binding should declare the soap, soap/1.1 and 
soap/1.2 intents using the @mayProvide attribute.


--
Jean-Sebastien

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

[continuum] BUILD ERROR: Apache Tuscany SDO Implementation Project

[Continuum VMBuild Server]

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=59876&projectId=37

Build statistics:
 State: Error
 Previous State: Ok
 Started at: Tue 4 Mar 2008 22:13:31 -0800
 Finished at: Tue 4 Mar 2008 22:13:38 -0800
 Total time: 7s
 Build Trigger: Schedule
 Build Number: 0
 Exit code: 0
 Building machine hostname: vmbuild.apache.org
 Operating system : Linux(unknown)
 Java Home version : 
 java version "1.5.0_12"

 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
 Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
   
 Builder version :

 Maven version: 2.0.7
 Java version: 1.5.0_12
 OS name: "linux" version: "2.6.20-16-server" arch: "i386"
   


SCM Changes:

No files changed


Dependencies Changes:

No dependencies changed





Build Error:

Provider message: The svn command failed.
Command output: 
---

svn: PROPFIND request failed on '/repos/asf/incubator/tuscany/java/sdo'
svn: PROPFIND of '/repos/asf/incubator/tuscany/java/sdo': could not connect to 
server (http://svn.apache.org)
---




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

[jira] Updated: (TUSCANY-1362) Incorrect operation of code that checks whether schema is loaded before going out on the net to retrieve it.

[haleh mahbod (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

haleh mahbod updated TUSCANY-1362:
--

Fix Version/s: (was: Java-SCA-Next)
   Cpp-Next

this defect belongs to CPP and was under Java-SCA-Next

> Incorrect operation of code that checks whether schema is loaded before going 
> out on the net to retrieve it. 
> -
>
> Key: TUSCANY-1362
> URL: https://issues.apache.org/jira/browse/TUSCANY-1362
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Java-SDO-M2
> Environment: All
>Reporter: Simon Laws
>Priority: Minor
> Fix For: Cpp-Next
>
>
> There is code in SDOSchemeSAX2Parse.cpp that decideds whether to go ahead and 
> parse the referenced file
> SDOSchemaSAX2Parser* ParserErrorSetter::parseIfNot(const void* 
> location, bool loadImportNamespace, const void* base)
> {
> xmlChar*const absoluteUri = xmlBuildURI((xmlChar*)location, 
> (xmlChar*)base);
> if (! absoluteUri)
> SDO_THROW_EXCEPTION("parseIfNot", SDOFileNotFoundException, 
> (char*)location);
> LocationParserMap::iterator iter = 
> parsedLocations.find(absoluteUri);
> if (parsedLocations.end() == iter)
> {
> SDOSchemaSAX2Parser*const schemaParser = new 
> SDOSchemaSAX2Parser(*new SchemaInfo(), this, loadImportNamespace);
>   try {
>   if (0 == 
> schemaParser->parse((char*)absoluteUri))
>  ***   return parsedLocations[ absoluteUri ] = 
> schemaParser;
> }
>   catch (SDORuntimeException e)
>   {}
> schemaParser->free(absoluteUri);
> return 0;
> }
> xmlFree(absoluteUri);
> return iter->second;
> }
> Note the line marked ***. This adds the current URL being parse to the 
> parsedLocations list for future reference. The issue is that, in the case 
> where no schemaLocation is provided and loadImportNamespace is true, this 
> will not work if the schema was orginally loaded from the file system, for 
> example
> /mydir/schema1.xsd  - parsedLocation = "file:///mydir/schema1.xsd
> targetNamespace="http://schemas.xmlsoap.org/wsdl/";
> /mydir/schema2.xsd 
>   http://schemas.xmlsoap.org/wsdl/"; /> - doesn't hit 
> parsedLocation as it not the same URL as was originally used to load schema1
> A solution is to store both the provided location and the target namsepace in 
> parsedLocation

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[continuum] BUILD ERROR: Apache Tuscany SDO Implementation Project

[Continuum VMBuild Server]

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=59876&projectId=37

Build statistics:
 State: Error
 Previous State: Ok
 Started at: Tue 4 Mar 2008 22:13:31 -0800
 Finished at: Tue 4 Mar 2008 22:13:38 -0800
 Total time: 7s
 Build Trigger: Schedule
 Build Number: 0
 Exit code: 0
 Building machine hostname: vmbuild.apache.org
 Operating system : Linux(unknown)
 Java Home version : 
 java version "1.5.0_12"

 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
 Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
   
 Builder version :

 Maven version: 2.0.7
 Java version: 1.5.0_12
 OS name: "linux" version: "2.6.20-16-server" arch: "i386"
   


SCM Changes:

No files changed


Dependencies Changes:

No dependencies changed





Build Error:

Provider message: The svn command failed.
Command output: 
---

svn: PROPFIND request failed on '/repos/asf/incubator/tuscany/java/sdo'
svn: PROPFIND of '/repos/asf/incubator/tuscany/java/sdo': could not connect to 
server (http://svn.apache.org)
---




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

Re: Re: Deploy a web service ,but not to target with reference

[Raymond Feng]

IMO, if the only binding configured for the service is binding.ws, then the 
service proxy returned from SCADomain.getService(...) should invoke the 
service using binding.ws. It's not very clear though if there are multiple 
bindings for the service. The selection of a binding is not well defined by 
the spec.


Thanks,
Raymond

--
From: "wang feng" <[EMAIL PROTECTED]>
Sent: Monday, March 03, 2008 11:51 PM
To: 
Subject: Re: Re: Deploy a web service ,but not to target with reference

If the component's service was deployed with web service,would the service 
invoker must through web service client?


Such as the example,  can I get the service through
HelloWorldService service = scaDomain.getService(HelloWorldService.class, 
"HelloWorldServiceJavaComponent/HelloWorldService");


If yes,is the service invoker through web service,not directly through 
binding.sca.



   class="com.primeton.demo.helloworld.HelloWorldImpl" />


interface="http://helloworldsdo#wsdl.interface(HelloWorld)" />



   

Thanks,
Wang Feng


On 2008-03-04,Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

In the 2nd case, the service is exposed using binding.ws. But the 
reference

uses the binding.sca (without an explicit binding, it's default to
binding.sca). The wiring should complain that the bindings are not
compatible.

Thanks,
Raymond

--
From: "wang feng" <[EMAIL PROTECTED]>
Sent: Monday, March 03, 2008 10:54 PM
To: "tuscany-dev" 
Subject: Deploy a web service ,but not to target with reference


Hi,all.
   I have deployed a component service with web service, and have made a
reference to it.
   I have two ways to reference,but only the first is ok,what wrong is 
the

second?

first:
http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://helloworldsdo";
   name="hellojavaws">
   
   

http://helloworldsdo#wsdl.interface(HelloWorld)" />


   


 


   
   
   http://helloworldsdo#wsdl.port(HelloWorldService/HelloWorldSoapPort)"/>
   


second:
http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://helloworldsdo";
   name="hellojavaws">
   
   

http://helloworldsdo#wsdl.interface(HelloWorld)" />


   


   
  



--
wang feng
2008-03-04


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



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




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



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

[continuum] BUILD ERROR: Apache Tuscany DAS Implementation project

[Continuum VMBuild Server]

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=59875&projectId=36

Build statistics:
 State: Error
 Previous State: Ok
 Started at: Tue 4 Mar 2008 22:11:23 -0800
 Finished at: Tue 4 Mar 2008 22:11:53 -0800
 Total time: 30s
 Build Trigger: Schedule
 Build Number: 0
 Exit code: 0
 Building machine hostname: vmbuild.apache.org
 Operating system : Linux(unknown)
 Java Home version : 
 java version "1.5.0_12"

 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
 Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
   
 Builder version :

 Maven version: 2.0.7
 Java version: 1.5.0_12
 OS name: "linux" version: "2.6.20-16-server" arch: "i386"
   


SCM Changes:

No files changed


Dependencies Changes:

No dependencies changed





Build Error:

Provider message: The svn command failed.
Command output: 
---

svn: PROPFIND request failed on '/repos/asf/incubator/tuscany/java/das'
svn: PROPFIND of '/repos/asf/incubator/tuscany/java/das': could not connect to 
server (http://svn.apache.org)
---




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

[continuum] BUILD ERROR: Apache Tuscany DAS Implementation project

[Continuum VMBuild Server]

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=59875&projectId=36

Build statistics:
 State: Error
 Previous State: Ok
 Started at: Tue 4 Mar 2008 22:11:23 -0800
 Finished at: Tue 4 Mar 2008 22:11:53 -0800
 Total time: 30s
 Build Trigger: Schedule
 Build Number: 0
 Exit code: 0
 Building machine hostname: vmbuild.apache.org
 Operating system : Linux(unknown)
 Java Home version : 
 java version "1.5.0_12"

 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
 Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
   
 Builder version :

 Maven version: 2.0.7
 Java version: 1.5.0_12
 OS name: "linux" version: "2.6.20-16-server" arch: "i386"
   


SCM Changes:

No files changed


Dependencies Changes:

No dependencies changed





Build Error:

Provider message: The svn command failed.
Command output: 
---

svn: PROPFIND request failed on '/repos/asf/incubator/tuscany/java/das'
svn: PROPFIND of '/repos/asf/incubator/tuscany/java/das': could not connect to 
server (http://svn.apache.org)
---




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

Re: Asia Open Source Symposium Code Fest is looking for help, was Fwd: Low hanging bugs for students

[haleh mahbod]

this is only a 2 day event. Can you identify a project that can be done in
such a short time? That would be great.

On 3/4/08, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> My 2c.  More than bugs it would be interesting for the students if we
> could
> suggest some minor enhancements to our tools or extensions.
>
> - Venkat
>
> 2008/3/5 haleh mahbod <[EMAIL PROTECTED]>:
>
>
> > It looks like they are looking for short, 1-2 day, projects to expose
> > students to how to provide patches in open source.
> >
> > How about suggesting a few of sample bugs for this exercise? This will
> > expose the students to Tuscany and show them how to run samples.  This
> > will
> > also give them a chance to  fix smaller scoped problems and gain the
> > experience that is looked for.
> >
> >
> > On 3/3/08, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > >
> > > This is a good opportunity for increasing awareness for Apache
> > > Tuscany. We could identify some JIRAs and/or very small projects (e.g
> > > enhancements to specific extensions) that we could send to J Aaron
> > > Farr to be used with the Chinese students.
> > >
> > > Thoughts ? Any suggestions ?
> > >
> > >
> > > -- Forwarded message --
> > > From: J Aaron Farr <[EMAIL PROTECTED]>
> > > Date: Mon, Mar 3, 2008 at 1:27 AM
> > > Subject: Low hanging bugs for students
> > > To: Apache Community <[EMAIL PROTECTED]>
> > >
> > >
> > >
> > > This next weekend I'm going to be at the Asia Open Source Symposium
> > > Code Fest.  What was going to be a hackathon-like event is now a
> > > student focused event with something like 50 university students
> > > attending for two days to learn something about open source.  So now
> > > I'm trying to come up with ideas on what to have these students do.
> > >
> > > My preference is to have the students work on a bunch of patches over
> > > two days rather than work on a single application to be released at
> > > the end of the event.  To me, the patch process is a fairly unique
> > > open source skill, so that's what I want to emphasize.
> > >
> > > I already have some bugs, features and code in mind, most related to
> > > the ApacheCon website.  But if anyone has some ideas of other low
> > > hanging bugs or features that I could task a few students with, please
> > > let me know.  Think of it as a two-day "summer of code".
> > >
> > > If anyone has any other thoughts or suggestions, please pass them on.
> > >
> > > Thanks!
> > >
> > > --
> > > J Aaron Farr jadetower.com[US] +1 724-964-4515
> > >馮傑仁  cubiclemuses.com [HK] +852 8123-7905
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > > --
> > > Luciano Resende
> > > Apache Tuscany Committer
>
> > > http://people.apache.org/~lresende<
> http://people.apache.org/%7Elresende>
>
> > > http://lresende.blogspot.com/
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>

Re: Asia Open Source Symposium Code Fest is looking for help, was Fwd: Low hanging bugs for students

[Venkata Krishnan]

My 2c.  More than bugs it would be interesting for the students if we could
suggest some minor enhancements to our tools or extensions.

- Venkat

2008/3/5 haleh mahbod <[EMAIL PROTECTED]>:

> It looks like they are looking for short, 1-2 day, projects to expose
> students to how to provide patches in open source.
>
> How about suggesting a few of sample bugs for this exercise? This will
> expose the students to Tuscany and show them how to run samples.  This
> will
> also give them a chance to  fix smaller scoped problems and gain the
> experience that is looked for.
>
>
> On 3/3/08, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >
> > This is a good opportunity for increasing awareness for Apache
> > Tuscany. We could identify some JIRAs and/or very small projects (e.g
> > enhancements to specific extensions) that we could send to J Aaron
> > Farr to be used with the Chinese students.
> >
> > Thoughts ? Any suggestions ?
> >
> >
> > -- Forwarded message --
> > From: J Aaron Farr <[EMAIL PROTECTED]>
> > Date: Mon, Mar 3, 2008 at 1:27 AM
> > Subject: Low hanging bugs for students
> > To: Apache Community <[EMAIL PROTECTED]>
> >
> >
> >
> > This next weekend I'm going to be at the Asia Open Source Symposium
> > Code Fest.  What was going to be a hackathon-like event is now a
> > student focused event with something like 50 university students
> > attending for two days to learn something about open source.  So now
> > I'm trying to come up with ideas on what to have these students do.
> >
> > My preference is to have the students work on a bunch of patches over
> > two days rather than work on a single application to be released at
> > the end of the event.  To me, the patch process is a fairly unique
> > open source skill, so that's what I want to emphasize.
> >
> > I already have some bugs, features and code in mind, most related to
> > the ApacheCon website.  But if anyone has some ideas of other low
> > hanging bugs or features that I could task a few students with, please
> > let me know.  Think of it as a two-day "summer of code".
> >
> > If anyone has any other thoughts or suggestions, please pass them on.
> >
> > Thanks!
> >
> > --
> > J Aaron Farr jadetower.com[US] +1 724-964-4515
> >馮傑仁 cubiclemuses.com [HK] +852 8123-7905
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende
> > http://lresende.blogspot.com/
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Running component service on a running port.

[Sandeep Raman]

Hi,

I want a component service run on an already running servlet container.

I have done the following:

1) Have created two web services and exposed them on port 8080 in tomcat
2) I create then a composite of the two services and create then a service 
of the composite as follows:
 



   http://localhost:8080/TwoWSService"; />



3) Now if i try to run this composite , the tuscany prepares to start its 
jettyserver and there is a conflict as the port is already in use. Now i 
dont want to start it on a new port.

4) The only option as per the samples is to create a webapp with an 
initial page (JSP/HTML) and go to the context path after deploying. The 
JSP does open , but in my case i will require the wsdl to open as soon as 
i touch the URL:
http://localhost:8080/TwoWSService?wsdl

How can it be done this way. Can you guide me.

Regards
Sandeep Raman.
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

Certificate Handling - Policy

[Sandeep Raman]

Hi Venkat,

I am unable to find any tuscany sample which deals with certificates for 
Policy.

I create a component service as follows:

  


  http://localhost:8085/TwoWSService"; /> 



I send a soap request with an header information pertaining to the x509 
certificate key, but it doesnt seem to be reading it. I am unable to find 
if anything is missing in the intents or the composite.


For the @requires , i have in definitions.xml as follows, is any change 
required in the below:


http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 

xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>


http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>



 http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";>
 
 
 
 




 http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never";>
 
 
 
 




 




 



 


http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>

 
 


http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>


 
http://ws.apache.org/rampart/policy";> 
apache
 apache
 
helloworld.ServerPWCBHandler
 


JKS
helloworldKeys.jks
apache



 



 


Regards
Sandeep Raman.
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

Re: What should be in Tuscany SCA Java release 1.2?

[Jean-Sebastien Delfino]

Luciano Resende wrote:

Time flies and is already March. I'd like to restart discussion on
this thread and start building a list of things we want to do for SCA
1.2 and I'd also like to volunteer for Release Manager for SCA 1.2
release.

On Thu, Feb 14, 2008 at 8:52 AM, Simon Laws <[EMAIL PROTECTED]> wrote:

Hi

 It's probably about time we started talking about what's going to be in
 Tuscany SCA Java release 1.2. From the past timeline I would expect us to be
 trying for a release mid to late March which is not very far away.

 Some of the things I'd like to see are;

 More progress on our domain level composite and generally the processing
 that has to go there
 There have been a lot of policy changes going on and it would be good to get
 them in. Also linked to the item above we should look at how policy affects
 domain level processing.
 Don't know if it's achievable but some elements of the runtime story we have
 been talking about on the mail list for a while now

 Feel free to add topics on this thread. I've also opened up the
 Java-SCA-1.2category in JIRA so start associating JIRA with it, for
 example, if

 1 - you've already marked a JIRA as fixed and its sitting at Java-SCA-Next
 2 - you are working or are going to work on the JIRA for 1.2
 3 - you would like to see the JIRA fixed for 1.2

 Of course everyone is invited to contribute and submit patches for JIRA
 whether they be for bugs or new features. Inevitably not all "wish list"
 features will get done so you improve your chances of getting you favorite
 feature in by submitting a patch for it.

 Regards

 Simon



+1 from me for Luciano as RM for 1.2!

I'll do a pass through JIRAs as suggested by Simon earlier in this 
thread and will also try to post tomorrow about the items I'd like to 
see in 1.2.


--
Jean-Sebastien

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

[jira] Resolved: (TUSCANY-2057) Namespace information not preserved by ContributionMetadataProcessor.write()

[Luciano Resende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luciano Resende resolved TUSCANY-2057.
--

Resolution: Fixed

Added testcase to check properly writting the contribution metadata document 
and fixed xmlOutputFactory to properly repair name spaces by using property : 
XMLOutputFactory.IS_REPAIRING_NAMESPACES

> Namespace information not preserved by ContributionMetadataProcessor.write()
> 
>
> Key: TUSCANY-2057
> URL: https://issues.apache.org/jira/browse/TUSCANY-2057
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-1.0.1
>Reporter: Brent Daniel
>Assignee: Luciano Resende
> Fix For: Java-SCA-Next
>
>
> Namespace information is not preserved by 
> ContributionMetadataProcessor.write(). You can reproduce this by modifying 
> ContributionMetadataDocumentProcessorTestsCase.testLoad() to add a write at 
> the end. 
> The input XML is:
>  private static final String VALID_XML =
> "" 
> + "http://www.osoa.org/xmlns/sca/1.0\"; 
> xmlns:helloworld=\"http://helloworld\";>"
> + ""
> + ""
> + "";
> The output from ContributionMetadataProcessor.write() is:
> 
> http://www.osoa.org/xmlns/sca/1.0";>
> 
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (TUSCANY-2062) WSDL2Java code generation fails on WSDL with multiple namespace imports

[Raymond Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Raymond Feng reassigned TUSCANY-2062:
-

Assignee: Raymond Feng

> WSDL2Java code generation fails on WSDL with multiple namespace imports
> ---
>
> Key: TUSCANY-2062
> URL: https://issues.apache.org/jira/browse/TUSCANY-2062
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SCA-1.0.1
> Environment: Runtime Deployment is Solaris/Websphere 6.1 however this 
> is a code generation bug
>Reporter: David Woolley
>Assignee: Raymond Feng
> Attachments: AdminServiceV2.wsdl, AuthenticationServiceV2.wsdl, 
> ServiceV2Common.xsd, TUSCANY-2062.zip
>
>
> As per summary. WSDLs and associated schemas will be attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-2062) WSDL2Java code generation fails on WSDL with multiple namespace imports

[Raymond Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Raymond Feng updated TUSCANY-2062:
--

Attachment: TUSCANY-2062.zip

This is the test project I used.

> WSDL2Java code generation fails on WSDL with multiple namespace imports
> ---
>
> Key: TUSCANY-2062
> URL: https://issues.apache.org/jira/browse/TUSCANY-2062
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SCA-1.0.1
> Environment: Runtime Deployment is Solaris/Websphere 6.1 however this 
> is a code generation bug
>Reporter: David Woolley
> Attachments: AdminServiceV2.wsdl, AuthenticationServiceV2.wsdl, 
> ServiceV2Common.xsd, TUSCANY-2062.zip
>
>
> As per summary. WSDLs and associated schemas will be attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (TUSCANY-2062) WSDL2Java code generation fails on WSDL with multiple namespace imports

[Raymond Feng (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575119#action_12575119
 ] 

Raymond Feng commented on TUSCANY-2062:
---

I managed to get the code-gen working with the trunk code as follows:

1) Create a java project such as TUSCANY-2062
2) Copy the wsdls/xsds to the src folder
3) Create a text file named as sdogen.options in the src folder and add a line 
"-javaPackage com.example.test.admin.sdo"
4) Run the following command (I tried inside eclipse with a run profile with 
the working dir configured to be the root of TUSCANY-2062 project
java org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator 
-targetDirectory src -javaPackage com.example.test.admin -generateSDO 
-sdoGenArgs src\sdogen.options src\AdminServiceV2.wsdl

I'll attach the project.

The tricky part is that if we don't use -sdoGenArgs option, the sdo java 
package will be the same as the generated Java interface and it causes 
conflicts for the faults.
But the -sdoGenArgs requires an external configuration file such as 
sdogen.options.

> WSDL2Java code generation fails on WSDL with multiple namespace imports
> ---
>
> Key: TUSCANY-2062
> URL: https://issues.apache.org/jira/browse/TUSCANY-2062
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SCA-1.0.1
> Environment: Runtime Deployment is Solaris/Websphere 6.1 however this 
> is a code generation bug
>Reporter: David Woolley
> Attachments: AdminServiceV2.wsdl, AuthenticationServiceV2.wsdl, 
> ServiceV2Common.xsd
>
>
> As per summary. WSDLs and associated schemas will be attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: What are my chances of being able to "inherit" behaviour from implementation.java?

[Rajini Sivaram]

implementation.osgi and implementation.spring reuse introspection code from
implementation.java. Both of these can avoid dependencies on
implementation.java if the introspection/injection code is refactored to
provide a proper SPI.



On 3/4/08, Matthew Peters <[EMAIL PROTECTED]> wrote:
>
> Bad form to reply to my own posting I know but I wanted to ask: can or
> should I raise this as formal requirement in some manner? It seems to me
> that I won't be the only one who wants an architected way to reuse the
> functionality from  - anything that is like a
> servlet, in being both a java class and something else at the same time,
> might want to do so.
>
> Matthew Peters
>
>
>
>
> Matthew Peters/UK/[EMAIL PROTECTED]
> 29/02/2008 17:50
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> tuscany-dev@ws.apache.org
> cc
>
> Subject
> Re: What are my chances of being able to "inherit" behaviour from
> implementation.java?
>
>
>
>
>
>
> Hi Jean-Sebastien, thanks for a fast response.
>
> What I am most interested in is the introspection and the ability to drive
>
> injection. Life cycle and invocation on the other hand are not a concernt
> because servlets have a very defined lifecycle and ideally that should all
>
> be looked after by the web container.
>
> Here is an example:
>
> The .composite file might look like this:
>
>   
>/>
>...
> 
>
>
>
>
>
>
> And with the servlet containing a setter for the reference, so looking for
>
> all the world like a java component in this respect
>@Reference
>public void setCatalogService(Catalog catalogService) {
>this.catalogService = catalogService;
>}
>private Catalog catalogService;
>
> Yet doing something special with some of the properties, presenting them
> as servlet init parameters, or example. So, I'm interested in:
>
> 1, introspection for references and properties
> 2. driving injection for references
> 3. driving injecttion for some properties
> 4. not doing injection for some other properties but doing something
> different for them
>
>
> Matthew Peters
>
>
>
>
> Jean-Sebastien Delfino <[EMAIL PROTECTED]>
> 29/02/2008 16:51
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> tuscany-dev@ws.apache.org
> cc
>
> Subject
> Re: What are my chances of being able to "inherit" behaviour from
> implementation.java?
>
>
>
>
>
>
> Matthew Peters wrote:
> > Suppose I wanted to create a new implementation that shared much of the
> > behaviour of  and then added a bit. Suppose I
> wanted
> > to make  for example, to be an implementation
> that
> > did what  does WRT understanding @Reference and
> @Property
> > and getters and setters, but did some extra - for example looked in the
> > web.xml file for the servlet and added some extra properties. How could
> I
> > architect this to take advantage of all the code that already exists
> > within the support for ?
> >
> > Matthew Peters
> >
>
> We may need to refactor some of that function to make it available to
> others as a proper SPI. Could you describe the bits you'd want to reuse
> in more details?
>
> - some of the implementation model?
>
> - introspection of a Java class and creation of the corresponding
> componentType model?
>
> - injection of properties and references?
>
> - invocation? I guess it's different here as a servlet has a fixed
> interface pattern?
>
> - anything else?
>
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>


-- 
Thank you...

Regards,

Rajini

Re: Asia Open Source Symposium Code Fest is looking for help, was Fwd: Low hanging bugs for students

[haleh mahbod]

It looks like they are looking for short, 1-2 day, projects to expose
students to how to provide patches in open source.

How about suggesting a few of sample bugs for this exercise? This will
expose the students to Tuscany and show them how to run samples.  This will
also give them a chance to  fix smaller scoped problems and gain the
experience that is looked for.


On 3/3/08, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> This is a good opportunity for increasing awareness for Apache
> Tuscany. We could identify some JIRAs and/or very small projects (e.g
> enhancements to specific extensions) that we could send to J Aaron
> Farr to be used with the Chinese students.
>
> Thoughts ? Any suggestions ?
>
>
> -- Forwarded message --
> From: J Aaron Farr <[EMAIL PROTECTED]>
> Date: Mon, Mar 3, 2008 at 1:27 AM
> Subject: Low hanging bugs for students
> To: Apache Community <[EMAIL PROTECTED]>
>
>
>
> This next weekend I'm going to be at the Asia Open Source Symposium
> Code Fest.  What was going to be a hackathon-like event is now a
> student focused event with something like 50 university students
> attending for two days to learn something about open source.  So now
> I'm trying to come up with ideas on what to have these students do.
>
> My preference is to have the students work on a bunch of patches over
> two days rather than work on a single application to be released at
> the end of the event.  To me, the patch process is a fairly unique
> open source skill, so that's what I want to emphasize.
>
> I already have some bugs, features and code in mind, most related to
> the ApacheCon website.  But if anyone has some ideas of other low
> hanging bugs or features that I could task a few students with, please
> let me know.  Think of it as a two-day "summer of code".
>
> If anyone has any other thoughts or suggestions, please pass them on.
>
> Thanks!
>
> --
> J Aaron Farr jadetower.com[US] +1 724-964-4515
>馮傑仁 cubiclemuses.com [HK] +852 8123-7905
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Is it possible to define a customizable value for an intent or policy?

[Jean-Sebastien Delfino]

ant elder wrote:

Ok thanks. The   element is also extensible so this axis2 config
could be added as extra attributes or elements there couldn't it, eg <
binding.ws timeOut="30" />? Which seems simpler if allowed so why is the
policySet approach better?



 will require you to go 
open your application jar and change the .composite provided by the 
application developer to adjust the timeout or number of connections.


Policies allow you to configure and adjust qualities of service like 
timeouts, connection pools etc. without touching the logical composition.

--
Jean-Sebastien

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

Re: Is it possible to define a customizable value for an intent or policy?

[Jean-Sebastien Delfino]

Venkata Krishnan wrote:

Hi,

I am just about going to check in what Sebastien is suggesting here.  So you
could define a PolicySet as follows : -


 
 100 
30
 
 


Where the only thing you might have to define is that structure
 and the xml processing for it.  Then you need to write your
handler for this policyset and register it in the binding module's
META-INF/services.  Thats it.



Yes that's exactly what I meant.

--
Jean-Sebastien

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

Support for external configuration of PolicySets

[Venkata Krishnan]

Hi,

Based on the suggestions made by Sebastien in
http://marc.info/?l=tuscany-dev&m=120346977514972 I have checked in some
changes under r633563 that brings in support for configuring policysets on
sca artifacts externally i.e. without have to modify the composites.  In the
itest/policy I have tested for this.   That itest looks a bit complicated
because I am verifying for policy settings based on whether the
corresponding handlers are called.

I wish I could register for various lifecycle events with the SCA Domain in
which case I'd register a listener for the post build phase and simply
verify the composite if its properly configured with the right policysets.

Thanks

- Venkat

Re: Is it possible to define a customizable value for an intent or policy?

[ant elder]

Ok thanks. The   element is also extensible so this axis2 config
could be added as extra attributes or elements there couldn't it, eg <
binding.ws timeOut="30" />? Which seems simpler if allowed so why is the
policySet approach better?

   ...ant

On Tue, Mar 4, 2008 at 5:37 PM, Venkata Krishnan <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> I am just about going to check in what Sebastien is suggesting here.  So
> you
> could define a PolicySet as follows : -
>
>  provides=""
> appliesTo="sca:binding.ws"
> tuscany:alwaysAppliesTo="sca:[EMAIL PROTECTED]'SomeName']"
> >
> 
> 100 
>30
> 
>  
>
>
> Where the only thing you might have to define is that structure
>  and the xml processing for it.  Then you need to write
> your
> handler for this policyset and register it in the binding module's
> META-INF/services.  Thats it.
>
> - Venkat
>
> On Tue, Mar 4, 2008 at 10:30 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Mar 4, 2008 at 4:34 PM, Jean-Sebastien Delfino <
> > [EMAIL PROTECTED]>
> > wrote:
> >
> > > ant elder wrote:
> > > > For a few things i've wondered about using intents to configure the
> > > > behaviour of an extension but cant see how to code it without hard
> > > coding
> > > > values. Using TUSCANY-1997 as an example is there some way of saying
> > > > something like  and have
> > that
> > > map
> > > > to a user configurable value like 10? I can see how to use an intent
> > > named
> > > > "lotsOfConnections" in a definitions.xml file but is there a way to
> > map
> > > a
> > > > value like 10 to that without just hard coding the mapping in the ws
> > > binding
> > > > code?
> > >
> > > Yes, the policy framework allows you to define in definitions.xml a
> > > policySet matching an intent, place in the policySet the desired
> > > configuration in a form understood by the binding code, then that
> > > configuration will be presented to your binding.
> > >
> > > For a scenario like "configure lots of connections on a reference with
> > > binding.ws", there is a better way than using an intent (i.e. I don't
> > > think that defining an intent for something like "lotsOfConnections"
> is
> > > the proper usage of policies):
> > > - you can just define the policySet, without an intent
> > > - add the policySet explicitly to your composition
> > > - or, better, attach it to your composition externally as discussed on
> > > tuscany-dev [1], the OASIS SCA Policy group [2] and in JIRA
> TUSCANY-1997
> > > [2].
> > >
> > > [1] http://marc.info/?l=tuscany-dev&m=120346977514972
> > > [2] http://www.osoa.org/jira/browse/POLICY-15
> > > [3]
> > >
> > >
> >
> http://issues.apache.org/jira/browse/TUSCANY-1997?focusedCommentId=12570553#action_12570553
> > > --
> > > Jean-Sebastien
> > >
> > >
> > Could you show some XML snippets for how that would look?
> >
> >   ...ant
> >
>

Re: Is it possible to define a customizable value for an intent or policy?

[Venkata Krishnan]

Hi,

I am just about going to check in what Sebastien is suggesting here.  So you
could define a PolicySet as follows : -


 
 100 
30
 
 


Where the only thing you might have to define is that structure
 and the xml processing for it.  Then you need to write your
handler for this policyset and register it in the binding module's
META-INF/services.  Thats it.

- Venkat

On Tue, Mar 4, 2008 at 10:30 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Tue, Mar 4, 2008 at 4:34 PM, Jean-Sebastien Delfino <
> [EMAIL PROTECTED]>
> wrote:
>
> > ant elder wrote:
> > > For a few things i've wondered about using intents to configure the
> > > behaviour of an extension but cant see how to code it without hard
> > coding
> > > values. Using TUSCANY-1997 as an example is there some way of saying
> > > something like  and have
> that
> > map
> > > to a user configurable value like 10? I can see how to use an intent
> > named
> > > "lotsOfConnections" in a definitions.xml file but is there a way to
> map
> > a
> > > value like 10 to that without just hard coding the mapping in the ws
> > binding
> > > code?
> >
> > Yes, the policy framework allows you to define in definitions.xml a
> > policySet matching an intent, place in the policySet the desired
> > configuration in a form understood by the binding code, then that
> > configuration will be presented to your binding.
> >
> > For a scenario like "configure lots of connections on a reference with
> > binding.ws", there is a better way than using an intent (i.e. I don't
> > think that defining an intent for something like "lotsOfConnections" is
> > the proper usage of policies):
> > - you can just define the policySet, without an intent
> > - add the policySet explicitly to your composition
> > - or, better, attach it to your composition externally as discussed on
> > tuscany-dev [1], the OASIS SCA Policy group [2] and in JIRA TUSCANY-1997
> > [2].
> >
> > [1] http://marc.info/?l=tuscany-dev&m=120346977514972
> > [2] http://www.osoa.org/jira/browse/POLICY-15
> > [3]
> >
> >
> http://issues.apache.org/jira/browse/TUSCANY-1997?focusedCommentId=12570553#action_12570553
> > --
> > Jean-Sebastien
> >
> >
> Could you show some XML snippets for how that would look?
>
>   ...ant
>

Re: What should be in Tuscany SCA Java release 1.2?

[Luciano Resende]

Time flies and is already March. I'd like to restart discussion on
this thread and start building a list of things we want to do for SCA
1.2 and I'd also like to volunteer for Release Manager for SCA 1.2
release.

On Thu, Feb 14, 2008 at 8:52 AM, Simon Laws <[EMAIL PROTECTED]> wrote:
> Hi
>
>  It's probably about time we started talking about what's going to be in
>  Tuscany SCA Java release 1.2. From the past timeline I would expect us to be
>  trying for a release mid to late March which is not very far away.
>
>  Some of the things I'd like to see are;
>
>  More progress on our domain level composite and generally the processing
>  that has to go there
>  There have been a lot of policy changes going on and it would be good to get
>  them in. Also linked to the item above we should look at how policy affects
>  domain level processing.
>  Don't know if it's achievable but some elements of the runtime story we have
>  been talking about on the mail list for a while now
>
>  Feel free to add topics on this thread. I've also opened up the
>  Java-SCA-1.2category in JIRA so start associating JIRA with it, for
>  example, if
>
>  1 - you've already marked a JIRA as fixed and its sitting at Java-SCA-Next
>  2 - you are working or are going to work on the JIRA for 1.2
>  3 - you would like to see the JIRA fixed for 1.2
>
>  Of course everyone is invited to contribute and submit patches for JIRA
>  whether they be for bugs or new features. Inevitably not all "wish list"
>  features will get done so you improve your chances of getting you favorite
>  feature in by submitting a patch for it.
>
>  Regards
>
>  Simon
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

[jira] Assigned: (TUSCANY-1718) One contribution exported it's namespace and was imported by two contribution ,gets assembly error.

[Luciano Resende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luciano Resende reassigned TUSCANY-1718:


Assignee: Luciano Resende

> One contribution exported it's namespace and was imported by two contribution 
> ,gets assembly error.
> ---
>
> Key: TUSCANY-1718
> URL: https://issues.apache.org/jira/browse/TUSCANY-1718
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-Next
> Environment: winxp,eclipse,jdk1.5.09
>Reporter: wangfeng
>Assignee: Luciano Resende
> Fix For: Java-SCA-Next
>
> Attachments: ContributionTestCase.zip
>
>
> My test case is that:
> 1.Contribution 'hello' export it's namespache 'http://hello'.
> 2.Contribution 'world_one' import the 'hello' contribution's namespache. 
> 3.Contribution 'world_two' import the 'hello' contribution's namespache too. 
> when run the testcase,get a fatal error as below:
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.IllegalStateException: Reference interface not remoteable for 
> component: HelloWorldServiceComponent_two and reference: helloServiceRef
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:739)
>   at test.ContributionTestCase.setUp(ContributionTestCase.java:82)
>   at junit.framework.TestCase.runBare(TestCase.java:128)
>   at junit.framework.TestResult$1.protect(TestResult.java:110)
>   at junit.framework.TestResult.runProtected(TestResult.java:128)
>   at junit.framework.TestResult.run(TestResult.java:113)
>   at junit.framework.TestCase.run(TestCase.java:120)
>   at junit.framework.TestSuite.runTest(TestSuite.java:228)
>   at junit.framework.TestSuite.run(TestSuite.java:223)
>   at 
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: java.lang.IllegalStateException: Reference interface not 
> remoteable for component: HelloWorldServiceComponent_two and reference: 
> helloServiceRef
>   at 
> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.isTargetRemote(RuntimeSCAReferenceBindingProvider.java:124)
>   at 
> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.(RuntimeSCAReferenceBindingProvider.java:85)
>   at 
> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingProviderFactory.createReferenceBindingProvider(RuntimeSCABindingProviderFactory.java:59)
>   at 
> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingProviderFactory.createReferenceBindingProvider(RuntimeSCABindingProviderFactory.java:1)
>   at 
> org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:189)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:179)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:135)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:735)
>   ... 14 more
> but when I remove the contribution 'world_one' or contribution 
> 'world_two',the testcase works fine.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (TUSCANY-2045) Refine processing of multiple WSDL with the same namespace to avoid aggregated artifacts

[Raymond Feng (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575052#action_12575052
 ] 

Raymond Feng commented on TUSCANY-2045:
---

I checked in a partial fix under r633545. It now resolves WSDL objects by 
service/binding/portType/message. I'm not sure if we need to do the same for 
XSDs.

> Refine processing of multiple WSDL with the same namespace to avoid 
> aggregated artifacts
> 
>
> Key: TUSCANY-2045
> URL: https://issues.apache.org/jira/browse/TUSCANY-2045
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
>Reporter: Simon Laws
>Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> Currently when multiple WSDL or XSD appear in the same namespace they are 
> aggregated together behind a facade at resolution time. The runtime is then 
> responsible for unpicking this aggregation in order to use the artifacts. We 
> should look into changing the code in order that specific artifacts are 
> targeted at resolution time rather than relying on synthetic aggregations. 
> This thought was started by the JIRA here 
> (http://issues.apache.org/jira/browse/TUSCANY-2043) and there are some 
> comments on the thread here 
> (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27968.html)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Is it possible to define a customizable value for an intent or policy?

[ant elder]

On Tue, Mar 4, 2008 at 4:34 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:

> ant elder wrote:
> > For a few things i've wondered about using intents to configure the
> > behaviour of an extension but cant see how to code it without hard
> coding
> > values. Using TUSCANY-1997 as an example is there some way of saying
> > something like  and have that
> map
> > to a user configurable value like 10? I can see how to use an intent
> named
> > "lotsOfConnections" in a definitions.xml file but is there a way to map
> a
> > value like 10 to that without just hard coding the mapping in the ws
> binding
> > code?
>
> Yes, the policy framework allows you to define in definitions.xml a
> policySet matching an intent, place in the policySet the desired
> configuration in a form understood by the binding code, then that
> configuration will be presented to your binding.
>
> For a scenario like "configure lots of connections on a reference with
> binding.ws", there is a better way than using an intent (i.e. I don't
> think that defining an intent for something like "lotsOfConnections" is
> the proper usage of policies):
> - you can just define the policySet, without an intent
> - add the policySet explicitly to your composition
> - or, better, attach it to your composition externally as discussed on
> tuscany-dev [1], the OASIS SCA Policy group [2] and in JIRA TUSCANY-1997
> [2].
>
> [1] http://marc.info/?l=tuscany-dev&m=120346977514972
> [2] http://www.osoa.org/jira/browse/POLICY-15
> [3]
>
> http://issues.apache.org/jira/browse/TUSCANY-1997?focusedCommentId=12570553#action_12570553
> --
> Jean-Sebastien
>
>
Could you show some XML snippets for how that would look?

   ...ant

[jira] Updated: (TUSCANY-2062) WSDL2Java code generation fails on WSDL with multiple namespace imports

[David Woolley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Woolley updated TUSCANY-2062:
---

Attachment: ServiceV2Common.xsd
AuthenticationServiceV2.wsdl
AdminServiceV2.wsdl

> WSDL2Java code generation fails on WSDL with multiple namespace imports
> ---
>
> Key: TUSCANY-2062
> URL: https://issues.apache.org/jira/browse/TUSCANY-2062
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SCA-1.0.1
> Environment: Runtime Deployment is Solaris/Websphere 6.1 however this 
> is a code generation bug
>Reporter: David Woolley
> Attachments: AdminServiceV2.wsdl, AuthenticationServiceV2.wsdl, 
> ServiceV2Common.xsd
>
>
> As per summary. WSDLs and associated schemas will be attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (TUSCANY-2062) WSDL2Java code generation fails on WSDL with multiple namespace imports

[David Woolley (JIRA)]

WSDL2Java code generation fails on WSDL with multiple namespace imports
---

 Key: TUSCANY-2062
 URL: https://issues.apache.org/jira/browse/TUSCANY-2062
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SCA-1.0.1
 Environment: Runtime Deployment is Solaris/Websphere 6.1 however this 
is a code generation bug
Reporter: David Woolley


As per summary. WSDLs and associated schemas will be attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [VOTE] Release SDO Java version 1.1-incubating (release candidate 2)

[Raymond Feng]

I tried the RC2 and it looks good to me.

+1.

Thanks,
Raymond

--
From: "kelvin goodson" <[EMAIL PROTECTED]>
Sent: Friday, February 29, 2008 3:30 AM
To: "tuscany-dev" 
Subject: [VOTE] Release SDO Java version 1.1-incubating (release candidate 
2)


Please review and vote to release the 1.1-incubating release of Tuscany 
SDO

for Java

The distribution files are at [1]
Maven artifacts for the release candidate are available at [2]
The tag for the release is at [3]

The rat report is at - [4], [5]

Here's my +1

Kelvin.

[1] http://people.apache.org/~amita/tuscany/1.1-RC2
[2] http://people.apache.org/~amita/tuscany/1.1-RC2/maven
[3]
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1-incubating/
[4]
http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2.txt
[5]
http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2-Exceptions.txt



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

[jira] Commented: (TUSCANY-1840) Bootstrapping a subset of Tuscany runtime to support object modeling in tools

[haleh mahbod (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575046#action_12575046
 ] 

haleh mahbod commented on TUSCANY-1840:
---

Thank you for your feedback. Can you please provide a more detailed list of 
what you mean by a subset of Tuscany runtime requires bootstrap?

 Do you have a patch that you would like to contribute?
Here is more information on how to submit patches if you are interested.
http://incubator.apache.org/tuscany/issue-tracking.html

> Bootstrapping a subset of Tuscany runtime to support object modeling in tools
> -
>
> Key: TUSCANY-1840
> URL: https://issues.apache.org/jira/browse/TUSCANY-1840
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.0
> Environment: Windows or Linux
>Reporter: Sean Zhou
>Priority: Critical
> Fix For: Java-SCA-Next
>
>
> When adopting Tuscany object models in a tooling environment, a subset of 
> Tuscany runtime requires bootstrap such as creating extension points and 
> factories. Currently there are no standard API methods or classes for Tuscany 
> bootstrapping for modeling.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [VOTE] (Restarting the vote to ...) Change Tuscany Charter to remove SDO reference

[Luciano Resende]

+1

On Mon, Mar 3, 2008 at 9:21 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> +1 from me
>
>  - Venkat
>
>  On Mon, Mar 3, 2008 at 3:09 PM, kelvin goodson <[EMAIL PROTECTED]>
>  wrote:
>
>
>
>  > As requested in [1] I am restarting this vote 
>  >
>  > Please vote to alter the wording of the existing draft Tuscany charter as
>  > discussed in
>  >
>  >
>  > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL 
> PROTECTED]
>  >
>  > to the following 
>  >
>  > 
>  > WHEREAS, the Board of Directors deems it to be in the best
>  >  interests of the Foundation and consistent with the Foundation's
>  >  purpose to establish a Projectt Management Committee charged with the
>  > creation
>  >  and maintenance of open-source software for distribution at no charge
>  >  to the public, that simplifies the development, deployment and management
>  >  of distributed applications built as compositions of service components.
>  >  These components may be implemented with a range of technologies and
>  >  connected using a variety of communication protocols. This software will
>  >  implement relevant open standards including, but not limited to, the
>  >  SCA standard defined by the OASIS OpenCSA member section, and related
>  >  technologies.
>  >
>  > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>  >  Committee (PMC), to be known as the "Apache Tuscany Project",
>  >  be and hereby is established pursuant to Bylaws of the
>  >  Foundation; and be it further
>  >
>  > RESOLVED, that the Apache Tuscany Project be and hereby is
>  >  responsible for the creation and maintenance of software
>  >  related to Apache Tuscany;
>  >  and be it further
>  >
>  > RESOLVED, that the office of "Vice President, Apache Tuscany" be
>  >  and hereby is created, the person holding such office to
>  >  serve at the direction of the Board of Directors as the chair
>  >  of the Apache Tuscany Project, and to have primary responsibility
>  >  for management of the projects within the scope of
>  >  responsibility of the Apache Tuscany Project; and be it further
>  >
>  > RESOLVED, that the persons listed immediately below be and
>  >  hereby are appointed to serve as the initial members of the
>  >  Apache Tuscany Project:
>  >
>  > Adriano Crestani
>  > Andy Grove   
>  > Andrew Borley   
>  > ant elder   
>  > Brady Johnson  
>  > Frank Budinsky 
>  > Ignacio Silva-Lepe  
>  > Jean-Sebastien Delfino   
>  > kelvin goodson   
>  > Luciano Resende   
>  > Mike Edwards   
>  > Pete Robbins
>  > Raymond Feng  
>  > Simon Laws  
>  > Simon Nash  
>  > Venkata Krishnan  
>  >
>  > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
>  >  be appointed to the office of Vice President, Apache Tuscany, to
>  >  serve in accordance with and subject to the direction of the
>  >  Board of Directors and the Bylaws of the Foundation until
>  >  death, resignation, retirement, removal or disqualification,
>  >  or until a successor is appointed; and be it further
>  >
>  > RESOLVED, that the Apache Tuscany Project be and hereby
>  >  is tasked with the migration and rationalization of the Apache
>  >  Incubator Tuscany podling; and be it further
>  >
>  > RESOLVED, that all responsibilities pertaining to the Apache
>  >  Incubator Tuscany podling encumbered upon the Apache Incubator
>  >  Project are hereafter discharged.
>  >
>  >
>  >
>  >
>  > =
>  >
>  > The wording of the existing draft charter was taken from
>  >
>  > 
> http://mail-archives.apache.org/mod_mbox/incubator-general/200710.mbox/[EMAIL 
> PROTECTED]
>  >
>  > Be sure to note when looking at that posting that it consists of a
>  > previous
>  > version + a modification at the end of the posting.
>  >
>  > The changes are ...
>  > "This software will implement relevant open standards including, but not
>  > limited to, the SCA and SDO standards defined by the OASIS OpenCSA member
>  > section."
>  > becomes ...
>  > "This software will implement relevant open standards including, but not
>  > limited to, the SCA standard defined by the OASIS OpenCSA member section,
>  > and related technologies."
>  >
>  > [1]
>  >
>  > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL 
> PROTECTED]
>  >
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

Re: Is it possible to define a customizable value for an intent or policy?

[Jean-Sebastien Delfino]

ant elder wrote:

For a few things i've wondered about using intents to configure the
behaviour of an extension but cant see how to code it without hard coding
values. Using TUSCANY-1997 as an example is there some way of saying
something like  and have that map
to a user configurable value like 10? I can see how to use an intent named
"lotsOfConnections" in a definitions.xml file but is there a way to map a
value like 10 to that without just hard coding the mapping in the ws binding
code?


Yes, the policy framework allows you to define in definitions.xml a 
policySet matching an intent, place in the policySet the desired 
configuration in a form understood by the binding code, then that 
configuration will be presented to your binding.


For a scenario like "configure lots of connections on a reference with 
binding.ws", there is a better way than using an intent (i.e. I don't 
think that defining an intent for something like "lotsOfConnections" is 
the proper usage of policies):

- you can just define the policySet, without an intent
- add the policySet explicitly to your composition
- or, better, attach it to your composition externally as discussed on 
tuscany-dev [1], the OASIS SCA Policy group [2] and in JIRA TUSCANY-1997 
[2].


[1] http://marc.info/?l=tuscany-dev&m=120346977514972
[2] http://www.osoa.org/jira/browse/POLICY-15
[3] 
http://issues.apache.org/jira/browse/TUSCANY-1997?focusedCommentId=12570553#action_12570553

--
Jean-Sebastien

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

Re: Porting Native SDO to Solaris 5.9

[Luciano Resende]

Hi Hongshi Lo

   Thanks for your interest in Native SDO. Would like to share more
about your experience migrating SDO to Solaris ? Are there lots of
changes required ? Would you be willing to contribute your changes
back to the comunity via patch ?

On Tue, Mar 4, 2008 at 8:10 AM, Honghsi Lo <[EMAIL PROTECTED]> wrote:
> Never mind, figured out the solutions.  Now it compiled.
>
>  Thanks,
>
>  honghsi
>
>
>
>  -Original Message-
>  From: Honghsi Lo [mailto:[EMAIL PROTECTED]
>  Sent: Tuesday, March 04, 2008 9:52 AM
>  To: tuscany-dev@ws.apache.org
>  Subject: Porting Native SDO to Solaris 5.9
>
>  Hi,
>
>  Anyone has experience porting native C++ SDO to Sun's Solaris 5.9?  I
>  used Sun Studio 11 (CC version 5.8) and I got problem with
>  RefCountingPtr, the actual compiling errors occurred in
>  ChangeSummaryImpl.cpp, DataObjectImpl.cpp, DataObjectListImpl.cpp, and
>  DataFactoryImpl.cpp.  I think it is a member function template related
>  problem.  I checked Sun's site and it said both Studio 11 and Studio 12
>  are based on 1998 C++ standard. But it already been 5 years since 2003.
>  Any helpful pointers or suggestions?
>
>  Thanks,
>
>  honghsi
>
>  Notice:  This email message, together with any attachments, may contain
>  information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
>  entities,  that may be confidential,  proprietary,  copyrighted  and/or
>  legally privileged, and is intended solely for the use of the individual
>  or entity named in this message. If you are not the intended recipient,
>  and have received this message in error, please immediately return this
>  by email and then delete it.
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>  Notice:  This email message, together with any attachments, may contain 
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
> entities,  that may be confidential,  proprietary,  copyrighted  and/or 
> legally privileged, and is intended solely for the use of the individual or 
> entity named in this message. If you are not the intended recipient, and have 
> received this message in error, please immediately return this by email and 
> then delete it.
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

RE: Porting Native SDO to Solaris 5.9

[Honghsi Lo]

Sure, I'll be more than happy to do that.  There are really only few
changes.  Now I need to debug SDO tests.

Regards,

honghsi

-Original Message-
From: Luciano Resende [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 04, 2008 11:20 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Porting Native SDO to Solaris 5.9

Hi Hongshi Lo

   Thanks for your interest in Native SDO. Would like to share more
about your experience migrating SDO to Solaris ? Are there lots of
changes required ? Would you be willing to contribute your changes back
to the comunity via patch ?

On Tue, Mar 4, 2008 at 8:10 AM, Honghsi Lo <[EMAIL PROTECTED]> wrote:
> Never mind, figured out the solutions.  Now it compiled.
>
>  Thanks,
>
>  honghsi
>
>
>
>  -Original Message-
>  From: Honghsi Lo [mailto:[EMAIL PROTECTED]
>  Sent: Tuesday, March 04, 2008 9:52 AM
>  To: tuscany-dev@ws.apache.org
>  Subject: Porting Native SDO to Solaris 5.9
>
>  Hi,
>
>  Anyone has experience porting native C++ SDO to Sun's Solaris 5.9?  I

> used Sun Studio 11 (CC version 5.8) and I got problem with  
> RefCountingPtr, the actual compiling errors occurred in  
> ChangeSummaryImpl.cpp, DataObjectImpl.cpp, DataObjectListImpl.cpp, and

> DataFactoryImpl.cpp.  I think it is a member function template related

> problem.  I checked Sun's site and it said both Studio 11 and Studio 
> 12  are based on 1998 C++ standard. But it already been 5 years since
2003.
>  Any helpful pointers or suggestions?
>
>  Thanks,
>
>  honghsi
>
>  Notice:  This email message, together with any attachments, may 
> contain  information  of  BEA Systems,  Inc.,  its subsidiaries  and  
> affiliated  entities,  that may be confidential,  proprietary,  
> copyrighted  and/or  legally privileged, and is intended solely for 
> the use of the individual  or entity named in this message. If you are

> not the intended recipient,  and have received this message in error, 
> please immediately return this  by email and then delete it.
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>  Notice:  This email message, together with any attachments, may
contain information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated entities,  that may be confidential,  proprietary,
copyrighted  and/or legally privileged, and is intended solely for the
use of the individual or entity named in this message. If you are not
the intended recipient, and have received this message in error, please
immediately return this by email and then delete it.
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>



--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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


Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

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

Re: [VOTE] Release SDO Java version 1.1-incubating (release candidate 2)

[Jean-Sebastien Delfino]

Amita Vadhavkar wrote:

I have tested the RC2 in details, and all seems fine, so here is my
+1

Regards,
Amita

On Tue, Mar 4, 2008 at 7:05 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:


I have done some basic testing on Linux, compiles fine from a clean
maven repo and samples are working. I have also looked at license and
notice files, seems fine.

+1

On Sun, Mar 2, 2008 at 5:16 PM, Frank Budinsky <[EMAIL PROTECTED]> wrote:

It looks good to me. +1

 Frank.

 [EMAIL PROTECTED] wrote on 02/29/2008 06:30:37 AM:



 > Please review and vote to release the 1.1-incubating release of

Tuscany

 SDO
 > for Java
 >
 > The distribution files are at [1]
 > Maven artifacts for the release candidate are available at [2]
 > The tag for the release is at [3]
 >
 > The rat report is at - [4], [5]
 >
 > Here's my +1
 >
 > Kelvin.
 >
 > [1] 
http://people.apache.org/~amita/tuscany/1.1-RC2
 > [2] 
http://people.apache.org/~amita/tuscany/1.1-RC2/maven
 > [3]
 > https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.
 > 1-incubating/
 > [4]
 >


http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2.txt

 > [5]
 > 
http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-
 > incubating-RC2-Exceptions.txt



+1 from me!

Built on Linux RHEL5, checked the license and notice files, the RAT 
report, all look good to me.


--
Jean-Sebastien

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

RE: Porting Native SDO to Solaris 5.9

[Honghsi Lo]

Never mind, figured out the solutions.  Now it compiled.  

Thanks,

honghsi 

-Original Message-
From: Honghsi Lo [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 04, 2008 9:52 AM
To: tuscany-dev@ws.apache.org
Subject: Porting Native SDO to Solaris 5.9

Hi,

Anyone has experience porting native C++ SDO to Sun's Solaris 5.9?  I
used Sun Studio 11 (CC version 5.8) and I got problem with
RefCountingPtr, the actual compiling errors occurred in
ChangeSummaryImpl.cpp, DataObjectImpl.cpp, DataObjectListImpl.cpp, and
DataFactoryImpl.cpp.  I think it is a member function template related
problem.  I checked Sun's site and it said both Studio 11 and Studio 12
are based on 1998 C++ standard. But it already been 5 years since 2003.
Any helpful pointers or suggestions?

Thanks,

honghsi

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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


Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

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

Re: What are my chances of being able to "inherit" behaviour from implementation.java?

[Matthew Peters]

Bad form to reply to my own posting I know but I wanted to ask: can or 
should I raise this as formal requirement in some manner? It seems to me 
that I won't be the only one who wants an architected way to reuse the 
functionality from  - anything that is like a 
servlet, in being both a java class and something else at the same time, 
might want to do so. 

Matthew Peters




Matthew Peters/UK/[EMAIL PROTECTED] 
29/02/2008 17:50
Please respond to
tuscany-dev@ws.apache.org


To
tuscany-dev@ws.apache.org
cc

Subject
Re: What are my chances of being able to "inherit" behaviour from 
implementation.java?






Hi Jean-Sebastien, thanks for a fast response. 

What I am most interested in is the introspection and the ability to drive 

injection. Life cycle and invocation on the other hand are not a concernt 
because servlets have a very defined lifecycle and ideally that should all 

be looked after by the web container.

Here is an example:

The .composite file might look like this:

   
   
... 







And with the servlet containing a setter for the reference, so looking for 

all the world like a java component in this respect
@Reference
public void setCatalogService(Catalog catalogService) {
this.catalogService = catalogService;
}
private Catalog catalogService;

Yet doing something special with some of the properties, presenting them 
as servlet init parameters, or example. So, I'm interested in:

1, introspection for references and properties
2. driving injection for references
3. driving injecttion for some properties
4. not doing injection for some other properties but doing something 
different for them


Matthew Peters




Jean-Sebastien Delfino <[EMAIL PROTECTED]> 
29/02/2008 16:51
Please respond to
tuscany-dev@ws.apache.org


To
tuscany-dev@ws.apache.org
cc

Subject
Re: What are my chances of being able to "inherit" behaviour from 
implementation.java?






Matthew Peters wrote:
> Suppose I wanted to create a new implementation that shared much of the 
> behaviour of  and then added a bit. Suppose I 
wanted 
> to make  for example, to be an implementation 
that 
> did what  does WRT understanding @Reference and 
@Property 
> and getters and setters, but did some extra - for example looked in the 
> web.xml file for the servlet and added some extra properties. How could 
I 
> architect this to take advantage of all the code that already exists 
> within the support for ?
> 
> Matthew Peters
> 

We may need to refactor some of that function to make it available to 
others as a proper SPI. Could you describe the bits you'd want to reuse 
in more details?

- some of the implementation model?

- introspection of a Java class and creation of the corresponding 
componentType model?

- injection of properties and references?

- invocation? I guess it's different here as a servlet has a fixed 
interface pattern?

- anything else?

-- 
Jean-Sebastien

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








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU












Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[jira] Commented: (TUSCANY-2058) The method XSDHelper.isXSD(Type) is returning invalid information

[Kelvin Goodson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575016#action_12575016
 ] 

Kelvin Goodson commented on TUSCANY-2058:
-

This makes me wonder whether the spec has been a bit loose in its wording here 
and missed an opportunity.  We keep our annotations that carry this extra 
metadata on the Type instance itself, so every xsdHelper would have access to 
the infomation.  I think it's worth opening this up as a spec issue. 

the actual contents of the Spec do not completely preclude the behaviour we are 
seeing ...

"IsXSD() can be used to tell if the XSDHelper has information about a Type." -- 
and,  for the duration of the isXSD(method), it does,  by virtue of the 
supplied argument.

It's the JavaDoc that's the main issue.  It says ...

Indicates if this helper contains XSD information for the specified type.

Which again is very loose, and probably wrong, since a set of helpers 
congregate around a scope for Types,  so an xsdHelper would have access to 
types that had been defined by itself,  and by the TypeHelper belonging to that 
scope.  Hence the fact that is has information about that type is not the 
discriminator that determines the return value.

I would suggest the behaviour we are seeing is the logical behaviour.

> The method XSDHelper.isXSD(Type) is returning invalid information
> -
>
> Key: TUSCANY-2058
> URL: https://issues.apache.org/jira/browse/TUSCANY-2058
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: Test2058.java
>
>
> Based on my understanding, XSDHelper.isXSD(Type) should return 'true' if the 
> supplied Type object has been defined in the Scope from which the XSDHelper 
> was constructed.  In turn, I expect that 'false' will be returned, for a Type 
> object NOT defined in the Scope.  In some testing I have performed, I'm 
> seeing that 'true' is always returned, even if the Type is defined outside 
> the Scope being questioned.  I will attach a sample.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Porting Native SDO to Solaris 5.9

[Honghsi Lo]

Hi,

Anyone has experience porting native C++ SDO to Sun's Solaris 5.9?  I
used Sun Studio 11 (CC version 5.8) and I got problem with
RefCountingPtr, the actual compiling errors occurred in
ChangeSummaryImpl.cpp, DataObjectImpl.cpp, DataObjectListImpl.cpp, and
DataFactoryImpl.cpp.  I think it is a member function template related
problem.  I checked Sun's site and it said both Studio 11 and Studio 12
are based on 1998 C++ standard. But it already been 5 years since 2003.
Any helpful pointers or suggestions?

Thanks,

honghsi

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

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

[jira] Commented: (TUSCANY-2031) Error encountered when trying to use dynamic Data APIs and SDO code-generated APIs at the same time

[Kelvin Goodson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575008#action_12575008
 ] 

Kelvin Goodson commented on TUSCANY-2031:
-

Hello Joseph.  I'm sorry that I didn't spot this one before.  I need to see a 
bit more of your code.   I don't have the beta1 source to hand at the moment to 
check in detail,  but the first thing that seems clear is that any occurrence 
of AnyTypeImpl indicates that the Type system for the document that is being 
read is not registered.  You'll need to have registered your type system in 
some way.  It's not clear whether you want to use the dynamic API on instances 
of DataObject,  or to use the dynamic API on instances of your generated 
classes.  Either is possible.  In the first case you will need to use the 
schema that you used for generating the static classes, and provide it as an 
InputStream to helperContext.getTypeHelper().define(...) and in the second case 
you would need to do something like 
MyGenFactory.INSTANCE.register(helperContext). This makes the Types available 
so that when you do helperContext.getXMLHelper().load(...) the load operation 
can look up the Types referenced in the XML document's elements,  and create 
instances of the appropriate classes.  I suspect this is user error.  So I am 
going to close this JIRA as such.  If you are still having troubles please mail 
the tuscany-user mailing list where we'll be able to help you out.

> Error encountered when trying to use dynamic Data APIs and SDO code-generated 
> APIs at the same time
> ---
>
> Key: TUSCANY-2031
> URL: https://issues.apache.org/jira/browse/TUSCANY-2031
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: Windows XP, JDK 1.6
>Reporter: Joseph Nguyen
> Fix For: Java-SDO-Next
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> Can use generated codes from SDO generator to create DataObject(s) and XML 
> data.  Once the data has been created, error encountered when trying to use 
> dynamic Data APIs to read in to create DataObject(s).  Below shows the 
> details of error.
> Exception in thread "main" java.lang.ClassCastException: 
> org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl
> at 
> org.apache.tuscany.sdo.helper.XMLDocumentImpl.getRootObject(XMLDocumentImpl.java:320)
> at tbd.TBD.getRootObjectFromXMLDoc(TBD.java:73)
> at tbd.TBD.main(TBD.java:497)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-2031) Error encountered when trying to use dynamic Data APIs and SDO code-generated APIs at the same time

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson resolved TUSCANY-2031.
-

Resolution: Invalid

Suspect user error as per comment above.

> Error encountered when trying to use dynamic Data APIs and SDO code-generated 
> APIs at the same time
> ---
>
> Key: TUSCANY-2031
> URL: https://issues.apache.org/jira/browse/TUSCANY-2031
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: Windows XP, JDK 1.6
>Reporter: Joseph Nguyen
> Fix For: Java-SDO-Next
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> Can use generated codes from SDO generator to create DataObject(s) and XML 
> data.  Once the data has been created, error encountered when trying to use 
> dynamic Data APIs to read in to create DataObject(s).  Below shows the 
> details of error.
> Exception in thread "main" java.lang.ClassCastException: 
> org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl
> at 
> org.apache.tuscany.sdo.helper.XMLDocumentImpl.getRootObject(XMLDocumentImpl.java:320)
> at tbd.TBD.getRootObjectFromXMLDoc(TBD.java:73)
> at tbd.TBD.main(TBD.java:497)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[Fwd: ASF Board Report - Initial Reminder for Mar 2008]

[Glen Daniels]

Teams:

It's that time again.  Our board report for March is now due.  I've 
started a template report at http://wiki.apache.org/ws/ReportForMar2008, 
which team leads should please flesh out as appropriate.  If there's 
nothing of note going on with your sub-project, no need to edit (but you 
should consider whether you need to get things moving :)).


Please take care of this ASAP if you have a minute, as it's always 
better to get it out of the way rather than having to stress about it at 
the last minute.  I'll plan to submit to the board by the 15th.


Thanks, all.

--Glen

 Original Message 
Subject: ASF Board Report - Initial Reminder for Mar 2008
Date: 4 Mar 2008 13:30:07 -
From: ASF Board <[EMAIL PROTECTED]>
To: Glen Daniels <[EMAIL PROTECTED]>



This email was sent by an automated system on behalf of the ASF Board.
It is an initial reminder to give you plenty of time to prepare the report.

The meeting is scheduled for Wed, 19 March 2008, 10 am PST and the 
deadline for

submitting your report is two full days prior to that!

According to board records, you are listed as the chair of at least one
committee that is due to submit a report this month. [1] [2]

Details on which project reports are due and how to submit a report
are enclosed below.

For the coming board report, the board and legal committee would much
appreciate your project reviewing the crypto export policy spelled out
at http://www.apache.org/dev/crypto.html to determine that the project
either either no encryption considerations, or if notices must be (or had
been) sent to the BIS and NSA, they have been documented at the official
location http://www.apache.org/licenses/exports/ for all encryption
elements within the oversite of this PMC.  Adding a status item on the
board report will help the legal committee to ensure this oversight has
been applied across the foundation.

Please submit your report with sufficient time to allow the board members
to review and digest. Again, the very latest you should submit your report
is two full days (48h) prior to the board meeting.

The exact date of the board meeting can be found in the calendar.txt file
in the board directory of the committers repository [2].

If you feel that an error has been made, please consult [1] and if there
is still an issue then contact the board directly.

Thanks,
The ASF Board

[1] - 
https://svn.apache.org/repos/private/committers/board/committee-info.txt

[2] - https://svn.apache.org/repos/private/committers/board/calendar.txt



Submitting your Report
--

Full details about the process and schedule are in [1].

Your report should be sent in plain-text format to [EMAIL PROTECTED]
with a Subject line that follows the below format:

Subject: [REPORT] Project Name

Cutting and pasting directly from a Wiki is not acceptable due to formatting
issues. Line lengths should be limited to 77 characters. The content should
also be committed to the meeting agenda in the board directory in the
foundation repository.


ASF Board Reports
-

Reports are due from you for the following committees:

 - Web Services

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

Is it possible to define a customizable value for an intent or policy?

[ant elder]

For a few things i've wondered about using intents to configure the
behaviour of an extension but cant see how to code it without hard coding
values. Using TUSCANY-1997 as an example is there some way of saying
something like  and have that map
to a user configurable value like 10? I can see how to use an intent named
"lotsOfConnections" in a definitions.xml file but is there a way to map a
value like 10 to that without just hard coding the mapping in the ws binding
code?

   ...ant

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

Hi,

To update, I have split the bigbank into bigbank and bigbank-account to show
the distribution of policies across contributions.  I just about have
trouble with the things that need to be imported / exported across these
two.  I'd prob. need Luciano's help to get over this.

The other thing I have started to do is the 'alwaysApplicablePolicySets'
that was suggested.  There weren't to many things to do for this and I am
right now trying to find a way to test this in the itest-policy.

- Venkat

On Thu, Feb 21, 2008 at 11:35 AM, Venkata Krishnan <[EMAIL PROTECTED]>
wrote:

> Hi Sebastien,
>
> Thanks for looking it up and providing opinions.  All of them sound good
> to me and I will get onto them after am done with some things am fixing with
> policy annotations and an iTest for policy.
>
> Just the one thing about the PasswordCallBackHandler.  It only meant to
> domonstrate that its a gateway to your user registries.  Agreed that this
> might be taken very literally by some users.  So, do you suggest that I
> interface with some user registry in the CallBackHandlers ?  If so can a
> simple Hashmap based user registry do or would you like some LDAP based user
> registry integration here?
>
> Thanks.
>
>
> - Venkat
>
>
> On Wed, Feb 20, 2008 at 6:38 AM, Jean-Sebastien Delfino <
> [EMAIL PROTECTED]> wrote:
>
> > Venkata Krishnan wrote:
> > > Hi Sebastien,
> > >
> > > I have made the changes to the secure-bigbank demo.  Let me know if
> > there is
> > > something that looks odd and not practical in a real world scenario.
> > > Thanks.
> > >
> >
> > I'm starting to like it :) I have a few more suggestions:
> >
> > - Merge it into the main bigbank scenario.
>
> - Place definitions.xml files in different contributions to show that
> > policies can be configured externally.
>
>
> >
> > - Remove the CallbackHandlers as hardcoding a password in a piece of
> > code in the contribution is not what I'd call practical :)
> >
> > Another suggestion to make policies easier to use: Support external
> > attachment of a PolicySet to a composite element independent of the
> > presence of intents.
> >
> > Here are some use cases:
> > - configure confidentiality at deployment time, without having to go
> > back and change the application composite to add intents or policySets.
> >
> > - configure the number of HTTP connections on a reference [1], over time
> > when traffic increases, again with no change to the composite.
> >
> > External policy attachment is starting to be discussed in the OASIS
> > policy spec workgroup [2], but I was thinking that we could start simple
> > with just an additional attribute on PolicySet for now, like this:
> >
> > 
> > 
> > /policySet>
> >
> > The policySet would be applied to the composite elements matching the
> > xpath in alwaysAppliesTo, independent of the presence or not of any
> > intents.
> >
> > Thoughts?
> >
> > [1] http://marc.info/?l=tuscany-user&m=120051348720777
> > [2] http://www.osoa.org/jira/browse/POLICY-15
> > --
> > Jean-Sebastien
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

[jira] Commented: (TUSCANY-2060) Exception using binding.ws if a method is named init()

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574901#action_12574901
 ] 

Daniel Stucky commented on TUSCANY-2060:


Well, I'm not familiar with Axis2 but I guess there are some reasons behind 
that list of excluded method names. Does anybody know what these reasons are?
At the moment it's ok for me to now that there are some method names that are 
not allowed (another exception would be nice, though).


> Exception using binding.ws if a method is named init()
> --
>
> Key: TUSCANY-2060
> URL: https://issues.apache.org/jira/browse/TUSCANY-2060
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
> Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 
> 1.5.0_10 
>Reporter: Daniel Stucky
>Assignee: Raymond Feng
> Attachments: test.zip
>
>
> I have the following Java Interface that works with binding.sca: 
> public interface Gamma 
> { 
> void init(); 
> void doSomething(); 
> void stop(); 
> } 
> When I use binding.ws (I let Tuscany create the WSDL interfaces automatically 
> I get the following exception (see below). The method is NOT marked with 
> @Init, it's just the name of the method. 
> Exception in thread "main" org.osoa.sca.ServiceRuntimeException: 
> org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
>   at launch.Launch.main(Launch.java:10)
> Caused by: org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:183)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
>   ... 2 more
> Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:756)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:181)
>   ... 3 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getOperation(WSDLOperationIntrospectorImpl.java:206)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:153)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.(Axis2ReferenceBindingProvider.java:51)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:53)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:40)
>   at 
> org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:190)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:176)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:133)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:752)
>   ... 4 more
> I also tested it with version 1.2. The Exception is the same, with slightly 
> different line numbers.
> Exception in thread "main" org.osoa.sca.ServiceRuntimeException: 
> org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
>   at launch.Launch.main(Launch.java:10)
> Caused by: org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:215)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:109)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
>   ... 2 more
> Caused by: org.apache.tuscany.sca.core.assem

[jira] Commented: (TUSCANY-2060) Exception using binding.ws if a method is named init()

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574899#action_12574899
 ] 

Daniel Stucky commented on TUSCANY-2060:


Well, I'm not familiar with Axis2 but I guess there are some reasons behind 
that list of excluded method names. Does anybody know what these reasons are?
At the moment it's ok for me to now that there are some method names that are 
not allowed (another exception would be nice, though).


> Exception using binding.ws if a method is named init()
> --
>
> Key: TUSCANY-2060
> URL: https://issues.apache.org/jira/browse/TUSCANY-2060
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
> Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 
> 1.5.0_10 
>Reporter: Daniel Stucky
>Assignee: Raymond Feng
> Attachments: test.zip
>
>
> I have the following Java Interface that works with binding.sca: 
> public interface Gamma 
> { 
> void init(); 
> void doSomething(); 
> void stop(); 
> } 
> When I use binding.ws (I let Tuscany create the WSDL interfaces automatically 
> I get the following exception (see below). The method is NOT marked with 
> @Init, it's just the name of the method. 
> Exception in thread "main" org.osoa.sca.ServiceRuntimeException: 
> org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
>   at launch.Launch.main(Launch.java:10)
> Caused by: org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:183)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
>   ... 2 more
> Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:756)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:181)
>   ... 3 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getOperation(WSDLOperationIntrospectorImpl.java:206)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:153)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.(Axis2ReferenceBindingProvider.java:51)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:53)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:40)
>   at 
> org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:190)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:176)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:133)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:752)
>   ... 4 more
> I also tested it with version 1.2. The Exception is the same, with slightly 
> different line numbers.
> Exception in thread "main" org.osoa.sca.ServiceRuntimeException: 
> org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
>   at launch.Launch.main(Launch.java:10)
> Caused by: org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:215)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:109)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
>   ... 2 more
> Caused by: org.apache.tuscany.sca.core.assem

Re: Classloading code in core contribution processing

[Rajini Sivaram]

Sebastien,

Thank you for the clarification. A few comments inline.


On 3/4/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Rajini Sivaram wrote:
> > Jean-Sebastien Delfino wrote:
> >> ...
> >> I think that the following issues have been raised in this thread:
> >> a) contribution dependency cycles
> >> b) partial package contributions
> >> c) ability to use contributions without providing a ClassLoader
> >> d) error handling (handling of ClassNotFound and related errors)
> >> e) function layering (contribution code depending on Java support)
> >> f) increased complexity of the classloading path
> >> g) differences between model resolving and classloading semantics
> >> h) reliance on specific classloader implementations
> >>
> >> I initially raised (c) and (e) and was really struggling with (f).
> >
> >
> > (c) has already been fixed (as a response to your first note in the
> thread)
> > - contributions do not require a classloader anymore, only
> > ClassReferenceModelResolver which loads classes requires a classloader.
>
> Yes, Thanks for fixing that.
>
> >
> > (e) has also been (almost) fixed. There is still a classloader object
> > associated with contributions, but it is set/get only by
> contribution-java.
>
> That's the next thing that I think we could fix, as it is odd to have
> both a ModelResolver and a ClassLoader in Contribution, and Contribution
> should really be independent of the support for Java artifacts.

>
> > Rajini raised (a), (b), (d), (g) (and maybe (f) too?).
> >
> >
> > I raised (a) and (b) as problems with the model resolver.
>
> (a) is definitely an issue, demonstrated in the test case that I've
> added to the contribution-multiple module, and there is a simple fix for
> it. I think that we just need to detect cycles in one of the "import"
> resolvers.
>
> Unless I'm mistaken, (b) seems to work though. I'll investigate more
> tomorrow.


I suspected that if contribution A and contribution B provided entries of
the package a.b.c, A and B would both import and export the package a.b.c,
resulting in a cycle. Maybe I was wrong. Anyway, I would expect a solution
for (a) to fix (b) as well.

These are
> > currently not issues with contribution classloading since the
> contribution
> > classloader does not use model resolvers.
>
> Right, but I'm hoping that after fixing (a) we can get class loading and
> model resolution to converge a bit more (more on this below).
>
> >
> > I raised (g) and I would like the semantics of import/export to be more
> > consistent across model resolution and class resolution. I am less keen
> on
> > the solution involving common code.
> >
> > I did raise (f) as well, but I was looking at complexity from a
> different
> > point of view.  I think most classloading is not initiated by Tuscany,
> and
> > classloading errors are inevitable. It doesn't matter how good
> contribution
> > classloading is, I can always create a set of contributions with
> > import/export statements which result in class validation errors as a
> result
> > of consistency failures. IMHO, adding model resolver to the classloading
> > path might make it easier for Tuscany developers to understand
> classloading
> > errors, but it will make it much harder for application developers to
> walk
> > through and debug a NoClassDefFound error, since most application
> developers
> > will have some understanding of classloaders, but little or no
> understanding
> > of Tuscany model resolution code.
>
> I'd like to actually write code for this... as it's difficult to go
> through code details in email, but I was thinking that a small change
> could help.
>
> I completely agree with you that having a ClassLoader delegate to a
> ModelResolver delegating to a ClassLoader etc will cause confusion.
>
> So, how about having ContributionClassLoader implement the ModelResolver
> interface?


Yes, that sounds like a good idea - if it can be made to work :-).

>
> > Looks like Luciano is providing an , which will allow
> >> resources to be loaded without depending in .
> >> Simon has helped organize the discussion with valid questions on the
> >> actual requirements and scenarios.
> >> Raymond proposed a classloader extensibility mechanism, which should
> >> help with (h).
> >>
> >> Please, anybody jump in if you disagree with this summary or think I've
> >> missed or mis-interpreted anything :)
> >
> >
> > I still dont understand the changes that you are proposing for
> contribution
> > classloading.
>
> I'm proposing the following:
>
> - Have ContributionClassLoader implement the ModelResolver interface,
> allowing it and its other ClassLoader friends to be associated with
> Contribution, Imports, Exports, everywhere we can store ModelResolvers
> right now.
>
> - Merge ClassReferenceModelResolver into ContributionClassLoader, as we
> don't need to have a ModelResolver delegating to a ClassLoader, and they
> can be a single object.
>
> - Remove get/setClassLoader from Contribution, making it 

Why there are two different ways for tuscany generating WSDL from java (java2wsdl)

[Alex]

Hi All,
In tuscany-sca (1.1 above) , there are two modules related with java2wsdl:
1.) modules\interface-wsdl-java2wsdl
2.) tools\java2wsdl
The java2wsdl interface(1) provides a runtime interface to handle java
object to wsdl object
the  java2wsdl tool (2) provides a command-line tool for converting java
classes into wsdl files.
the (1) use JAVA2WSDLBuilder (from Axis2 1.3 code) and AxisService2WSDL11,
AxisService2WSDL20  to generate WSDL
the (2) use TuscanyJAVA2WSDLBuilder, TuscanyWSDLTypeGenerator ... to
generate WSDL
Why there are two different ways? Why not just use axis code only or tuscany
code only for the two modules?
Or there are already a plan to merge the code? so which one will be if there
is a choice?

Thanks
- Alex

Re: [VOTE] Release SDO Java version 1.1-incubating (release candidate 2)

[ant elder]

+1, looks good to me.

Any chance our mentors could have a look and cast a vote?

   ...ant

On Fri, Feb 29, 2008 at 11:30 AM, kelvin goodson <[EMAIL PROTECTED]>
wrote:

> Please review and vote to release the 1.1-incubating release of Tuscany
> SDO
> for Java
>
> The distribution files are at [1]
> Maven artifacts for the release candidate are available at [2]
> The tag for the release is at [3]
>
> The rat report is at - [4], [5]
>
> Here's my +1
>
> Kelvin.
>
> [1] 
> http://people.apache.org/~amita/tuscany/1.1-RC2
> [2] 
> http://people.apache.org/~amita/tuscany/1.1-RC2/maven
> [3]
>
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1-incubating/
> [4]
>
> http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2.txt
> [5]
>
> http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2-Exceptions.txt
>

Re: [VOTE] Release SDO Java version 1.1-incubating (release candidate 2)

[Amita Vadhavkar]

I have tested the RC2 in details, and all seems fine, so here is my
+1

Regards,
Amita

On Tue, Mar 4, 2008 at 7:05 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> I have done some basic testing on Linux, compiles fine from a clean
> maven repo and samples are working. I have also looked at license and
> notice files, seems fine.
>
> +1
>
> On Sun, Mar 2, 2008 at 5:16 PM, Frank Budinsky <[EMAIL PROTECTED]> wrote:
> > It looks good to me. +1
> >
> >  Frank.
> >
> >  [EMAIL PROTECTED] wrote on 02/29/2008 06:30:37 AM:
> >
> >
> >
> >  > Please review and vote to release the 1.1-incubating release of
> Tuscany
> >  SDO
> >  > for Java
> >  >
> >  > The distribution files are at [1]
> >  > Maven artifacts for the release candidate are available at [2]
> >  > The tag for the release is at [3]
> >  >
> >  > The rat report is at - [4], [5]
> >  >
> >  > Here's my +1
> >  >
> >  > Kelvin.
> >  >
> >  > [1] 
> > http://people.apache.org/~amita/tuscany/1.1-RC2
> >  > [2] 
> > http://people.apache.org/~amita/tuscany/1.1-RC2/maven
> >  > [3]
> >  > https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.
> >  > 1-incubating/
> >  > [4]
> >  >
> >
> http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2.txt
> >  > [5]
> >  > 
> > http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-
> >  > incubating-RC2-Exceptions.txt
> >
> >
> >  -
> >  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>