Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Simon Laws]

Hi Venkat

A question.

snip...

>
> - In the contribution read phase, we postpone the reading of composite
> files
> so that all definitions.xml file contents can all be aggregated
>

Do you mean all the definitions.xml files in the contribution or all the
definitions.xml files in the domain?

Simon

Re: NoSuchMethodError: javax/wsdl/Operation

[Jean-Sebastien Delfino]

ant elder wrote:

Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError:
javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know
how to fix that? This is with the class loader set to "Classes loaded with
application class loader first".

   ...ant



You need "Single Class Loader" as well.

--
Jean-Sebastien

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

Re: Distribution zips and what they contain, was: SCA runtimes

[Jean-Sebastien Delfino]

Comments inline.

Simon Nash wrote:
Well, I think the smart installer approach will be a nightmare. We had 
a similar approach in M2 and people didn't like it.



The M2 approach was very different from what I was proposing.  M2
downloaded everything on demand at runtime.  A smart installer would
set things up ahead of time with the necessary features for the
desired runtime configuration.  This is much more manageable if
there are any problems with the downloads.


OK, you scared me :)

If you're talking about analyzing the features required by a composite 
at deployment time, calculating the set of JARs providing these 
features, and making them available for installation, then you get my +1.


The work I've started with the Maven Ant generator plugin is a step in 
that direction. If you hook it with a composite model analyzer and 
remove the Ant specifics you get what I just described, allowing you to 
tailor a minimal runtime for a particular SCA application.


You're right that the Eclipse feature install approach is a little 
like that. IMHO it has been a nightmare and probably one of the 
reasons why their download page [1] now shows targeted distros :)

- for Java developers
- for Java EE developers
- for Plugin developers
- for C++ developers
- for Web developers (on a separate page).
- and the classic IDE mix

Very similar to the approach I was proposing... I'm just seeing Spring 
and Eclipse, two extensible and successful projects adopt similar 
approaches, and thought they'd be good examples to follow :)



I think these are good examples to follow.  Tuscany is rather similar
in that it contains a base framework and many optional extensions, and
there is probably no user who wants to use all the optional features.



+1

But that's OK, if people don't like that split I can also live with a 
single big runtime distro.



Over time, we will add more and more optional features and this will
become more and more of a problem.  IMO, it's bad enough now that we
need to do something.


I agree with you, but there is no consensus on this.

I see several options:
a) a vote to pick a common direction now
b) have people develop their different visions to get user feedback
c) continue with the current distro scheme

Like I said I could live with (c). However, I would prefer (a) or (b).


I'd like to suggest a first baby step towards partitioning the contents
of the distro.  In this first step, there's still a single binary distro
with all the dependencies.  The difference is that the modules and lib
directories are broken down into subdirectories along the lines that
Sebastien and others have suggested.  Based on earlier discussions, the
subdirectories could be:

core - The base that everybody needs
  core assembly model and runtime
  Java APIs, Java components, SCA binding, Web Service binding

web - For Web developers
  Web 2.0 bindings, Scripting components, Widget components

JEE - For JEE app integration
  EJB, RMI and JMS bindings, Spring components

process - For process development
  BPEL and XQuery components

Each of these could be built and tested separately.  Dependencies
between them would only use documented SPIs.  There would no
longer be a single catch-all tuscany-manifest jar or a single
tuscany-all jar.  If this first step is successful, we could think
about what further steps we could take to improve modularity.



I don't see what that baby step buys us. If we think that partitioning 
is the right approach, why not just simply do it cleanly and partition 
the distro?


--
Jean-Sebastien

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

RE: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

[[EMAIL PROTECTED]]

Jean-sebastien,
Qualified = target namespace?or wsdl name?

Say my wsdl is named aaa.wsdl do I reference it by http://aaa ?  

Thx clemens
-Original Message-
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: tuscany-dev@ws.apache.org
Sent: 2/11/08 6:33 PM
Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, 
annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

Clemens Utschig - Utschig wrote:
> shouldn't an  do it, so that I could potentially store the wsdl 
> anywhere ..
> 
> I'll try that later today - thx for the advise..
> 

You don't even need an include, just place the WSDL file anywhere inside
your SCA contribution (JAR or folder), reference its qualified name from
your .composite and we should find it.

-- 
Jean-Sebastien

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





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

Re: Binding-echo-extension failing : missing abstract method getApplicablePolicySets() Fwd: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project

[Jean-Sebastien Delfino]

Venkata Krishnan wrote:

Thanks.  I will ask Sebastien then :)


I'm an administrator on project Tuscany but:
- you are not in the Tuscany continuum group
- I don't have seem to have authority to perform any user admin tasks

Can you ask one of the continuum user administrators, here's the list:
http://vmbuild.apache.org/continuum/security/userlist!show.action?roleName=User+Administrator
--
Jean-Sebastien

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

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Jean-Sebastien Delfino]

Venkata Krishnan wrote:

Hi,

Dealing with the 'appliesTo' attribute in PolicySets has been a subject that
I ended up discussing on the thread
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27768.html.  I
have gone forward with a suggestion that Sebastien sounded off on that
thread and have committed the changes under r620307.

First to set the stage
---
- The PolicySets could be defined in various definitions.xml which are all
read and aggreated for a domain
- Each PolicySet defines an 'appliesTo' attribute which is an xpath that
specifies the sca artifacts to which this policyset may apply.

The problem is about being able to validate the computed or calculated
policysets for a binding / implementation using this 'appliesTo' attribute.


Here is a summary of what's been done.
---
- In the contribution read phase, we postpone the reading of composite files
so that all definitions.xml file contents can all be aggregated
- After reading all other kinds of artifacts, we finally read the composite
files in the contribution.  The composite xml is first read as a xml
document and for each PolicySet defined for the domain we run the appliesTo
xpath against this xml document.  For the nodes returned as result of this
xpath evaluation, we add an attribute named 'applicablePolicySets' whose
value will be the name of the PolicySet in question.  So the read composite
will now be modified to include this attribute wherever applicable.
- The modified composite xml is then passed to the STaX processors for the
usual parsing and creation of the the assembly model objects.
- Then during the computing / calculation of PolicySets for a
PolicySetAttachPoint (i.e. a binding or an implementation) the matching
policysets are validated against the list that has been made in the
'applicablePolicySets' attribute of the PolicySetAttachPoint.

As a result of this our samples now don't define their own intents to target
specific policysets for specific references / services.  Instead this
targeting is achieved by the proper specification of the 'appliesTo'
attribute in the PolicySet.

Please let me know your thoughts on this.

Thanks

- Venkat



Looks good to me. I am assuming that 'applicablePolicySets' is a 
transient and calculated attribute used by Tuscany to flow policySet 
info with model elements across the composite reading phases, and not 
exposed to application developers.


Were you able to leverage these changes to simplify the bigbank scenario?
--
Jean-Sebastien

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

Re: Tuscany web-apps and jUnit dependencies

[Jean-Sebastien Delfino]

Simon Nash wrote:

ant elder wrote:

On Feb 8, 2008 8:55 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:



As for the other items, If we have TuscanyServletFilter and

TuscanyTestServletFilter, it would only work for the iTests, as they
have generated web.xml. If we want to have simmilar aproach on our
sample applications, that have real web.xml, how would we do it ?



I already said earlier on the other thread but just to reiterate I don't
think we should use this approach with the samples. They need to be as
simple and clear as possible so they're easy for new users to understand.

   ...ant


+1 for keeping the samples as simple as possible.

Is it possible to automate the running of sample tests in a way that
doesn't change the contents of the sample war files?  I'm thinking of
a test framework that starts Tomcat or Jetty, deploys a sample war,
then runs some JUnit tests.  I don't see why this would need any change
to the web.xml in the sample war.

  Simon



My 2c, with my application developer hat on:

My webapp should not have to depend on junit unless I'm packaging test 
cases that need junit.


I don't want any fancy web.xml generator as it'll wipe out the 
application servlets and welcome pages that I'll declare in web.xml.


My application's web.xml should just contain the following:

  tuscany
  
  org.apache.tuscany.sca.host.webapp.TuscanyServletFilter
  


and in that case the TuscanyServletFilter should not open execution of 
test cases under the /junit path.


To enable junit test execution, I should just have to add the following 
to my web.xml:


  tuscany-junit
  
  org.apache.tuscany.sca.whatever.TuscanyJUnitServletFilter
  


Finally, samples should show me how to do what I just described.

--
Jean-Sebastien

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

Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

[Jean-Sebastien Delfino]

Clemens Utschig - Utschig wrote:
> shouldn't an  do it, so that I could potentially store the wsdl 
> anywhere ..
> 
> I'll try that later today - thx for the advise..
> 

You don't even need an include, just place the WSDL file anywhere inside
your SCA contribution (JAR or folder), reference its qualified name from
your .composite and we should find it.

-- 
Jean-Sebastien

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

Re: Graduation next steps

[haleh mahbod]

If someone is a very active contributor, he/she is most likely watching the
commit list as well as the dev list. If someone is  just subscribed to the
dev list to watch the key discussions and occasionally gets involved, he/she
would not want to see all the JIRA updates.  This assumes that new
discussions do not get triggered in JIRAs. They come to life on the mailing
list and turn into a JIRA if they need to.


On 2/9/08, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> ant elder wrote:
> > On Feb 6, 2008 5:28 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> > 
> >
> >> One other consideration - sometimes it's appropriate to reply to a
> >>> JIRA rather than updating the issue: if there are two lists, on has to
> >>> decide - should the replies go to both or just dev?
> >>>
> >> In such a case I think the reply should just go to the dev list.  All
> >> discussions should be happening there, not on the commits list.
> >>
> >
> > That can be done by having the JIRA emails configured with a replyto set
> to
> > the dev list, thats the same as the SVN update emails which are sent to
> the
> > commit list but replies to those emails go to the dev list.
> >
> > If it works like that would people feel more comfortable going ahead
> with
> > this change moving the JIRA emails to go to the commit list or is the
> dev
> > list still the preferred place?
> >
> >...ant
> >
> I think the active committers could handle these on either list.  It
> would be useful to have input from those who are not active committers
> and therefore (presumably) not following the commits list very closely.
> I'd be happy to go with whatever these people prefer.
>
>Simon
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: NoSuchMethodError: javax/wsdl/Operation

[Scott Kurz]

There's two jars with WSDL4J relevant to the 6.1 appserver runtime:

WAS\plugins\com.ibm.ws.runtime_6.1.0.jar
WAS\plugins\org.apache.axis2_6.1.0.jar

The rest are relevant for tooling and client envs.

The first of those has some version WSDL4J 1.5 and the latter 1.6.

So you manually patched wsdl4j 1.6.2 into com.ibm.ws.runtime_6.1.0.jar?



On Feb 11, 2008 2:02 PM, ant elder <[EMAIL PROTECTED]> wrote:
> I have done all this and still see the problem. I've also search for all the
> wsdl4j jars in the WAS install and replaced the few i found with the
> 1.6.2jar and still see the problem, any other ideas? Seems odd that
> Venkat and I
> both hit this but others don't.
>
>...ant
>
>
> On Feb 11, 2008 4:47 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> > I have been using WAS installed with the "Application Server" option.
> > It needs a fix for a bug with Servlet Filters, that is available with
> > FixPack 9 (or later I guess), and this fix need to be  activated in
> > the WAS admin console, navigate to Application Servers - server1 - Web
> > Container - Customer Properties and configure a
> > com.ibm.ws.webcontainer.invokefilterscompatibility property to true.
> > Then, every time you deploy an Tuscany application, you should set the
> > proper class path options :  ¨Classes loaded with application class
> > loader first"  and "Single class loader per application". See also
> > Sebastien's post [1] with much more details on this subject.
> >
> > Please let me know if this helps.
> >
> >
> > [1]
> > http://jsdelfino.blogspot.com/2007/10/how-to-use-apache-tuscany-with.html
> >
> > On Feb 11, 2008 12:57 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > Yes.  Its the same with me as well.  I have installed WAS 6.1 ND.  Is
> > there
> > > a particular fixpack that is to take care of this ?
> > >
> > > Thanks
> > >
> > > - Venkat
> > >
> > >
> > > On Feb 11, 2008 2:22 PM, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > > Trying to run Tuscany WebApp samples in WebSphere i get a
> > > > NoSuchMethodError:
> > > > javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone
> > > > know
> > > > how to fix that? This is with the class loader set to "Classes loaded
> > with
> > > > application class loader first".
> > > >
> > > >   ...ant
> > > >
> > >
> >
> >
> >
> > --
> > 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]
> >
> >
>

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

Re: Spring Integration Tests

[Venkata Krishnan]

Thanks.  Any addition to the tests will be really helpful.  To get a
jumpstart you could copy over one of the existing tests and modify it
deleting / adding classes and resources.

- Venkat

On Feb 12, 2008 12:01 AM, Kevin Williams <[EMAIL PROTECTED]> wrote:

> I noticed there are no spring-related tests in the sca/itest folder
> and I would like to volunteer to add a few.  Does this sound like a
> good idea?  I would probably need some help setting up the basic
> structure before adding content.
>
> Thanks,
>
> --Kevin
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: svn commit: r620376 - /incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java

[Luciano Resende]

Sorry for the break, I have committed an update fix that should take
care of the web container using old version of servlet api. I also
added code to throw an exception when we fail to get the proper
contextPath using the multiple methods we support.

On Feb 11, 2008 10:31 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I just tested the WAR with Jetty-5.1.14 and Tomcat-5.5.26. It was broken
> with Jetty-5.1.14 as the getContextPth() method is not available. On
> Tomcat-5.5.26, the implementation class of ServletContext happens to have
> the method and it's by luck working.
>
> Thanks,
> Raymond
>
>
> - Original Message -
> From: "Raymond Feng" <[EMAIL PROTECTED]>
> To: 
> Sent: Sunday, February 10, 2008 9:46 PM
> Subject: Re: svn commit: r620376 -
> /incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
>
>
> > Hi,
> >
> > I don't think this is a good fix. The ServletContext.getContextPath() is
> > introduced for Servlet Spec 2.5 or later. The major/minor version can tell
> > us if the current ServletContext has getContextPath() method. In Servlet
> > 2.4, the getContextPath() is only available on HttpServletRequest.
> >
> > With this change, we'll get IllegalStateException for Servlet version
> > before 2.5. Is the WebSphere Servlet at the level of 2.5 or later? If so,
> > the getContextPath() should return a valid value as required by the spec.
> > (See [1]). If it returns null, it should be a WebSphere bug :-).
> >
> > BTW, I don't know why we check the init-parameter for the contextPath as a
> > fall-back. Is it a Tuscany specific thing or a Servlet spec statement (I
> > couldn't find it in Servlet spec 2.4)?
> >
> > Thanks,
> > Raymond
> >
> > [1]
> > http://java.sun.com/javaee/5/docs/api/javax/servlet/ServletContext.html#getContextPath()
> >
> > - Original Message -
> > From: <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Sunday, February 10, 2008 6:06 PM
> > Subject: svn commit: r620376 -
> > /incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
> >
> >
> >> Author: lresende
> >> Date: Sun Feb 10 18:06:37 2008
> >> New Revision: 620376
> >>
> >> URL: http://svn.apache.org/viewvc?rev=620376&view=rev
> >> Log:
> >> Comment code that was failing to retrieve contextPath in certain web
> >> containers
> >>
> >> Modified:
> >>
> >> incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
> >>
> >> Modified:
> >> incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
> >> URL:
> >> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java?rev=620376&r1=620375&r2=620376&view=diff
> >> ==
> >> ---
> >> incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
> >> (original)
> >> +++
> >> incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
> >> Sun Feb 10 18:06:37 2008
> >> @@ -240,7 +240,8 @@
> >> public void initContextPath(ServletConfig config) {
> >> ServletContext context = config.getServletContext();
> >> int version = context.getMajorVersion() * 100 +
> >> context.getMinorVersion();
> >> -if (version >= 205) {
> >> +//FIXME Do we really need this ? Servlet 2.4 Spec does mention
> >> getContextPath
> >> +//if (version >= 205) {
> >> // The getContextPath() is introduced since Servlet 2.5
> >> Method m;
> >> try {
> >> @@ -254,9 +255,9 @@
> >> throw new IllegalStateException(
> >> "'contextPath' init
> >> parameter must be set for pre-2.5 servlet container");
> >> }
> >> -} else {
> >> -contextPath = config.getInitParameter("contextPath");
> >> -}
> >> +//} else {
> >> +//contextPath = config.getInitParameter("contextPath");
> >> +//}
> >> logger.info("initContextPath: " + contextPath);
> >> }
> >>
> >>
> >>
> >>
> >> -
> >> 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]
>
>



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

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

[jira] Commented: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types

[Scott Kurz (JIRA)]

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

Scott Kurz commented on TUSCANY-2042:
-

It is looking more like an Axis2 versioning issue for me.

In 1.3, Axis2 J2W seems to switch from generating:

* wsdl def TNS=xxx
* schema TNS for wrapper elems = xxx/xsd

like it did in Axis2 1.2,
to simply:

* wsdl def TNS=xxx
* schema TNS for wrapper elems = xxx

which looks to be my issue. 

> Dynamically generated WSDL not generating output message for void types  
> -
>
> Key: TUSCANY-2042
> URL: https://issues.apache.org/jira/browse/TUSCANY-2042
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Lou Amodeo
> Fix For: Java-SCA-Next
>
> Attachments: helloworld-ws-asynch.jar
>
>
> This problem is similar to Tuscany-1658 but it appears the fix is not working 
> properly in all cases.  I am finding that the 
> namespace and element namespace values assigned durig the dynamic wsdl 
> definition generation are causing the following code to not function because 
> theif (element.getAttribute("targetNamespace").equals(namespaceURI)) { 
> is returning false.   This is because the target namespace is being generated 
> as : targetNamespace=http://helloworld
> while the element namespace is : http://helloworld/xsd  
> The method signature is :  public void getGreetings(String name)
> class:  Java2WSDLHelper.java
>  private static void processNoArgAndVoidReturnMethods(Definition definition, 
> Class javaInterface) {
> String namespaceURI = definition.getTargetNamespace();
> String prefix = definition.getPrefix(namespaceURI);
> String xsPrefix = 
> definition.getPrefix("http://www.w3.org/2001/XMLSchema";);
> PortType portType = 
> (PortType)definition.getAllPortTypes().values().iterator().next();
> Element schema = null;
> Document document = null;
> Types types = definition.getTypes();
> if (types != null) {
> for (Object ext : types.getExtensibilityElements()) {
> if (ext instanceof Schema) {
> Element element = ((Schema)ext).getElement();
> if 
> (element.getAttribute("targetNamespace").equals(namespaceURI)) {
> schema = element;
> document = schema.getOwnerDocument();
> break;
> }
> }
> }
> }
> if (document == null) {
> return;
> }
> Definition generated: 
> Definition: name=null targetNamespace=http://helloworld
> Types:
> SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
> required=null
> element=[xs:schema: null]
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> BindingOperation: name=getGreetings
> BindingInput: name=null
> SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
> required=null
> use=literal
> namespaceURI=http://helloworld
> SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
> required=null
> soapActionURI=urn:getGreetings
> style=document
> SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
> required=null
> transportURI=http://schemas.xmlsoap.org/soap/http
> style=document
> Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> BindingOperation: name=getGreetings
> BindingInput: name=null
> SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
> required=null
> use=literal
> namespaceURI=http://helloworld
> SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
> required=null
> soapActionURI=urn:getGreetings
> style=document
> SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
> required=null
> transportURI=http://schemas.xmlsoap.org/soap/http
> style=document
> Service: name={http://helloworld}HelloWorldService
> Port: name=

SCA and Databases

[John Hunt]

Dear All,

I have a question around SCA and Java embedded in a database. How 
feasible is it to embedded SCA within say the Java VM running within an 
Oracle database, either to provide a service or as a client to call a 
service.


I have a scenario in mind that goes essentially like this:

  1. Some database logic (e.g. PL/SQL) calls a piece of Java code
  2. Java code needs to call out to an external service – for example
 to access an external Work Order system to obtain a new work order id
  3. Java code calls an SCA client, using (say) the Web Services
 binding to access the remote service direct from within the database
  4. Obtains a new id back and continues?

Obviously the Database JVM must be able to support the appropriate 
version of Java etc. but what else might be required.


Potentially hosting services is more of an issue – however, in some 
cases it might be useful to define a Java POJO that will invoke PL/SQL 
within the database for performance issues (obviously we could create a 
POJO external to the database that could call the PL/SQL / stored 
procedures externally). However, I suspect that this is a rather more 
problematic area. For example, depending upon the binding selected what 
functionality is required in the database - how would a web service, rmi 
or jms binding be supported (if indeed at all).


In terms of real world scenarios I know of numerous situations in which 
the SCA client in the database scenario would be very useful. I have 
less “real world” scenarios for the service in the database example.


But should the ability to at least run an SCA Client from within the 
database be a supported SCA scenario? I would be very interested to know 
what the SCA Dev community think about this.


Regards,

John



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

Re: Spring Integration Tests

[Kevin Williams]

Hi Luciano,
Good deal.  I'll get started.  It's been awhile since I've added to
the project structure: directories, maven artifacts, etc.  I'll let
you know if I run into any trouble.
Thanks,
--Kevin

On Feb 11, 2008 1:19 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> Hey Kevin, sure, this would be welcomed. The sca/iTest are based on
> the jUnit framework. What kind of help would you need ?
>
>
> On Feb 11, 2008 10:31 AM, Kevin Williams <[EMAIL PROTECTED]> wrote:
> > I noticed there are no spring-related tests in the sca/itest folder
> > and I would like to volunteer to add a few.  Does this sound like a
> > good idea?  I would probably need some help setting up the basic
> > structure before adding content.
> >
> > Thanks,
> >
> > --Kevin
> >
> > -
> > 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: Tuscany with Weblogic

[haleh mahbod]

Dave,
I added this to the user doc under host environments.
It should show up on the website in a day.

Thanks
Haleh

On 2/11/08, Dave Sowerby <[EMAIL PROTECTED]> wrote:
>
> Yup, all worked great :)
>
> Dave.
>
> On Feb 11, 2008 5:30 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > Thanks, great post. Were you able to run calculator-ws-webapp sample as
> well ?
> >
> >
> > On Feb 11, 2008 9:10 AM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
> > > All,
> > >
> > > I've spotted there's no FAQs for using Tuscany with Weblogic, so I
> > > thought I'd throw something together to help :)
> > >
> > > Over on my blog:
> > >
> > >
> http://davesowerby.blogspot.com/2008/02/using-tuscany-with-weblogic.html
> > >
> > > It covers the updates necessary to webapps and then an example of how
> to deploy.
> > >
> > > If you think it'll be useful, please feel free to link from the FAQs
> > >
> > > Cheers,
> > >
> > > Dave.
> > >
> > > --
> > > Dave Sowerby MEng MBCS
> > >
> > > -
> > > 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]
> >
> >
>
>
>
> --
> Dave Sowerby MEng MBCS
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Spring Integration Tests

[Luciano Resende]

Hey Kevin, sure, this would be welcomed. The sca/iTest are based on
the jUnit framework. What kind of help would you need ?

On Feb 11, 2008 10:31 AM, Kevin Williams <[EMAIL PROTECTED]> wrote:
> I noticed there are no spring-related tests in the sca/itest folder
> and I would like to volunteer to add a few.  Does this sound like a
> good idea?  I would probably need some help setting up the basic
> structure before adding content.
>
> Thanks,
>
> --Kevin
>
> -
> 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: NoSuchMethodError: javax/wsdl/Operation

[ant elder]

I have done all this and still see the problem. I've also search for all the
wsdl4j jars in the WAS install and replaced the few i found with the
1.6.2jar and still see the problem, any other ideas? Seems odd that
Venkat and I
both hit this but others don't.

   ...ant

On Feb 11, 2008 4:47 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:

> I have been using WAS installed with the "Application Server" option.
> It needs a fix for a bug with Servlet Filters, that is available with
> FixPack 9 (or later I guess), and this fix need to be  activated in
> the WAS admin console, navigate to Application Servers - server1 - Web
> Container - Customer Properties and configure a
> com.ibm.ws.webcontainer.invokefilterscompatibility property to true.
> Then, every time you deploy an Tuscany application, you should set the
> proper class path options :  ¨Classes loaded with application class
> loader first"  and "Single class loader per application". See also
> Sebastien's post [1] with much more details on this subject.
>
> Please let me know if this helps.
>
>
> [1]
> http://jsdelfino.blogspot.com/2007/10/how-to-use-apache-tuscany-with.html
>
> On Feb 11, 2008 12:57 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > Yes.  Its the same with me as well.  I have installed WAS 6.1 ND.  Is
> there
> > a particular fixpack that is to take care of this ?
> >
> > Thanks
> >
> > - Venkat
> >
> >
> > On Feb 11, 2008 2:22 PM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > > Trying to run Tuscany WebApp samples in WebSphere i get a
> > > NoSuchMethodError:
> > > javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone
> > > know
> > > how to fix that? This is with the class loader set to "Classes loaded
> with
> > > application class loader first".
> > >
> > >   ...ant
> > >
> >
>
>
>
> --
> 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: Distribution zips and what they contain, was: SCA runtimes

[Simon Nash]

ant elder wrote:

On Feb 10, 2008 10:06 PM, Simon Nash <[EMAIL PROTECTED]> wrote:




But that's OK, if people don't like that split I can also live with a

single big runtime distro.


Over time, we will add more and more optional features and this will
become more and more of a problem.  IMO, it's bad enough now that we
need to do something.



We don't seem to be reaching much consensus on this and i wonder if its
because we don't understand what each of our priorities are. There was an
attempt to find that out over at
http://apache.markmail.org/message/4wldk6zdjxaxz4kf but now here on this
thread I'm a bit lost after the many weeks of discussion so could you say
more about which aspect is "bad enough" now and maybe summarise the
important aspects you'd like the distribution(s) to have?

   ...ant


From a user perspective, if the user is doing personal development,
I suppose most users these days can put up with a 60MB download and
a 60MB runtime.  Where this becomes an issue is for people building
applications or services that depend on the Tuscany runtime and need
to be deployed into various environments.

Examples are packaging the Tuscany runtime packaged inside a webapp,
placing it in a shared library on a JEE appserver, placing it on
the classpath in a J2SE environment, and maybe others.  In all these
cases, it's desirable for the deployed runtime to contain only what's
needed to run the deployed applications.  This is particularly important
for Tuscany's external library dependencies, partly because of the
number and diversity of these (read: risk), and partly because the
versions of these libraries that we ship could potentially conflict
with other things within the runtime environment.

I also have a number of concerns from the Tuscany architecture, design
and implementation perspective.  As a Tuscany developer, I think the
present situation is bad for the following reasons.

1. We claim to have a "modular architecture" but all evidence suggests
   that this isn't the case.  For Tuscany SCA Java, we have to build it
   as one unit, test it as one unit, package it as one unit, and deliver
   it as one unit.  Where is the modularity?  What are the modules?

2. We know that there are dependency issues with some parts of the
   current codebase, with various parts of the runtime dragging
   dependencies that they shouldn't (either other parts of Tuscany or
   external libraries).  How much of the Tuscany runtime, and how
   many external libraries, are needed to run a simple "Hello World"?
   How many of these things are we comfortable with having as
   dependencies, and how many do we think are a problem that should
   be eliminated?  The present structure provides no answers to
   these questions.

3. We know that some of the maven modules are directly using
   implementation code within other maven modules rather than going
   through SPIs, but we don't know exactly what these non-SPI
   couplings are.  Our claim to have a stable and well-defined SPI
   is a little shaky until we get a handle on these exception cases
   and address them.

4. To make Tuscany successful, we need a modular architecture and
   implementation that addresses all the above issues.  This is because
   Tuscany needs to run in many different environments with many different
   configurations.  Without modularity, we won't be able to do this.
   This doesn't necessarily mean that we need to split the distribution
   right now, but I think it does mean that we need to work on improving
   modularity in the code, in at least some of the ways listed above.
   This would give us and our users some flexibility to build and deploy
   different combinations of capability to meet their needs.

  Simon


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

Re: svn commit: r620376 - /incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java

[Raymond Feng]

Hi,

I just tested the WAR with Jetty-5.1.14 and Tomcat-5.5.26. It was broken 
with Jetty-5.1.14 as the getContextPth() method is not available. On 
Tomcat-5.5.26, the implementation class of ServletContext happens to have 
the method and it's by luck working.


Thanks,
Raymond

- Original Message - 
From: "Raymond Feng" <[EMAIL PROTECTED]>

To: 
Sent: Sunday, February 10, 2008 9:46 PM
Subject: Re: svn commit: r620376 - 
/incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java




Hi,

I don't think this is a good fix. The ServletContext.getContextPath() is 
introduced for Servlet Spec 2.5 or later. The major/minor version can tell 
us if the current ServletContext has getContextPath() method. In Servlet 
2.4, the getContextPath() is only available on HttpServletRequest.


With this change, we'll get IllegalStateException for Servlet version 
before 2.5. Is the WebSphere Servlet at the level of 2.5 or later? If so, 
the getContextPath() should return a valid value as required by the spec. 
(See [1]). If it returns null, it should be a WebSphere bug :-).


BTW, I don't know why we check the init-parameter for the contextPath as a 
fall-back. Is it a Tuscany specific thing or a Servlet spec statement (I 
couldn't find it in Servlet spec 2.4)?


Thanks,
Raymond

[1] 
http://java.sun.com/javaee/5/docs/api/javax/servlet/ServletContext.html#getContextPath()


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

To: <[EMAIL PROTECTED]>
Sent: Sunday, February 10, 2008 6:06 PM
Subject: svn commit: r620376 - 
/incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java




Author: lresende
Date: Sun Feb 10 18:06:37 2008
New Revision: 620376

URL: http://svn.apache.org/viewvc?rev=620376&view=rev
Log:
Comment code that was failing to retrieve contextPath in certain web 
containers


Modified:

incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java

Modified: 
incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java?rev=620376&r1=620375&r2=620376&view=diff

==
---  
incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java 
(original)
+++ 
incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java 
Sun Feb 10 18:06:37 2008

@@ -240,7 +240,8 @@
public void initContextPath(ServletConfig config) {
ServletContext context = config.getServletContext();
int version = context.getMajorVersion() * 100 + 
context.getMinorVersion();

-if (version >= 205) {
+//FIXME Do we really need this ? Servlet 2.4 Spec does mention 
getContextPath

+//if (version >= 205) {
// The getContextPath() is introduced since Servlet 2.5
Method m;
try {
@@ -254,9 +255,9 @@
throw new IllegalStateException(
"'contextPath' init 
parameter must be set for pre-2.5 servlet container");

}
-} else {
-contextPath = config.getInitParameter("contextPath");
-}
+//} else {
+//contextPath = config.getInitParameter("contextPath");
+//}
logger.info("initContextPath: " + contextPath);
}




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

Spring Integration Tests

[Kevin Williams]

I noticed there are no spring-related tests in the sca/itest folder
and I would like to volunteer to add a few.  Does this sound like a
good idea?  I would probably need some help setting up the basic
structure before adding content.

Thanks,

--Kevin

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

Re: Tuscany with Weblogic

[Dave Sowerby]

Yup, all worked great :)

Dave.

On Feb 11, 2008 5:30 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> Thanks, great post. Were you able to run calculator-ws-webapp sample as well ?
>
>
> On Feb 11, 2008 9:10 AM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
> > All,
> >
> > I've spotted there's no FAQs for using Tuscany with Weblogic, so I
> > thought I'd throw something together to help :)
> >
> > Over on my blog:
> >
> > http://davesowerby.blogspot.com/2008/02/using-tuscany-with-weblogic.html
> >
> > It covers the updates necessary to webapps and then an example of how to 
> > deploy.
> >
> > If you think it'll be useful, please feel free to link from the FAQs
> >
> > Cheers,
> >
> > Dave.
> >
> > --
> > Dave Sowerby MEng MBCS
> >
> > -
> > 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]
>
>



-- 
Dave Sowerby MEng MBCS

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

Re: Tuscany with Weblogic

[Luciano Resende]

Thanks, great post. Were you able to run calculator-ws-webapp sample as well ?

On Feb 11, 2008 9:10 AM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
> All,
>
> I've spotted there's no FAQs for using Tuscany with Weblogic, so I
> thought I'd throw something together to help :)
>
> Over on my blog:
>
> http://davesowerby.blogspot.com/2008/02/using-tuscany-with-weblogic.html
>
> It covers the updates necessary to webapps and then an example of how to 
> deploy.
>
> If you think it'll be useful, please feel free to link from the FAQs
>
> Cheers,
>
> Dave.
>
> --
> Dave Sowerby MEng MBCS
>
> -
> 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]

[jira] Issue Comment Edited: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types

[Scott Kurz (JIRA)]

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

scottkurz edited comment on TUSCANY-2042 at 2/11/08 9:16 AM:
--

I recreated this at the same time as stepping through the debugger.  

I saw a problem here:

  Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if 
(element.getAttribute("targetNamespace").equals(namespaceURI)) {
   
I think the J2W is generating the WSDL definition with a TNS of "http://blah"; 
while the schema TNS is being
generated as "http://blah/xsd";.  

This equals() was returning false, causing the 'document' ref to remain null, 
causing a return soon after:

if (document == null) {
return;

I think I'm running on an older Axis2 level..  I wonder if that could have 
anything to do with this?

  was (Author: scottkurz):
I recreated this at the same time as stepping through the debugger.  

I saw a problem here:


 (not sure if it's the same as you
  
> Dynamically generated WSDL not generating output message for void types  
> -
>
> Key: TUSCANY-2042
> URL: https://issues.apache.org/jira/browse/TUSCANY-2042
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Lou Amodeo
> Attachments: helloworld-ws-asynch.jar
>
>
> This problem is similar to Tuscany-1658 but it appears the fix is not working 
> properly in all cases.  I am finding that the 
> namespace and element namespace values assigned durig the dynamic wsdl 
> definition generation are causing the following code to not function because 
> theif (element.getAttribute("targetNamespace").equals(namespaceURI)) { 
> is returning false.   This is because the target namespace is being generated 
> as : targetNamespace=http://helloworld
> while the element namespace is : http://helloworld/xsd  
> The method signature is :  public void getGreetings(String name)
> class:  Java2WSDLHelper.java
>  private static void processNoArgAndVoidReturnMethods(Definition definition, 
> Class javaInterface) {
> String namespaceURI = definition.getTargetNamespace();
> String prefix = definition.getPrefix(namespaceURI);
> String xsPrefix = 
> definition.getPrefix("http://www.w3.org/2001/XMLSchema";);
> PortType portType = 
> (PortType)definition.getAllPortTypes().values().iterator().next();
> Element schema = null;
> Document document = null;
> Types types = definition.getTypes();
> if (types != null) {
> for (Object ext : types.getExtensibilityElements()) {
> if (ext instanceof Schema) {
> Element element = ((Schema)ext).getElement();
> if 
> (element.getAttribute("targetNamespace").equals(namespaceURI)) {
> schema = element;
> document = schema.getOwnerDocument();
> break;
> }
> }
> }
> }
> if (document == null) {
> return;
> }
> Definition generated: 
> Definition: name=null targetNamespace=http://helloworld
> Types:
> SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
> required=null
> element=[xs:schema: null]
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> BindingOperation: name=getGreetings
> BindingInput: name=null
> SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
> required=null
> use=literal
> namespaceURI=http://helloworld
> SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
> required=null
> soapActionURI=urn:getGreetings
> style=document
> SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
> required=null
> transportURI=http://schemas.xmlsoap.org/soap/http
> style=document
> Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
> PortType: name={http://helloworld}HelloWorldServicePortType

[jira] Commented: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types

[Scott Kurz (JIRA)]

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

Scott Kurz commented on TUSCANY-2042:
-

I recreated this at the same time as stepping through the debugger.  

I saw a problem here:


 (not sure if it's the same as you

> Dynamically generated WSDL not generating output message for void types  
> -
>
> Key: TUSCANY-2042
> URL: https://issues.apache.org/jira/browse/TUSCANY-2042
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Lou Amodeo
> Attachments: helloworld-ws-asynch.jar
>
>
> This problem is similar to Tuscany-1658 but it appears the fix is not working 
> properly in all cases.  I am finding that the 
> namespace and element namespace values assigned durig the dynamic wsdl 
> definition generation are causing the following code to not function because 
> theif (element.getAttribute("targetNamespace").equals(namespaceURI)) { 
> is returning false.   This is because the target namespace is being generated 
> as : targetNamespace=http://helloworld
> while the element namespace is : http://helloworld/xsd  
> The method signature is :  public void getGreetings(String name)
> class:  Java2WSDLHelper.java
>  private static void processNoArgAndVoidReturnMethods(Definition definition, 
> Class javaInterface) {
> String namespaceURI = definition.getTargetNamespace();
> String prefix = definition.getPrefix(namespaceURI);
> String xsPrefix = 
> definition.getPrefix("http://www.w3.org/2001/XMLSchema";);
> PortType portType = 
> (PortType)definition.getAllPortTypes().values().iterator().next();
> Element schema = null;
> Document document = null;
> Types types = definition.getTypes();
> if (types != null) {
> for (Object ext : types.getExtensibilityElements()) {
> if (ext instanceof Schema) {
> Element element = ((Schema)ext).getElement();
> if 
> (element.getAttribute("targetNamespace").equals(namespaceURI)) {
> schema = element;
> document = schema.getOwnerDocument();
> break;
> }
> }
> }
> }
> if (document == null) {
> return;
> }
> Definition generated: 
> Definition: name=null targetNamespace=http://helloworld
> Types:
> SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
> required=null
> element=[xs:schema: null]
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> BindingOperation: name=getGreetings
> BindingInput: name=null
> SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
> required=null
> use=literal
> namespaceURI=http://helloworld
> SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
> required=null
> soapActionURI=urn:getGreetings
> style=document
> SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
> required=null
> transportURI=http://schemas.xmlsoap.org/soap/http
> style=document
> Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> BindingOperation: name=getGreetings
> BindingInput: name=null
> SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
> required=null
> use=literal
> namespaceURI=http://helloworld
> SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
> required=null
> soapActionURI=urn:getGreetings
> style=document
> SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
> required=null
> transportURI=http://schemas.xmlsoap.org/soap/http
> style=document
> Service: name={http://helloworld}HelloWorldService
> Port: name=HelloWorldServiceSOAP11port
> Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0

Tuscany with Weblogic

[Dave Sowerby]

All,

I've spotted there's no FAQs for using Tuscany with Weblogic, so I
thought I'd throw something together to help :)

Over on my blog:

http://davesowerby.blogspot.com/2008/02/using-tuscany-with-weblogic.html

It covers the updates necessary to webapps and then an example of how to deploy.

If you think it'll be useful, please feel free to link from the FAQs

Cheers,

Dave.

-- 
Dave Sowerby MEng MBCS

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

Re: NoSuchMethodError: javax/wsdl/Operation

[Scott Kurz]

Ant,

There is more than one version of WSDL4J in the WAS 6.1 image.
You're probably getting the wrong one.

Generally speaking WAS 6.1 uses OSGI bundle manifests and a special
OSGi-enabled classloader network to load the
right target class starting from a given source classloader.   There
are some OSGI settings which can help choose the right target..
however your source classloader is an app classloader, rather than
another WAS runtime-level classloader, so I'm not sure myself how the
OSGI settings can be used from an app classloader.

Hope that helps,
Scott



On Feb 11, 2008 11:47 AM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> I have been using WAS installed with the "Application Server" option.
> It needs a fix for a bug with Servlet Filters, that is available with
> FixPack 9 (or later I guess), and this fix need to be  activated in
> the WAS admin console, navigate to Application Servers - server1 - Web
> Container - Customer Properties and configure a
> com.ibm.ws.webcontainer.invokefilterscompatibility property to true.
> Then, every time you deploy an Tuscany application, you should set the
> proper class path options :  ¨Classes loaded with application class
> loader first"  and "Single class loader per application". See also
> Sebastien's post [1] with much more details on this subject.
>
> Please let me know if this helps.
>
>
> [1] http://jsdelfino.blogspot.com/2007/10/how-to-use-apache-tuscany-with.html
>
>
> On Feb 11, 2008 12:57 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > Yes.  Its the same with me as well.  I have installed WAS 6.1 ND.  Is there
> > a particular fixpack that is to take care of this ?
> >
> > Thanks
> >
> > - Venkat
> >
> >
> > On Feb 11, 2008 2:22 PM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > > Trying to run Tuscany WebApp samples in WebSphere i get a
> > > NoSuchMethodError:
> > > javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone
> > > know
> > > how to fix that? This is with the class loader set to "Classes loaded with
> > > application class loader first".
> > >
> > >   ...ant
> > >
> >
>
>
>
> --
> 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]
>
>

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

Re: NoSuchMethodError: javax/wsdl/Operation

[Luciano Resende]

I have been using WAS installed with the "Application Server" option.
It needs a fix for a bug with Servlet Filters, that is available with
FixPack 9 (or later I guess), and this fix need to be  activated in
the WAS admin console, navigate to Application Servers - server1 - Web
Container - Customer Properties and configure a
com.ibm.ws.webcontainer.invokefilterscompatibility property to true.
Then, every time you deploy an Tuscany application, you should set the
proper class path options :  ¨Classes loaded with application class
loader first"  and "Single class loader per application". See also
Sebastien's post [1] with much more details on this subject.

Please let me know if this helps.


[1] http://jsdelfino.blogspot.com/2007/10/how-to-use-apache-tuscany-with.html

On Feb 11, 2008 12:57 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Yes.  Its the same with me as well.  I have installed WAS 6.1 ND.  Is there
> a particular fixpack that is to take care of this ?
>
> Thanks
>
> - Venkat
>
>
> On Feb 11, 2008 2:22 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > Trying to run Tuscany WebApp samples in WebSphere i get a
> > NoSuchMethodError:
> > javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone
> > know
> > how to fix that? This is with the class loader set to "Classes loaded with
> > application class loader first".
> >
> >   ...ant
> >
>



-- 
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: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

[[EMAIL PROTECTED]]

Also how is the mapping from ns to wsdl done w/o an include?

/clemens (powered by ocs mobile)

clemens utschig - utschig
soa product management 

-Original Message-
From: "Clemens Utschig - Utschig" <[EMAIL PROTECTED]>
To: "tuscany-dev@ws.apache.org" 
Sent: 2/11/08 7:30 AM
Subject: RE: Tuscany: Axis2 codegen bug? - java interface exposed as service, 
annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

shouldn't an  do it, so that I could potentially store the wsdl 
anywhere ..

I'll try that later today - thx for the advise..

-Original Message-
From: Simon Nash [mailto:[EMAIL PROTECTED]
Sent: Monday, February 11, 2008 5:54 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, 
annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace


Clemens Utschig - Utschig wrote:
> would it help to have a interface.wsdl? that contains the whole thing - 
> rather than generating it from the annonated java interface?
>
> -- if so, any example for that?
>
Yes, it would help.  It might not solve all the problems, but it should
get you further.

I couldn't find a sample that uses interface.wsdl on a reference (seems
like an omission), though there are a few that use it on a service definition.
You would need to replace the  element with something like
 http://model/common/serviceinterface#wsdl.interface(EmpFlexFieldService)"
 />

The generated wsdl file needs to be somewhere on your classpath.  In our
samples and tests that use generated wsdl, we put the wsdl files in the
src/main/resources/wsdl directory.

  Simon

> cherrs clemens
>
> -Original Message-
> From: Simon Nash [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 10, 2008 12:42 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, 
> annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
>
>
> Jean-Sebastien Delfino wrote:
>> Clemens Utschig - Utschig wrote:
>>> Folks,
>>>
>>> I have a simple composite as below - which makes use of SDO through SOAP in 
>>> the reference
>>>
>>> 
>>> http://www.osoa.org/xmlns/sca/1.0";
>>>targetNamespace="/model/common/"
>>>
>>> xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0";
>>>name="FlexEmployeeComposite" xmlns:tns="/model/common/types/"
>>>xmlns:types="/model/common/types/"
>>>xmlns:errors="http://xmlns.oracle.com/adf/svc/errors/";
>>>xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
>>>   
>>> >> class="com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent"/>
>>> 
>>>   
>>>   >>  promote="FlexEmployeeServiceComponent/empFlexFieldService">
>>> >> interface="model.common.serviceinterface.EmpFlexFieldService"/>
>>> >> uri="http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService"/>
>>>   
>>> 
>>>
>>> that promotes the java interface from the reference as service .. the 
>>> interface is annotated as webservice - as below ..
>>>
>>>@javax.jws.WebMethod(action="/model/common/createEmployees1",
>>> operationName="createEmployees1")
>>> @javax.xml.ws.RequestWrapper(targetNamespace="/model/common/types/",
>>> localName="createEmployees1")
>>> @javax.xml.ws.ResponseWrapper(targetNamespace="/model/common/types/",
>>> localName="createEmployees1Response")
>>> @javax.jws.WebResult(name="result")
>>> DataObject 
>>> createEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN, 
>>> name="employees1")
>>> DataObject employees1) throws ServiceException;
>>>
>>> which implies that the namespace for this element is "/model/common/types/"
>>>
>>> however - Axis2, takes the targetNamespace - and hence tries to send out
>>>
>>> 
>>> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>>> 
>>> <_ns_:getEmployees1 xmlns:_ns_="/model/common/">
>>> 1
>>> 
>>> 
>>> 
>>>
>>>
>>> instead of
>>>
>>> http://schemas.xmlsoap.org/soap/envelope/";>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>> anybody seen this? - this sounds like a real bug to me..
>>>
>>> thx clemens
>> I'm not sure that the support for jaxws annotations is ready and
>> integrated in the build yet, although it may be pretty close.
>>
>> Raymond, it looks like you've been working on the interface-java-jaxws
>> module recently, can you give us its status?
>>
>> Thanks.
>>
> I don't think the code in the interface-java-jaxws module is enough to
> solve this problem.  We also need the ability to generate a WSDL interface
> at runtime from a Java interface containing JAX-WS annotations.  (Our
> current code for this uses Axis2, which doesn't understand JAX-WS
> annotations.)  The code we need would do the same as the JAX-WS tool
> wsgen -wsdl

[jira] Updated: (TUSCANY-2043) documentBaseURI is null when multiple wsdls in contribution with same namespace

[Lou Amodeo (JIRA)]

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

Lou Amodeo updated TUSCANY-2043:


Attachment: helloworld-ws-asynch.jar

Please see attached testcase.  Thanks. 

> documentBaseURI is null when multiple wsdls in contribution with same 
> namespace   
> --
>
> Key: TUSCANY-2043
> URL: https://issues.apache.org/jira/browse/TUSCANY-2043
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Lou Amodeo
> Attachments: helloworld-ws-asynch.jar
>
>
> I have a case where there are 2 wsdl files in the contribution with the same 
> namespace.  After the WSDL resolution the 
> documentBaseURI attribute of the wsdl's  DefinitionImpl is null.  The is 
> normally completed in the WebServiceBindingProcessor.resolve().   In this 
> particular case there are 2 binding.ws elements in the contribution.  One for 
> the service and one for its  binding.   If I change the TNS of one 
> of the WSDL files then the documnetBaseURI is filled in during the 
> WebServiceBindingProcessor.resolve.   So it appears there is in issue in the 
> WSDL Model resolver when it finds multiple WSDL files with the same TNS. 
> 

-- 
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: Performance results.

[Giorgio Zoppi]

2008/2/11, Simon Laws <[EMAIL PROTECTED]>:
> On Feb 10, 2008 12:50 PM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:
>
> > I've tried my app a while ago in a 16 node-cluster and I'm publishing
> > my result at 
> > http://www.cli.di.unipi.it/~zoppi/out/ch06.html
> > They are in italian but you can find many images. I suppose to cache
> > component uri
> > as you can see in the code:
> > http://www.cli.di.unipi.it/~zoppi/out/apas06.html#d4e1968
> > in order to speed up applications.
> > At the end of this work there's all code that i crafted in order to
> > have a behavioural skeleton
> > task farm: a SCA distributed task executor.
> > Next I have to port it to the new Tuscany 1.1.
> > Cheers,
> > Giorgio
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> Hi Giorgio, thanks for posting the results. Looking at the graphs you can
> see the measured completion time diverging from the ideal completion time as
> the task size shrinks and the number of nodes increases. This is to be
> expected as the infrastructure becomes more noticeable in these situations.

Yes it's expected because your infrastructure use a ConcurrentHashMap for async
invocations as a Work queue.

> The question is is it too intrusive and do you have a feeling for where we
> get the best payback in reducing the overhead. You mention caching the URL.
Yes. As you can see the grain is middle/coarse and if you dont' cache the URL,
the situation get worse.
I cache the url and I cache the callableReference, which i resolve for
calling back.
CallableReference --> proxy costs around 500ms too much for me.

> In other discussions over the last few weeks [1] [2] we are looking at a
> slightly simplified approach to deploying the nodes where the topology is
> calculated ahead of time and hence endpoint information can be provided with
> deployed composites. Rather than the nodes having to make calls across the
> information to find this information. This is initially less dynamic than
> the situation we have now but you could argue that it is more predictable.
> Do you see problems for you application in taking this slightly more static
> approach?
No idea. I'll start to review all next week.

> I still have the previous code you attached to the open JIRA [3] sitting on
> my machine. My intention was to check it in as a demonstration but haven't
> done so yet. Should I wait until you have ported to 1.1?
Yes. Wait, because i'm going to refactor inorder to have something
more loosely decoupled.
I saw the latest callback issue, so maybe i'll able to use
infrastructure callback better.

Cheers,
Giorgio.

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

[jira] Created: (TUSCANY-2043) documentBaseURI is null when multiple wsdls in contribution with same namespace

[Lou Amodeo (JIRA)]

documentBaseURI is null when multiple wsdls in contribution with same namespace 
  
--

 Key: TUSCANY-2043
 URL: https://issues.apache.org/jira/browse/TUSCANY-2043
 Project: Tuscany
  Issue Type: Bug
Reporter: Lou Amodeo


I have a case where there are 2 wsdl files in the contribution with the same 
namespace.  After the WSDL resolution the 
documentBaseURI attribute of the wsdl's  DefinitionImpl is null.  The is 
normally completed in the WebServiceBindingProcessor.resolve().   In this 
particular case there are 2 binding.ws elements in the contribution.  One for 
the service and one for its  binding.   If I change the TNS of one of 
the WSDL files then the documnetBaseURI is filled in during the 
WebServiceBindingProcessor.resolve.   So it appears there is in issue in the 
WSDL Model resolver when it finds multiple WSDL files with the same TNS. 



-- 
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-1293) SDO does not work with OSGi

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson commented on TUSCANY-1293:
-

Rajini,
  sorry to take so long to get to this,  and thanks for the patch.  I'm working 
towards getting thsi in for the next release.  I note a couple of occasions in 
the tests where an exception is caught,  and then either output is made to the 
System.out,  or the exception is ignored.  Could you help me understand if in 
either of these cases the symptom is truly benign please?  If so i will add a 
comment to the code.  If not then I'll change to let the exception surface 
through the test infrastructure.

First is on OSGITestCase ...

 // Start all the installed bundles
 for (int i = 0; i < bundles.size(); i++) {
 Bundle bundle = (Bundle)bundles.get(i);
 try {
bundle.start();
} catch (Exception e) {
e.printStackTrace();
System.out.println("Could not start bundle " + 
bundle);
}
 }


second is in ClassLoaderTestCase  (I think I can see this is benign,  but could 
do with confirmation)

for (int i = 0; i < parentLoaders.length; i++) {
try {
return 
parentLoaders[i].loadClass(className);   
} catch (Exception e) {
}
}


> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:89

RE: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

[Clemens Utschig - Utschig]

shouldn't an  do it, so that I could potentially store the wsdl 
anywhere ..

I'll try that later today - thx for the advise..

-Original Message-
From: Simon Nash [mailto:[EMAIL PROTECTED]
Sent: Monday, February 11, 2008 5:54 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, 
annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace


Clemens Utschig - Utschig wrote:
> would it help to have a interface.wsdl? that contains the whole thing - 
> rather than generating it from the annonated java interface?
>
> -- if so, any example for that?
>
Yes, it would help.  It might not solve all the problems, but it should
get you further.

I couldn't find a sample that uses interface.wsdl on a reference (seems
like an omission), though there are a few that use it on a service definition.
You would need to replace the  element with something like
 http://model/common/serviceinterface#wsdl.interface(EmpFlexFieldService)"
 />

The generated wsdl file needs to be somewhere on your classpath.  In our
samples and tests that use generated wsdl, we put the wsdl files in the
src/main/resources/wsdl directory.

  Simon

> cherrs clemens
>
> -Original Message-
> From: Simon Nash [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 10, 2008 12:42 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, 
> annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
>
>
> Jean-Sebastien Delfino wrote:
>> Clemens Utschig - Utschig wrote:
>>> Folks,
>>>
>>> I have a simple composite as below - which makes use of SDO through SOAP in 
>>> the reference
>>>
>>> 
>>> http://www.osoa.org/xmlns/sca/1.0";
>>>targetNamespace="/model/common/"
>>>
>>> xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0";
>>>name="FlexEmployeeComposite" xmlns:tns="/model/common/types/"
>>>xmlns:types="/model/common/types/"
>>>xmlns:errors="http://xmlns.oracle.com/adf/svc/errors/";
>>>xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
>>>   
>>> >> class="com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent"/>
>>> 
>>>   
>>>   >>  promote="FlexEmployeeServiceComponent/empFlexFieldService">
>>> >> interface="model.common.serviceinterface.EmpFlexFieldService"/>
>>> >> uri="http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService"/>
>>>   
>>> 
>>>
>>> that promotes the java interface from the reference as service .. the 
>>> interface is annotated as webservice - as below ..
>>>
>>>@javax.jws.WebMethod(action="/model/common/createEmployees1",
>>> operationName="createEmployees1")
>>> @javax.xml.ws.RequestWrapper(targetNamespace="/model/common/types/",
>>> localName="createEmployees1")
>>> @javax.xml.ws.ResponseWrapper(targetNamespace="/model/common/types/",
>>> localName="createEmployees1Response")
>>> @javax.jws.WebResult(name="result")
>>> DataObject 
>>> createEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN, 
>>> name="employees1")
>>> DataObject employees1) throws ServiceException;
>>>
>>> which implies that the namespace for this element is "/model/common/types/"
>>>
>>> however - Axis2, takes the targetNamespace - and hence tries to send out
>>>
>>> 
>>> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>>> 
>>> <_ns_:getEmployees1 xmlns:_ns_="/model/common/">
>>> 1
>>> 
>>> 
>>> 
>>>
>>>
>>> instead of
>>>
>>> http://schemas.xmlsoap.org/soap/envelope/";>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>> anybody seen this? - this sounds like a real bug to me..
>>>
>>> thx clemens
>> I'm not sure that the support for jaxws annotations is ready and
>> integrated in the build yet, although it may be pretty close.
>>
>> Raymond, it looks like you've been working on the interface-java-jaxws
>> module recently, can you give us its status?
>>
>> Thanks.
>>
> I don't think the code in the interface-java-jaxws module is enough to
> solve this problem.  We also need the ability to generate a WSDL interface
> at runtime from a Java interface containing JAX-WS annotations.  (Our
> current code for this uses Axis2, which doesn't understand JAX-WS
> annotations.)  The code we need would do the same as the JAX-WS tool
> wsgen -wsdl, or the CXF tool java2wsdl, except that the processing would
> be done at runtime and would generate WSDL to a stream instead of a file.
>
>>From a quick look at both these options, it looks like it would be
> possible for the Tuscany runtime to call into code from either CXF or
> the JAX-WS tools to do the generation.  However, this wouldn't be using
> any official APIs but would require a bit of copying and adapting the code
> that 

[jira] Updated: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types

[Lou Amodeo (JIRA)]

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

Lou Amodeo updated TUSCANY-2042:


Attachment: helloworld-ws-asynch.jar

> Dynamically generated WSDL not generating output message for void types  
> -
>
> Key: TUSCANY-2042
> URL: https://issues.apache.org/jira/browse/TUSCANY-2042
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Lou Amodeo
> Attachments: helloworld-ws-asynch.jar
>
>
> This problem is similar to Tuscany-1658 but it appears the fix is not working 
> properly in all cases.  I am finding that the 
> namespace and element namespace values assigned durig the dynamic wsdl 
> definition generation are causing the following code to not function because 
> theif (element.getAttribute("targetNamespace").equals(namespaceURI)) { 
> is returning false.   This is because the target namespace is being generated 
> as : targetNamespace=http://helloworld
> while the element namespace is : http://helloworld/xsd  
> The method signature is :  public void getGreetings(String name)
> class:  Java2WSDLHelper.java
>  private static void processNoArgAndVoidReturnMethods(Definition definition, 
> Class javaInterface) {
> String namespaceURI = definition.getTargetNamespace();
> String prefix = definition.getPrefix(namespaceURI);
> String xsPrefix = 
> definition.getPrefix("http://www.w3.org/2001/XMLSchema";);
> PortType portType = 
> (PortType)definition.getAllPortTypes().values().iterator().next();
> Element schema = null;
> Document document = null;
> Types types = definition.getTypes();
> if (types != null) {
> for (Object ext : types.getExtensibilityElements()) {
> if (ext instanceof Schema) {
> Element element = ((Schema)ext).getElement();
> if 
> (element.getAttribute("targetNamespace").equals(namespaceURI)) {
> schema = element;
> document = schema.getOwnerDocument();
> break;
> }
> }
> }
> }
> if (document == null) {
> return;
> }
> Definition generated: 
> Definition: name=null targetNamespace=http://helloworld
> Types:
> SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
> required=null
> element=[xs:schema: null]
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> BindingOperation: name=getGreetings
> BindingInput: name=null
> SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
> required=null
> use=literal
> namespaceURI=http://helloworld
> SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
> required=null
> soapActionURI=urn:getGreetings
> style=document
> SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
> required=null
> transportURI=http://schemas.xmlsoap.org/soap/http
> style=document
> Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> BindingOperation: name=getGreetings
> BindingInput: name=null
> SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
> required=null
> use=literal
> namespaceURI=http://helloworld
> SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
> required=null
> soapActionURI=urn:getGreetings
> style=document
> SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
> required=null
> transportURI=http://schemas.xmlsoap.org/soap/http
> style=document
> Service: name={http://helloworld}HelloWorldService
> Port: name=HelloWorldServiceSOAP11port
> Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
> PortType: name={http://helloworld}HelloWorldServicePortType
> Operation: name=getGreetings
> style=ONE_WAY,0
> Input: name=null
> Message: name={http://helloworld}getGreetingsMessage
> Part: name=part1
> elementName={http://helloworld/xsd}getGreetings
> 

[jira] Created: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types

[Lou Amodeo (JIRA)]

Dynamically generated WSDL not generating output message for void types  
-

 Key: TUSCANY-2042
 URL: https://issues.apache.org/jira/browse/TUSCANY-2042
 Project: Tuscany
  Issue Type: Bug
Reporter: Lou Amodeo


This problem is similar to Tuscany-1658 but it appears the fix is not working 
properly in all cases.  I am finding that the 
namespace and element namespace values assigned durig the dynamic wsdl 
definition generation are causing the following code to not function because 
theif (element.getAttribute("targetNamespace").equals(namespaceURI)) { 
is returning false.   This is because the target namespace is being generated 
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd  

The method signature is :  public void getGreetings(String name)


class:  Java2WSDLHelper.java

 private static void processNoArgAndVoidReturnMethods(Definition definition, 
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix = 
definition.getPrefix("http://www.w3.org/2001/XMLSchema";);
PortType portType = 
(PortType)definition.getAllPortTypes().values().iterator().next();

Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if 
(element.getAttribute("targetNamespace").equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}


Definition generated: 

Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Service: name={http://helloworld}HelloWorldService
Port: name=HelloWorldServiceSOAP11port
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
SOAPAddress ({http://schemas.xmlsoap.org/wsdl/soap/}address):
requi

Re: Performance results.

[Simon Laws]

On Feb 10, 2008 12:50 PM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:

> I've tried my app a while ago in a 16 node-cluster and I'm publishing
> my result at 
> http://www.cli.di.unipi.it/~zoppi/out/ch06.html
> They are in italian but you can find many images. I suppose to cache
> component uri
> as you can see in the code:
> http://www.cli.di.unipi.it/~zoppi/out/apas06.html#d4e1968
> in order to speed up applications.
> At the end of this work there's all code that i crafted in order to
> have a behavioural skeleton
> task farm: a SCA distributed task executor.
> Next I have to port it to the new Tuscany 1.1.
> Cheers,
> Giorgio
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


Hi Giorgio, thanks for posting the results. Looking at the graphs you can
see the measured completion time diverging from the ideal completion time as
the task size shrinks and the number of nodes increases. This is to be
expected as the infrastructure becomes more noticeable in these situations.
The question is is it too intrusive and do you have a feeling for where we
get the best payback in reducing the overhead. You mention caching the URL.
In other discussions over the last few weeks [1] [2] we are looking at a
slightly simplified approach to deploying the nodes where the topology is
calculated ahead of time and hence endpoint information can be provided with
deployed composites. Rather than the nodes having to make calls across the
information to find this information. This is initially less dynamic than
the situation we have now but you could argue that it is more predictable.
Do you see problems for you application in taking this slightly more static
approach?

I still have the previous code you attached to the open JIRA [3] sitting on
my machine. My intention was to check it in as a demonstration but haven't
done so yet. Should I wait until you have ported to 1.1?

Regards

Simon

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27362.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27609.html
[3] https://issues.apache.org/jira/browse/TUSCANY-1863

[jira] Created: (TUSCANY-2041) Repeated nill elements of extended type cause "Parser found unknown element" exception

[Simon Laws (JIRA)]

Repeated nill elements of extended type cause "Parser found unknown element" 
exception
--

 Key: TUSCANY-2041
 URL: https://issues.apache.org/jira/browse/TUSCANY-2041
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-Next
 Environment: XP SP2, VC7 
Reporter: Simon Laws


With the schema

http://www.w3.org/2001/XMLSchema"; 
targetNamespace="http://www.example.org/AnnonTypes"; 
xmlns:tns="http://www.example.org/AnnonTypes"; 
elementFormDefault="qualified">


  

  

  

  

  



  
 


And XML

http://www.example.org/AnnonTypes"; 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
 xsi:schemaLocation="http://www.example.org/AnnonTypes AnnonTypes2.xsd 
">
  
  http://www.w3.org/2001/XMLSchema-instance"/>
  

Re: NoSuchMethodError: javax/wsdl/Operation

[ant elder]

Exactly what i was looking for, thanks!

   ...ant

On Feb 11, 2008 1:43 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:

> There are some instructions that work for me at:
>
> http://www.jetbrains.com/idea/documentation/howto_02.html
>
> The section called "Configuring WebSphere Application Server"
>
> Hope that helps :)
>
> Dave.
>
> On Feb 11, 2008 12:51 PM, ant elder <[EMAIL PROTECTED]> wrote:
> > And another follow up question - anyone know how to get WebSphere to
> start
> > up listening for a remote debugger to attach to it?
> >
> >...ant
> >
> >
> >
> > On Feb 11, 2008 8:57 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > > Yes.  Its the same with me as well.  I have installed WAS 6.1 ND.  Is
> > > there
> > > a particular fixpack that is to take care of this ?
> > >
> > > Thanks
> > >
> > > - Venkat
> > >
> > > On Feb 11, 2008 2:22 PM, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > > Trying to run Tuscany WebApp samples in WebSphere i get a
> > > > NoSuchMethodError:
> > > > javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List.
> Anyone
> > > > know
> > > > how to fix that? This is with the class loader set to "Classes
> loaded
> > > with
> > > > application class loader first".
> > > >
> > > >   ...ant
> > > >
> > >
> >
>
>
>
> --
> Dave Sowerby MEng MBCS
>

Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

[Simon Nash]

Clemens Utschig - Utschig wrote:
> would it help to have a interface.wsdl? that contains the whole thing - 
> rather than generating it from the annonated java interface?
> 
> -- if so, any example for that?
> 
Yes, it would help.  It might not solve all the problems, but it should
get you further.

I couldn't find a sample that uses interface.wsdl on a reference (seems
like an omission), though there are a few that use it on a service definition.
You would need to replace the  element with something like
 http://model/common/serviceinterface#wsdl.interface(EmpFlexFieldService)"
 />

The generated wsdl file needs to be somewhere on your classpath.  In our
samples and tests that use generated wsdl, we put the wsdl files in the
src/main/resources/wsdl directory.

  Simon

> cherrs clemens
> 
> -Original Message-
> From: Simon Nash [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 10, 2008 12:42 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, 
> annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
> 
> 
> Jean-Sebastien Delfino wrote:
>> Clemens Utschig - Utschig wrote:
>>> Folks,
>>>
>>> I have a simple composite as below - which makes use of SDO through SOAP in 
>>> the reference
>>>
>>> 
>>> http://www.osoa.org/xmlns/sca/1.0";
>>>targetNamespace="/model/common/"
>>>
>>> xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0";
>>>name="FlexEmployeeComposite" xmlns:tns="/model/common/types/"
>>>xmlns:types="/model/common/types/"
>>>xmlns:errors="http://xmlns.oracle.com/adf/svc/errors/";
>>>xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
>>>   
>>> >> class="com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent"/>
>>> 
>>>   
>>>   >>  promote="FlexEmployeeServiceComponent/empFlexFieldService">
>>> >> interface="model.common.serviceinterface.EmpFlexFieldService"/>
>>> >> uri="http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService"/>
>>>   
>>> 
>>>
>>> that promotes the java interface from the reference as service .. the 
>>> interface is annotated as webservice - as below ..
>>>
>>>@javax.jws.WebMethod(action="/model/common/createEmployees1",
>>> operationName="createEmployees1")
>>> @javax.xml.ws.RequestWrapper(targetNamespace="/model/common/types/",
>>> localName="createEmployees1")
>>> @javax.xml.ws.ResponseWrapper(targetNamespace="/model/common/types/",
>>> localName="createEmployees1Response")
>>> @javax.jws.WebResult(name="result")
>>> DataObject 
>>> createEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN, 
>>> name="employees1")
>>> DataObject employees1) throws ServiceException;
>>>
>>> which implies that the namespace for this element is "/model/common/types/"
>>>
>>> however - Axis2, takes the targetNamespace - and hence tries to send out
>>>
>>> 
>>> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>>> 
>>> <_ns_:getEmployees1 xmlns:_ns_="/model/common/">
>>> 1
>>> 
>>> 
>>> 
>>>
>>>
>>> instead of
>>>
>>> http://schemas.xmlsoap.org/soap/envelope/";>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>> anybody seen this? - this sounds like a real bug to me..
>>>
>>> thx clemens
>> I'm not sure that the support for jaxws annotations is ready and
>> integrated in the build yet, although it may be pretty close.
>>
>> Raymond, it looks like you've been working on the interface-java-jaxws
>> module recently, can you give us its status?
>>
>> Thanks.
>>
> I don't think the code in the interface-java-jaxws module is enough to
> solve this problem.  We also need the ability to generate a WSDL interface
> at runtime from a Java interface containing JAX-WS annotations.  (Our
> current code for this uses Axis2, which doesn't understand JAX-WS
> annotations.)  The code we need would do the same as the JAX-WS tool
> wsgen -wsdl, or the CXF tool java2wsdl, except that the processing would
> be done at runtime and would generate WSDL to a stream instead of a file.
> 
>>From a quick look at both these options, it looks like it would be
> possible for the Tuscany runtime to call into code from either CXF or
> the JAX-WS tools to do the generation.  However, this wouldn't be using
> any official APIs but would require a bit of copying and adapting the code
> that is currently there.  Of the two options, the CXF code seems rather
> easier to work with.  Also, since CXF is an Apache project, Tuscany could
> contribute back to CXF any modifications we make to enable this.
> 
> Before I launch into actually trying to get this working, does anyone
> else have comments or suggestions on the general approach?
> 
>   Simon
> 
> 
> 

Re: NoSuchMethodError: javax/wsdl/Operation

[Dave Sowerby]

There are some instructions that work for me at:

http://www.jetbrains.com/idea/documentation/howto_02.html

The section called "Configuring WebSphere Application Server"

Hope that helps :)

Dave.

On Feb 11, 2008 12:51 PM, ant elder <[EMAIL PROTECTED]> wrote:
> And another follow up question - anyone know how to get WebSphere to start
> up listening for a remote debugger to attach to it?
>
>...ant
>
>
>
> On Feb 11, 2008 8:57 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> > Yes.  Its the same with me as well.  I have installed WAS 6.1 ND.  Is
> > there
> > a particular fixpack that is to take care of this ?
> >
> > Thanks
> >
> > - Venkat
> >
> > On Feb 11, 2008 2:22 PM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > > Trying to run Tuscany WebApp samples in WebSphere i get a
> > > NoSuchMethodError:
> > > javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone
> > > know
> > > how to fix that? This is with the class loader set to "Classes loaded
> > with
> > > application class loader first".
> > >
> > >   ...ant
> > >
> >
>



-- 
Dave Sowerby MEng MBCS

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

[jira] Commented: (TUSCANY-1689) XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType named "Descriptor"

[Ron Gavlin (JIRA)]

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

Ron Gavlin commented on TUSCANY-1689:
-

Added as Eclipse EMF Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=218494

> XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType 
> named "Descriptor"
> 
>
> Key: TUSCANY-1689
> URL: https://issues.apache.org/jira/browse/TUSCANY-1689
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
> Environment: Windows XP SP2 w/Sun JDK 1.4.2_11
>Reporter: Ron Gavlin
> Fix For: Java-SDO-Next
>
>
> I have a schema with a complexType named "Descriptor". 
> The generated FactoryImpl.java class includes the following code which does 
> not compile because the return type 
> "org.eclipse.emf.ecore.EPackage.Descriptor" is not compatible with 
> Factory.createDescriptor() with return type "myNamespace.Descriptor":
> public Descriptor createDescriptor()
> {
>   DescriptorImpl descriptor = new DescriptorImpl();
>   return descriptor;
> }
> I suspect this is an EMF bug but I am reporting it here.

-- 
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-1688) XSD2JavaGenerator throws IOException:Access is denied with complexType named "Con"

[Ron Gavlin (JIRA)]

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

Ron Gavlin commented on TUSCANY-1688:
-

Added as Eclipse EMF Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=218493

> XSD2JavaGenerator throws IOException:Access is denied with complexType named 
> "Con"
> --
>
> Key: TUSCANY-1688
> URL: https://issues.apache.org/jira/browse/TUSCANY-1688
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-Next
> Environment: Windows XP SP2 w/Sun JDK 1.4.2_11
>Reporter: Ron Gavlin
> Fix For: Java-SDO-Next
>
>
> I have an XML Schema that contains a complexType named "Con". The following 
> error output is displayed to stdout:
> >> Generating Con
> >> Generating Java interface test.Con
> >> Generating /TargetProject/test/Con.java
> >> Examining old /TargetProject/test/Con.java
> org.eclipse.emf.common.util.WrappedException: java.io.IOException: Access is 
> denied
> at 
> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generateJava 
> (AbstractGeneratorAdapter.java:1046)
> at 
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateInterface
>  (GenClassGeneratorAdapter.java:123)
> at 
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateModel
>  (GenClassGeneratorAdapter.java:106)
> at 
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGeneratorAdapter.doGenerate
>  (GenBaseGeneratorAdapter.java:214)
> at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generate 
> (AbstractGeneratorAdapter.java:275)
> at org.eclipse.emf.codegen.ecore.generator.Generator.generate 
> (Generator.java:600)
> at org.eclipse.emf.codegen.ecore.generator.Generator.generate 
> (Generator.java:512)
> at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel 
> (JavaGenerator.java:515)
> ...
> It seems as if the type name 'Con' conflicts with the operating system's 
> console device named 'Con'. The code first checks to see if the file exists 
> to decide if a merge is required. The code seems to incorrectly find the 
> file/device named 'Con' and then tries to access it in error. I suspect this 
> is an Eclipse EMF problem.

-- 
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: NoSuchMethodError: javax/wsdl/Operation

[ant elder]

And another follow up question - anyone know how to get WebSphere to start
up listening for a remote debugger to attach to it?

   ...ant


On Feb 11, 2008 8:57 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

> Yes.  Its the same with me as well.  I have installed WAS 6.1 ND.  Is
> there
> a particular fixpack that is to take care of this ?
>
> Thanks
>
> - Venkat
>
> On Feb 11, 2008 2:22 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > Trying to run Tuscany WebApp samples in WebSphere i get a
> > NoSuchMethodError:
> > javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone
> > know
> > how to fix that? This is with the class loader set to "Classes loaded
> with
> > application class loader first".
> >
> >   ...ant
> >
>

Re: PolicyHanders

[Venkata Krishnan]

Hi Greg,

Thanks for your observations / suggestions.  Please see my comments inline.
I apologize for making them lengthy in the hope that it would trigger more
discussions.

- Venkat

On Feb 7, 2008 1:33 AM, Greg Dritschler <[EMAIL PROTECTED]> wrote:

> I have been looking at the PolicyHandler support for Java implementations
> and overall I like the direction this is going.  I have some comments
> about
> it.
>
> 1.  If a given component/operation has multiple policy sets that are
> handled
> by the same PolicyHandler, it appears that one PolicyHandler is created
> for
> each such policy set.  I wonder if it wouldn't be better to call a given
> PolicyHandler only once per invocation and give it the full list of policy
> sets it handles.  This may be more efficient depending on the policy (the
> handler may be able to optimize/combine policies, and it may be able to
> find
> conflicts that are beyond the powers of the policy framework).


Just to clarify, I did start with PolicyHanlder types classified against the
PolicySet name, but later discovered that this is not scalable.  Today, the
PolicyHandler types are classified against the PolicyModel that they can
understand (i.e. WS-Policy or some customer model) and the Intent that they
can deal with (i.e authentication or transaction).  I feel we might also
have to add one more classifier that denotes the QoS infrastructure that the
PolicyHandler is capable of working with. While the policy model and intent
can be extracted for a PolicySet to find the appropriate PolicyHandler, I am
not sure where we can encapsulate this 'specific infrastructure'
information.

So, if it does happen that we have mutliple PolicySets on a wire that point
to the same PolicyHandler type, yes it makes sense to do what you suggest.
Infact, this turns out to be a necessity for example when we want to
configure the Axis2 Config Parameters for binding.ws to say enable
authentication AND integrity where each of these could have their own
PolicySets.

2.  Some intents can be provided without requiring a policy set (these are
> the intents in the implementation's mayProvides list).  Although the
> PolicyHandler gets registered for an intent, it appears it is only driven
> if
> the intent is satisfied by a policy set.  It would be nice if it could be
> driven if the intent appears in the mayProvides list too.


+1.  At the present moment this is left to how implementation and binding
extensions would choose to deal with.  I'd prefer that the binding /
implementation providers parse the list of required intents and if there are
the ones that they 'mayProvide' then suitable PolicySets should be added to
the list of PolicySets.  Ofcourse the corresponding PolicyHandlers should
also be defined and registered.  This I feel provide uniformity and
extensibility to how policy handling plugs into extensions.

>
> 3.  I'm also wondering whether it should be possible to register a
> PolicyHandler that always gets control regardless of what intents or
> policy
> sets are specified.  This might be to implement some default behavior.
>  I'm
> thinking of transactions here.  The transaction spec says that the runtime
> can provide one of the intents by default, but the choice of default is
> implementation-specific.  There's no way to declare the default intent to
> the policy framework today, so there's no choice but to give control to
> the
> transaction handler and let it figure it out.
>

This sounds like something that is left for bindings / implementations to
deal with, in the way they might choose to.  As I had mentioned in the
previous point a cleaner way would be for binding /implementation providers
to verify if a default intent needs to be in force and add the corresponding
PolicySet to the list of policysets.  For example, if an implementation
provider parses the requiredIntents and discovers nothing in there related
to transaction intent type, then it could add the default transaction
PolicySet to the list of policysets.  Makes sense or am I missing your
point?


> 4.  The PolicyHandler is provided the target Operation and Message.  I
> wonder if that's enough context.  Can the handler works its way "up" the
> model (component, etc) if it needs to?
>

 I suppose what is 'provided' to the handler depends on the implementation
or binding extension and from where it decides to call the handlers.  If the
handlers are called from the interceptors they can provide any state that is
available to them.  Or if there is context information that is not going to
change across service calls then such information could be initialized into
PolicyHandlers as part of the 'setup' call.


> 5.  It might be nice for the PolicyHandlingInterceptor constructor to make
> an initialization call to the handler so it can do some setup.
>

For the JavaImplementation extension this is done in the
JavaPolicyHandlingRuntimeWireProcessor that creates these PolicyHandlers and
injects them into the interceptor.  The 'setu

[jira] Commented: (TUSCANY-1999) ConversationAttributes and expiry doesn't work with Stateless Conversational components

[Thomas Greenwood (JIRA)]

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

Thomas Greenwood commented on TUSCANY-1999:
---

Thanks Simon.

It will probably be a few weeks before we get our stuff working with the latest 
Tuscany.  As long as the interfaces between the conversation manager and the 
scope container are pretty similar the fix should be OK.

> ConversationAttributes and expiry doesn't work with Stateless Conversational 
> components
> ---
>
> Key: TUSCANY-1999
> URL: https://issues.apache.org/jira/browse/TUSCANY-1999
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
>Reporter: Ben Smith
>Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: ConversationExpiry.patch
>
>
> In services that are marked as @Conversational yet have scope of STATELESS 
> the following problems occur
> Caused by: 
> org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidConversationalImplementation:
>  Service is marked with @ConversationAttributes but the scope is not 
> @Scope("CONVERSATION")
>   at 
> org.apache.tuscany.sca.implementation.java.introspect.impl.ConversationProcessor.visitClass(ConversationProcessor.java:57)
> Also looking at the code it looks as if that expiring of conversations only 
> occurs with services that are of scope CONVERSATION. I believe that the above 
> should work with all services marked as @Conversational. 
> To fix this I'm thinking that the job of expiring conversations should be 
> moved from the ConversationalScopeContainer into the ConversationManager and 
> the check in the ConversationProcessor changed to check for the 
> @Conversational tag not @Scope("CONVERSATION")
> Ben

-- 
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-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4

[Amita Vadhavkar (JIRA)]

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

Amita Vadhavkar updated TUSCANY-257:


Attachment: 257.patch

have used Paul's work and created 257.patch. please review

> recently added file Interface2JavaGenerator.java is not compatible with JDK 
> 1.4
> ---
>
> Key: TUSCANY-257
> URL: https://issues.apache.org/jira/browse/TUSCANY-257
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
> Environment: all
>Reporter: Paul Golick
> Fix For: Java-SDO-Next
>
> Attachments: 257.patch, newFiles.jar, 
> patchInterface2JavaGenerator.txt, patchUpdated.txt
>
>
> Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and 
> java.lang.reflect.Type that were added in Java 5 for generics.  It appears 
> that the portion of Interface2JavaGenerator that uses ParameterizedType and 
> Type is not needed for Java 1.4 classes.

-- 
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-2035) Injected callback references are not resolved at the time of injection

[Thomas Greenwood (JIRA)]

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

Thomas Greenwood commented on TUSCANY-2035:
---

My colleagues have created a patch for this, but it's a bit rough and has some 
issues.  We could try and attach a patch file if you think it might help.

We were thinking that it this change was made then it might be possible to 
start thinking about removing the ThreadMessageContext thread local.  This 
would make it easier for people to use threading in Tuscany.

> Injected callback references are not resolved at the time of injection
> --
>
> Key: TUSCANY-2035
> URL: https://issues.apache.org/jira/browse/TUSCANY-2035
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
> Environment: All
>Reporter: Simon Nash
>Assignee: Simon Nash
> Fix For: Java-SCA-Next
>
>
> When a callback reference is injected as a proxy or a CallableReference, the 
> callback target should be resolved at the time of injection to the caller's 
> callback service or the target of any ServiceReference provided by a 
> setCallbackObject() call.  Tuscany currently does not do this, but resolves 
> the callback target as the time of use, relative to the current invocation 
> context at that time.  For example, if A invokes B and C subsequently invokes 
> the same B instance, any callbacks from the C invocation through references 
> that were injected by the A invocation will go to C instead of going to A as 
> they should.

-- 
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: JIRA backlog

[Simon Laws]

On Feb 6, 2008 1:36 PM, ant elder <[EMAIL PROTECTED]> wrote:

> We've about 170 open JIRAs for SCA, (currently split over 3 versions but
> i'll go move all the SCA ones to SCA-next), what shall we do about them?
>
> There's various suggestions for how to improve JIRA handling listed at:
>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Graduation+Next+Steps
> ,
> which of those should we do? How about as a start we just all focus on
> JIRAs
> for a bit trying to resolve which ever ones we can to see if that brings
> the
> number down much? Thats what i'll go do for now ...
>
>   ...ant


Buried deep in [1] there was a suggestion that the next release will be
called 1.2. I've created a 1.2 release label so we can use that to associate
JIRA with the next release that we have either completed, or would like to
see completed.

Simon

[1] http://apache.markmail.org/message/jwt6vnb3tc4xgfe5

[jira] Updated: (TUSCANY-1688) XSD2JavaGenerator throws IOException:Access is denied with complexType named "Con"

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson updated TUSCANY-1688:



I did a check for EMF bugs raised for this issue,  but couldn't find one.  Do 
you know if this issue has been addressed in EMF?

> XSD2JavaGenerator throws IOException:Access is denied with complexType named 
> "Con"
> --
>
> Key: TUSCANY-1688
> URL: https://issues.apache.org/jira/browse/TUSCANY-1688
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-Next
> Environment: Windows XP SP2 w/Sun JDK 1.4.2_11
>Reporter: Ron Gavlin
> Fix For: Java-SDO-Next
>
>
> I have an XML Schema that contains a complexType named "Con". The following 
> error output is displayed to stdout:
> >> Generating Con
> >> Generating Java interface test.Con
> >> Generating /TargetProject/test/Con.java
> >> Examining old /TargetProject/test/Con.java
> org.eclipse.emf.common.util.WrappedException: java.io.IOException: Access is 
> denied
> at 
> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generateJava 
> (AbstractGeneratorAdapter.java:1046)
> at 
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateInterface
>  (GenClassGeneratorAdapter.java:123)
> at 
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateModel
>  (GenClassGeneratorAdapter.java:106)
> at 
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGeneratorAdapter.doGenerate
>  (GenBaseGeneratorAdapter.java:214)
> at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generate 
> (AbstractGeneratorAdapter.java:275)
> at org.eclipse.emf.codegen.ecore.generator.Generator.generate 
> (Generator.java:600)
> at org.eclipse.emf.codegen.ecore.generator.Generator.generate 
> (Generator.java:512)
> at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel 
> (JavaGenerator.java:515)
> ...
> It seems as if the type name 'Con' conflicts with the operating system's 
> console device named 'Con'. The code first checks to see if the file exists 
> to decide if a merge is required. The code seems to incorrectly find the 
> file/device named 'Con' and then tries to access it in error. I suspect this 
> is an Eclipse EMF problem.

-- 
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-1689) XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType named "Descriptor"

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson updated TUSCANY-1689:



I did a check for EMF bugs raised for this issue,  but couldn't find one.  Do 
you know if this issue has been addressed in EMF?

> XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType 
> named "Descriptor"
> 
>
> Key: TUSCANY-1689
> URL: https://issues.apache.org/jira/browse/TUSCANY-1689
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
> Environment: Windows XP SP2 w/Sun JDK 1.4.2_11
>Reporter: Ron Gavlin
> Fix For: Java-SDO-Next
>
>
> I have a schema with a complexType named "Descriptor". 
> The generated FactoryImpl.java class includes the following code which does 
> not compile because the return type 
> "org.eclipse.emf.ecore.EPackage.Descriptor" is not compatible with 
> Factory.createDescriptor() with return type "myNamespace.Descriptor":
> public Descriptor createDescriptor()
> {
>   DescriptorImpl descriptor = new DescriptorImpl();
>   return descriptor;
> }
> I suspect this is an EMF bug but I am reporting it here.

-- 
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-1831) Make SDOPackageRegistryDelegator pluggable

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson commented on TUSCANY-1831:
-

I guess we could parallel the way that the default HelperProvider 
implementation is made pluggable in the SDO API project's HelperProvider class, 
 where the default impl is looked up by PROPERTY_NAME.

> Make SDOPackageRegistryDelegator pluggable
> --
>
> Key: TUSCANY-1831
> URL: https://issues.apache.org/jira/browse/TUSCANY-1831
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
> Fix For: Java-SDO-Next
>
>
> The current SDOPackageRegistryDelegator implementation assumes that a 
> standard, hierarchical classloader structure is present in the "hosting 
> environment". BEA WebLogic, for example, uses an unusual "change aware" 
> classloading scheme which does not meet the expectations of the 
> SDOPackageRegistryDelegator. Prior to Tuscany SDO 1.0, I was able to 
> work-around this former EMF problem by setting the EMF JVM property 
> "org.eclipse.emf.ecore.EPackage.Registry.INSTANCE". In Tuscany SDO 1.0, this 
> setting is no longer relevant. I would like to be able to plugin my own 
> SDOPackageRegistryDelegator implementation that provides a 
> non-classloader-aware registry, knowing full well the limitations of of this 
> implementation.

-- 
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: Distribution zips and what they contain, was: SCA runtimes

[ant elder]

On Feb 10, 2008 10:06 PM, Simon Nash <[EMAIL PROTECTED]> wrote:



> But that's OK, if people don't like that split I can also live with a
> > single big runtime distro.
> >
> Over time, we will add more and more optional features and this will
> become more and more of a problem.  IMO, it's bad enough now that we
> need to do something.
>

We don't seem to be reaching much consensus on this and i wonder if its
because we don't understand what each of our priorities are. There was an
attempt to find that out over at
http://apache.markmail.org/message/4wldk6zdjxaxz4kf but now here on this
thread I'm a bit lost after the many weeks of discussion so could you say
more about which aspect is "bad enough" now and maybe summarise the
important aspects you'd like the distribution(s) to have?

   ...ant

Re: NoSuchMethodError: javax/wsdl/Operation

[Venkata Krishnan]

Yes.  Its the same with me as well.  I have installed WAS 6.1 ND.  Is there
a particular fixpack that is to take care of this ?

Thanks

- Venkat

On Feb 11, 2008 2:22 PM, ant elder <[EMAIL PROTECTED]> wrote:

> Trying to run Tuscany WebApp samples in WebSphere i get a
> NoSuchMethodError:
> javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone
> know
> how to fix that? This is with the class loader set to "Classes loaded with
> application class loader first".
>
>   ...ant
>

NoSuchMethodError: javax/wsdl/Operation

[ant elder]

Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError:
javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know
how to fix that? This is with the class loader set to "Classes loaded with
application class loader first".

   ...ant