date:20070831

Consolidate extended provider SPI interfaces into base interfaces
-

 Key: TUSCANY-1640
 URL: https://issues.apache.org/jira/browse/TUSCANY-1640
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.99
 Environment: Windows XP
Reporter: Simon Nash
 Fix For: Java-SCA-1.0


In org.apache.tuscany.sca.provider, we have some extended SPI interfaces that 
were introduced to support new functionality in a way htat would not impact 
existing extension code by putting new methods into the base SPI interfaces.  
The extended SPI interfaces are:
  ReferenceBindingProvider2
  ServiceBindingProvider2
  ImplementationProvider2 (part of patch 4 for TUSCANY-1500)

The following changes should be made to base SPI interfaces so that these 
extended interfaces can be eliminated:
1. In ReferenceBindingProvider, add createInvoker(Operation operation) and 
remove createInvoker(Operation operation, boolean isCallback).  Change existing 
provider code to use the new signature.
2. In ReferenceBindingProvider, add supportsAsyncOneWayInvocation().  Change 
existing provider code to implement this method and return false.
3. In ServiceBindingProvider, add supportsAsyncOneWayInvocation().  Change 
existing provider code to implement this method and return false.
4. In ImplementationProvider, add  processReferenceWire(RuntimeWire wire).  
Change existing provider code to implement this method and do nothing.
 .

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


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

[jira] Created: (TUSCANY-1641) @Destroy method not called for CompositeScope

2007-08-31 Thread Mark Combellack (JIRA)

@Destroy method not called for CompositeScope
-

 Key: TUSCANY-1641
 URL: https://issues.apache.org/jira/browse/TUSCANY-1641
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
 Environment: Linux
Tuscany SVN revision 571406
Reporter: Mark Combellack
 Fix For: Java-SCA-1.0


If you define a method on a class with Composite Scope, the @Destroy method is 
not called when the SCA Domain is closed.


The flow of events is:

DefaultSCADomain.close()
 - For Each CompositeActivator
- CompositeActivatorImpl.stop()
- If instance of ScopedRuntimeComponent then
   - compositeScopeContainer.stop()


The problem is in the CompositeScopeContainer.stop() method:

public synchronized void stop() {
super.stop();
wrapper = null;
}

The stop method just nulls the reference to the wrapper. However, if wrapper != 
null then it should call wrapper.stop().

The wrapper is actually an instance of ReflectiveInstanceWrapper which is 
responsible for calling the @Start and @Destroy annotated methods when 
wrapper.start() and wrapper.stop() are called.

The final code for the CompositeScopeContainer.stop() method would be something 
like:

public synchronized void stop() {
super.stop();
if (wrapper != null) {
try {
wrapper.stop();
} catch (TargetDestructionException ex) {
// TODO: Handle this exception better
ex.printStackTrace();
}
}
wrapper = null;
}




-- 
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-1641) @Destroy method not called for CompositeScope

2007-08-31 Thread Mark Combellack (JIRA)


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

Mark Combellack updated TUSCANY-1641:
-

Patch Info: [Patch Available]

Have attached patch to fix this issue

 @Destroy method not called for CompositeScope
 -

 Key: TUSCANY-1641
 URL: https://issues.apache.org/jira/browse/TUSCANY-1641
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
 Environment: Linux
 Tuscany SVN revision 571406
Reporter: Mark Combellack
 Fix For: Java-SCA-1.0

 Attachments: DestroyForCompositeScope.patch


 If you define a method on a class with Composite Scope, the @Destroy method 
 is not called when the SCA Domain is closed.
 The flow of events is:
 DefaultSCADomain.close()
  - For Each CompositeActivator
 - CompositeActivatorImpl.stop()
 - If instance of ScopedRuntimeComponent then
- compositeScopeContainer.stop()
 The problem is in the CompositeScopeContainer.stop() method:
 public synchronized void stop() {
 super.stop();
 wrapper = null;
 }
 The stop method just nulls the reference to the wrapper. However, if wrapper 
 != null then it should call wrapper.stop().
 The wrapper is actually an instance of ReflectiveInstanceWrapper which is 
 responsible for calling the @Start and @Destroy annotated methods when 
 wrapper.start() and wrapper.stop() are called.
 The final code for the CompositeScopeContainer.stop() method would be 
 something like:
 public synchronized void stop() {
 super.stop();
 if (wrapper != null) {
 try {
 wrapper.stop();
 } catch (TargetDestructionException ex) {
 // TODO: Handle this exception better
 ex.printStackTrace();
 }
 }
 wrapper = null;
 }

-- 
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-1641) @Destroy method not called for CompositeScope

2007-08-31 Thread Mark Combellack (JIRA)


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

Mark Combellack updated TUSCANY-1641:
-

Attachment: DestroyForCompositeScope.patch

 @Destroy method not called for CompositeScope
 -

 Key: TUSCANY-1641
 URL: https://issues.apache.org/jira/browse/TUSCANY-1641
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
 Environment: Linux
 Tuscany SVN revision 571406
Reporter: Mark Combellack
 Fix For: Java-SCA-1.0

 Attachments: DestroyForCompositeScope.patch


 If you define a method on a class with Composite Scope, the @Destroy method 
 is not called when the SCA Domain is closed.
 The flow of events is:
 DefaultSCADomain.close()
  - For Each CompositeActivator
 - CompositeActivatorImpl.stop()
 - If instance of ScopedRuntimeComponent then
- compositeScopeContainer.stop()
 The problem is in the CompositeScopeContainer.stop() method:
 public synchronized void stop() {
 super.stop();
 wrapper = null;
 }
 The stop method just nulls the reference to the wrapper. However, if wrapper 
 != null then it should call wrapper.stop().
 The wrapper is actually an instance of ReflectiveInstanceWrapper which is 
 responsible for calling the @Start and @Destroy annotated methods when 
 wrapper.start() and wrapper.stop() are called.
 The final code for the CompositeScopeContainer.stop() method would be 
 something like:
 public synchronized void stop() {
 super.stop();
 if (wrapper != null) {
 try {
 wrapper.stop();
 } catch (TargetDestructionException ex) {
 // TODO: Handle this exception better
 ex.printStackTrace();
 }
 }
 wrapper = null;
 }

-- 
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: [DAS] Transaction support

2007-08-31 Thread Amita Vadhavkar

Hi,
I have tried to use JOTM and Tomcat and would like to create a sample web
app in
DAS showing how external transaction manager can control DAS transactions.
I am creating another mail thread for any discussion for this sample + JOTM
issues.

We can demonstrate through this and accompanying wiki - how Txn support in
DAS
for externally managed txns should do.
Regards,
Amita

On 8/17/07, Luciano Resende [EMAIL PROTECTED] wrote:

 By doing a quick debug on Amita's testcase from JIRA-1543, looks like
 we might have some bugs in our current code, that might be causing
 this whole confusion. Let me spend couple hours on this over the
 weekend, and send some feedback after that. I'll also write a wiki
 page with what I think the Transaction support should do/work.

 On 8/17/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
  Just trying to see what changes will be needed (marked with )
  1) when connection from user, and he wants to delegate transaction
 control
  to DAS,
  allow it only per/Command. This will save user from issuing one
  commit/rollback per command in the client code. (i.e. current way of
  managetx=true default, connection passed from user). So this is as of
 today,
  no changes needed.
 
  2) when connection from user and user wants to control single/group of
  commands, he should set managedtx=false.
  -As default managedtx=true, user in this case will need to put
  ConnectionInfo element in config just for the sake of passing
  managedtx=false
  Giving new test case showing this
 
  3)-- fix logic of DASImpl.managingConnections() - should just look
 at
  managedtx
 
  4) when connection from DAS and user wants to control single/group of
  commands, he should set  managedtx=false
 
  --- new test cases showing manage single/group of Commands
 
  5)DAS will expose getConnection() for all cases except when connection
 by
  DAS, tx management by DAS
  --public Connection DAS.getConnection();
  For exception case throw RuntimeException from DAS -
  DAS is controlling transaction, can not expose Connection!
 
  5)
  awhen user passes connection in DAS() and also sets ConnectionInfo
  -datasource/drivermanager - specify that passed connection will be used
 and
  config connection will be ignored.
 
  bDAS can manage connection only when it is created internally and
  only/Command. i.e. DAS does not support internally managing transactions
 for
  group of commands
 
  -- Document - FAQs?
 
  6) DAS throws RuntimeException with embedded SQLException - may it be
  connection closed, integrity violation etc.
  ---no changes needed
 
  I will submit patch for JIRA-1466 using above summary shortly.
  Regards,
  Amita
  On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote:
  
   forwarding last message to dev list...
  
   On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote:
   
Hi Amita, thanks for the examples, it always helps to clarify : ).
 My
comments:
   
Use Case 1:
I think if there is part of the code the user needs to control the
transaction directly, he would never set the managedtx=true, that's
 why
managedtx is an option, to give a chance to the user decide if he
 wants
   or
not to control anytime the transaction. So, on my opinion it's an
 user
   error
that set the managedtx as true when he wants to control the
 transaction,
   and
not a DAS error.
   
I understand that your point is try to avoid a user mistake like
 this,
although the user needs to know well what the DAS interface does or
 not,
   and
on this case the DAS interface says: DAS will control the
 transactions
   when
you set managedtx=true. This kind of user mistake could be easily
   resolved
if a Connection object could be easily copied, but as far as I know
 it
can't.
   
Use Case 2:
Here I agree that not to expose the Connection when its created by
 DAS
   and
managedtx is false is a DAS mistake. That's why I vote to expose
getConnection and I see no problem to throw some kind of exception
 when
   user
tries to invoke getConnection when managedtx=true.
   
Use Case 3:
a) About user invoking closeConnection, it's the same case I
 described
   on
Use Case 1's comments, the user needs to be aware that DAS is
   controlling
the transactions. However, DAS should throw some kind of exception
 when
   the
Connection is closed externally, I don't know if it's doing that.
   
b) If exposing the getConnection, I do not see anything new in using
   these
new methods, start/endTransactions, that user cannot perform only
 using
   a
Connection object.
   
c) About data integrity, I think it's also wrong decision if the
 user
   set
the managedtx=true if he may further want to perform a rollback on
 the
   db.
   
In conclusion:
   
+1 for exposing getConnection
   
- for adding methods startTransaction and endTranscation
   
Regards,
Adriano Crestani
   
   
On 8/16/07,

[DAS] DAS Web Sample with Tomcat and JOTM as Transaction Manager

2007-08-31 Thread Amita Vadhavkar

I am using jotm-2.0.10 and Tomcat 5.5.23.
The HowTo from JOTM site has a few problems and the below info worked for me
-
[1]http://www.nabble.com/UserTransaction,-
JOTM-and-Tomcat-5.5.x-t1073172.html
[2]http://static.raibledesigns.com/downloads/howto-tomcat-jotm.html

Also, as mentioned in [1] for hsql, for Derby too , I checked that
ut.rollback does not work (used the sample from
.jotm-2.0.10\examples\tomcat - tailored for Derby). So, MySQL may need to be
used for this. With its InnoDB feature ON.
(Ref -
[3]http://www.onjava.com/pub/a/onjava/2003/07/30/jotm_transactions.html?page=2
)

Please see the attached screenshot and comment if something like this will
be useful as the sample? Or some
different use case/example will suite better.

Also, I am finding it quite easy to re-use the sample-ajax-das framework to
deploy this new sample. Please advise,
if it should stand separate and not part of that sample. The ease in re-use
lies in the generic -servlet, js, menu jsp
and service processor etc.  We can rename sample-ajax-das to ''Advanced
DAS Web Sample, any better name?

Please comment on all of the above, so I will proceed with creating the
required sample using your feedback.

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

Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks


I think it would be good to step back from details of which characters are
usable in URIs and look at the bigger picture.  The major question we have
to decide is whether the pseudo-services used by callbacks are to be treated
from the user's perspective
 a. exactly like SCA services in every respect
 b. exactly like SCA services except for a very small number of differences
 c. as a different thing from an SCA service with its own set of rules for
how it is used

By treating these exactly like SCA services, I mean doing the following
things with them:
 1. Specifying as a target of a reference wire
 2. Specifying a callback interface and binding in addition to a forward
interface and binding
 3. Creating a ServiceReference that can be passed to setCallback()
 4. Creating a ServiceReference that can be used for normal forward
invocations
 5. Mapping to an endpoint URI using the standard algorithm defined in
the SCA assembly spec
 6. Enforcing name uniqueness rules with respect to other services
 7. Including in the calculation of whether a component only has a single
service so that its default URI need not include the service name
 8. Automatically creating an exposed endpoint on a configured host server
There could be other aspects that I have overlooked.  Please send your
additions to this list.

As a simple solution I'd like to propose that a callback reference defines
an SCA service with the same name as the reference, and that this service
can be used exactly like an SCA service except for points 1 and 2 above,
which are explicitly precluded by the SCA assembly spec.  This callback
service would support all the other points on the list above and any other
properties of SCA services that I may have overlooked in the above list.

The soundbite version is: Callbacks are full SCA services that can't be
wired and can't themselves have callbacks.

Any thoughts or comments on this, or other suggestions?

  Simon

Simon Nash wrote:

See inline.

  Simon

Jean-Sebastien Delfino wrote:

(cut)


The # symbol has a special meaning in URIs as it separates a URI from 
a fragment id. This form of URI will prevent bindings to use fragment 
ids to identify the target operation or to append some context to the 
URI for example.


RFC 2396 [1], section 4.1 clearly states this:
When a URI reference is used to perform a retrieval action on the
identified resource, the optional fragment identifier, separated from
the URI by a crosshatch (#) character, consists of additional
reference information to be interpreted *BY THE USER AGENT* after the
retrieval action has been successfully completed.  As such, *IT IS NOT
PART OF A URI*, but is often used in conjunction with a URI.

So I don't think that using '#' is a good idea. It may work with some 
bindings, will break others.


[1] http://www.ietf.org/rfc/rfc2396.txt



Thanks for explaining the issues with #.  There were other questions
in my last post concerning the use of / as the separator.  Since you
didn't comment on these, I'm assuming that I have correctly captured
the scenario that causes you concerns with this.

The reference to RFC2396 is extremely helpful and provides (I think)
the necessary information to come up with a good solution to your
challenge.  From this document, we have a few options for the
separator character.

Option 1: Use semicolon (;).  In section 3.3 of RFC 2394 this is defined
as delimiting a parameter or parameters that are part of a path
component.  It seems quite appropriate to use a ;callback suffix in
the last path segment of a URI to represent a callback parameter.

Option 2: Use any character that's legal within a path component but
not legal in an NCName (used for SCA service and reference names).
The possible characters are
  path segment characters in section 3.3:
: | @ |  | = | + | $ | ,
  unreserved characters in section 2.3:
! | ~ | * | ' | ( | )
I don't have a strong preference here, but : and @ look good to
me, with ! as a possible alternative.

With any of these approaches, some kind of callback suffix appears
explicitly in the URI, rather than relying on a SCDL naming uniqueness
rule and having a URI that doesn't indicate that it's for a callback.
I think having an explicit callback indication in the name is helpful
for users, assuming that we can pick a convenient and robust syntax
for this.  I hope that one of the above options will satisfy this
requirement.




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

Notes on ws-binding

2007-08-31 Thread Giorgio Zoppi

Hi again,
i saw tuscany ws binding and it fits my needs both OneWay Invocations
and callbacks work fine. I've put some findings at
http://g4sca.blogspot.com/ so now the next..what i've to do is bootstrap
a node with an EmbeddedNode and use that binding. Axis2 permits some
kind of data-mapping with JiBX( in Axis2 with the -d jibx -E parameters)
for example, do you have a data mapping api so you can pass arbitrary
objects to a Component? Without any data mapping there's an hack for
doing that and it's using reflection inside a component and pass a byte
array with the class serialized. Any suggestions?


Cheers,
Jo.

P.S. Sca remote binding simply hangs, I've not still discovered the
reason, but i'm sure that next week when i'll have a more deep
understanding of ws binding and something working with it..I'll see that
code. The only thing that i've seen is that i do a request to the
ServiceDiscovery Servlet for every request, a caching (o keep-alive)
mechanism would be more useful: every node should be have a partial view
of the domain.



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

[ANNOUNCE] Apache Tuscany SCA Java 0.99 released

2007-08-31 Thread ant elder

The Apache Tuscany team are pleased to announce the 0.99-incubating
release of the Java SCA project.

Apache Tuscany provides a runtime based on the Service Component
Architecture. SCA is a set of specifications aimed at simplifying SOA
Application Development which are being standardized at OASIS as part
of Open Composite Services Architecture (Open CSA).

This release of Apache Tuscany SCA builds on the stability and
modularity established with the previous releases and includes more
complete implementation of SCA specifications, support for distributed
SCA domains, SCA policy, OSGi implementation types, and pub/sub
support with notification components. Start up time and memory
footprint of the runtime has been reduced and there have been numerous
bug fixes. This is expected to be the last point release before the
1.0 final release.

For full detail about the release see the RELEASE_NOTES and CHANGES files.

To download or for more information about the release go to:
http://incubator.apache.org/tuscany/sca-java-releases.html

To find out more about OASIS Open CSA go to: http://www.oasis-opencsa.org.

Apache Tuscany welcomes your help. Any contribution, including code,
testing, improving the documentation, or bug reporting is always
appreciated. For more information on how to get involved in Apache
Tuscany visit the website at: http://incubator.apache.org/tuscany.

Thank you for your interest in Apache Tuscany!
The Apache Tuscany Team.

---

Tuscany is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the Apache Web services PMC. Incubation
is required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making
process have stabilized in a manner consistent with other successful
ASF projects. While incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate that
the project has yet to be fully endorsed by the ASF.

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

Re: Monitoring, logging and exceptions (again)

On 8/29/07, Raymond Feng [EMAIL PROTECTED] wrote:

 I just created https://issues.apache.org/jira/browse/TUSCANY-1635 to track
 the aspectj-based tracing.

 Thanks,
 Raymond

 - Original Message -
 From: Jean-Sebastien Delfino [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Wednesday, August 29, 2007 11:06 AM
 Subject: Re: Monitoring, logging and exceptions (again)


  Simon Laws wrote:
  On 8/20/07, Simon Laws [EMAIL PROTECTED] wrote:
 
 
  On 8/20/07, Simon Nash [EMAIL PROTECTED]  wrote:
 
  See inline.
 
 Simon
 
  Raymond Feng wrote:
 
 
  Comments inline.
 
  Thanks,
  Raymond
 
  - Original Message - From: Jean-Sebastien Delfino
   [EMAIL PROTECTED]
  To:  tuscany-dev@ws.apache.org
  Sent: Friday, August 17, 2007 9:27 AM
  Subject: Re: Monitoring, logging and exceptions (again)
 
 
 
  [snip]
  ant elder wrote:
 
 
  And also my 2p inline...
 
 ...ant
 
  On 8/16/07, Simon Laws  [EMAIL PROTECTED] wrote:
 
 
  A number of different requirements have been discussed and
 
  solutions
 
  proposed. My 2p (I'm using Raymond's definitions b.t.w)
 
  Tracing: Dump out input/output/exception for method calls for the
  purpose
  of
  debugging/troubleshooting. (Target for developers/technical
 
  support)
 
  I feel that tracing of execution paths through the Tuscany
 codebase
  would
  be
  useful but agree that  it's a lot of work and will be difficult
 to
maintain
  and keep consistent if we did it manually.  I'm happy that this
 is
 
  the
 
  responsibility of whoever wants to trace through the code and not
 a
  core
  part of the codebase. For the Tuscany developer community AspectJ
 
  have
 
  been
  proposed a couple of times and support has been prototyped. We
 
  could
 
  choose
  SLF4J as the  interface through which  messages are output.
 
 
  I'm not sure we need to use SLF4J if we go the AspectJ route.
 SLF4J
 
  is a
 
  facade for logging APIs, so you can code to  the SLF4J API and
 then
  plug in
  whatever logging impl you like, but if the only logging calls we
 
  have
 
  are
  confined to a single tracing aspect we might as well just code
 that
  aspect
  to a specific logging API like JDK logging. That avoids the extra
  dependency
  on SLF4J and anyone can add additional aspects if they really want
 
  to
 
  use a
  different logger. The main other benefit of SLF4J is its
 
  parameterized
 
  message logging (avoids all the if(logger.isDebugEnabled()) )
 but
  again if
  all the logging calls are in a single aspect thats not so useful.
 
 
  Makes sense to me. If we go the aspectj route for tracing method
  entry/exit, I agree that using the JDK logger directly is simpler.
 
 
  Since the aspect is on the side, we're flexible. JDK logger can be
  default and it can be replaced easily if the embedders or users
 choose
  to do so.
 
 
  A few more questions on this: What dependencies will aspectj add to
  our distribution? aspectjweaver is more than 1Mb, do we need it?
 
  I'll try to spend some time to explore both the compile-time and
  load-time weaving.
 
 
  What about mid-method logging of specific interesting events, for
  example
  the contents of requests as the enter and leave bindings and
  implementation
  types and things like that? That sort of logging is often all a
 lot
  of users
  want to see not the detail tracing of every method entry/exit.
 Could
  we add
  things like this in specific places?
 
 
  +1 for the ability to produce this level of information.  This is my
  preferred approach for debugging or understanding how some part of
 the
  code works.  Having every method entry and exit produce a trace line
  often creates a huge amount of output that obscures the essential
  details
  of what is happening.
 
 
  Can this mid-method logging be split in two categories?
 
  a) Debug tracing
  A simple solution is to split the method in two, and then leverage
 
  the
 
  entry/exit method tracing as discussed above.
 
  In many cases this would lead to a convoluted code structure with
 local
  variables needing to be passed as parameters between the two methods,
  or
  methods that contain a single line of code (if a trace line needs to
 be
  produced from within a loop).
 
 
  We can use JDK logger to add statements in the middle of a method.
 
  Then
 
  we can use an aspect to capture such calls to dump out the
 
  information.
 
  For example, if we have the following statement in a method:
  logger.debug(...);
  The apsect can trap it by a point cut like call *
  java.util.logger.Logger.debug(..).
 
 
  If the logger call is already there, why is an aspect needed to trap
  it?
  Why not just let it execute?
 
 
  b) End-user readable information (info that a binding is
  sending/receiving a message for example)
  This falls into the second category discussed in this thread,
  reporting significant events to a management console.
 
  The above suggestion should help too. The key here is to have some
 
  calls

Re: Notes on ws-binding

2007-08-31 Thread ant elder

Tuscany has a data binding framework so that most data bindings could be
supported, but there has to be a Tuscany databinding extension written for
each data binding and there's no JiBX one yet, would be really cool if
someone could help write one...interested in helping? There's a bit of
documentation on this at [1] and some examples from the existing databinding
extensions at [2], [3], [4].

Until that happens one thing you could do is just use Axiom OMElements for
the service parameters and do all the conversion to/from XML to JiBX objects
yourself within the component impl. There's one of the Tuscany tests that
shows working with OMElements at [5]

   ...ant

[1] http://incubator.apache.org/tuscany/tuscany-databinding-guide.html
[2]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-axiom/
[3]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-sdo/
[4]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-jaxb/
[5]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/test/java/org/apache/tuscany/sca/binding/ws/axis2/itests/HelloWorldOMTestCase.java

On 8/31/07, Giorgio Zoppi [EMAIL PROTECTED] wrote:
 Hi again,
 i saw tuscany ws binding and it fits my needs both OneWay Invocations
 and callbacks work fine. I've put some findings at
 http://g4sca.blogspot.com/ so now the next..what i've to do is bootstrap
 a node with an EmbeddedNode and use that binding. Axis2 permits some
 kind of data-mapping with JiBX( in Axis2 with the -d jibx -E parameters)
 for example, do you have a data mapping api so you can pass arbitrary
 objects to a Component? Without any data mapping there's an hack for
 doing that and it's using reflection inside a component and pass a byte
 array with the class serialized. Any suggestions?


 Cheers,
 Jo.

 P.S. Sca remote binding simply hangs, I've not still discovered the
 reason, but i'm sure that next week when i'll have a more deep
 understanding of ws binding and something working with it..I'll see that
 code. The only thing that i've seen is that i do a request to the
 ServiceDiscovery Servlet for every request, a caching (o keep-alive)
 mechanism would be more useful: every node should be have a partial view
 of the domain.



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

Re: Notes on ws-binding

On 8/31/07, ant elder [EMAIL PROTECTED] wrote:

Tuscany has a data binding framework so that most data bindings could be
supported, but there has to be a Tuscany databinding extension written for
each data binding and there's no JiBX one yet, would be really cool if
someone could help write one...interested in helping? There's a bit of
documentation on this at [1] and some examples from the existing
databinding
extensions at [2], [3], [4].

Until that happens one thing you could do is just use Axiom OMElements for
the service parameters and do all the conversion to/from XML to JiBX
objects
yourself within the component impl. There's one of the Tuscany tests that
shows working with OMElements at [5]

...ant

[1] http://incubator.apache.org/tuscany/tuscany-databinding-guide.html
[2]

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-axiom/
[3]

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-sdo/
[4]

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-jaxb/
[5]

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/test/java/org/apache/tuscany/sca/binding/ws/axis2/itests/HelloWorldOMTestCase.java

On 8/31/07, Giorgio Zoppi [EMAIL PROTECTED] wrote:
Hi again,
i saw tuscany ws binding and it fits my needs both OneWay Invocations
and callbacks work fine. I've put some findings at
http://g4sca.blogspot.com/ so now the next..what i've to do is bootstrap
a node with an EmbeddedNode and use that binding. Axis2 permits some
kind of data-mapping with JiBX( in Axis2 with the -d jibx -E parameters)
for example, do you have a data mapping api so you can pass arbitrary
objects to a Component? Without any data mapping there's an hack for
doing that and it's using reflection inside a component and pass a byte
array with the class serialized. Any suggestions?

Cheers,
Jo.

P.S. Sca remote binding simply hangs, I've not still discovered the
reason, but i'm sure that next week when i'll have a more deep
understanding of ws binding and something working with it..I'll see that
code. The only thing that i've seen is that i do a request to the
ServiceDiscovery Servlet for every request, a caching (o keep-alive)
mechanism would be more useful: every node should be have a partial view
of the domain.

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

Hi Jo

I don't have anything to add to Ants response re. databindings but following
up on the P.S. comments

It's a bit worrying that the remote sca binding hangs for you. Under the
covers it's using the web service binding that you say is working ok so it
must be something to do with the code that goes and looks up endpoints in
the registry. Which version of Tuscany are you running against.

On the second point about repeated requests to ServiceDiscovery. The
Axis2SCAReferenceBindingProvider does some simple caching to prevent
repeated lookup so maybe what you are seeing is an indicator that something
is going wrong. We should get a new binding provider instance for each
component reference so if you are calling down a number of different
references you will see repeated reads. I haven't added caching (and cache
clearing) function to the ServiceDiscovery interface yet as I wanted to keep
it simple in this first instance but if your scenario needs it let's
discuss what we should do.

Regards

Simon

Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks


Simon Nash wrote:
I think it would be good to step back from details of which characters 
are

usable in URIs and look at the bigger picture.


Right :)


The major question we have
to decide is whether the pseudo-services used by callbacks are to be 
treated

from the user's perspective
 a. exactly like SCA services in every respect


+1

 b. exactly like SCA services except for a very small number of 
differences
 c. as a different thing from an SCA service with its own set of rules 
for

how it is used

By treating these exactly like SCA services, I mean doing the following
things with them:
 1. Specifying as a target of a reference wire
 2. Specifying a callback interface and binding in addition to a forward
interface and binding
 3. Creating a ServiceReference that can be passed to setCallback()
 4. Creating a ServiceReference that can be used for normal forward
invocations
 5. Mapping to an endpoint URI using the standard algorithm defined in
the SCA assembly spec
 6. Enforcing name uniqueness rules with respect to other services
 7. Including in the calculation of whether a component only has a single
service so that its default URI need not include the service name
 8. Automatically creating an exposed endpoint on a configured host 
server

There could be other aspects that I have overlooked.  Please send your
additions to this list.


+1 for 1 through 8

I'm assuming that this is symmetric and that a callback on a service 
will work like a reference.


The reference representing the callback will have its target endpoint 
configured at the time a request is received with the endpoint of the 
originator of the request. The ability to configure the endpoint of a 
reference at run-time is actually a core function of service references, 
not specific to callbacks. Although, the Java SCA API does not expose 
that capability yet, the BPEL programming model does, for regular 
references as well.


Conclusion:
- service/callback works like a regular reference
- reference/callback works like a regular service



As a simple solution I'd like to propose that a callback reference 
defines

an SCA service with the same name as the reference, and that this service
can be used exactly like an SCA service except for points 1 and 2 above,
which are explicitly precluded by the SCA assembly spec.  This callback
service would support all the other points on the list above and any 
other

properties of SCA services that I may have overlooked in the above list.

The soundbite version is: Callbacks are full SCA services that can't be
wired and can't themselves have callbacks.


+1 that looks like a clean and simple design to me, I also like the fact 
that the service is named exactly like the callback reference.




Any thoughts or comments on this, or other suggestions?

  Simon

Simon Nash wrote:

See inline.

  Simon

Jean-Sebastien Delfino wrote:

(cut)


The # symbol has a special meaning in URIs as it separates a URI 
from a fragment id. This form of URI will prevent bindings to use 
fragment ids to identify the target operation or to append some 
context to the URI for example.


RFC 2396 [1], section 4.1 clearly states this:
When a URI reference is used to perform a retrieval action on the
identified resource, the optional fragment identifier, separated from
the URI by a crosshatch (#) character, consists of additional
reference information to be interpreted *BY THE USER AGENT* after the
retrieval action has been successfully completed.  As such, *IT IS NOT
PART OF A URI*, but is often used in conjunction with a URI.

So I don't think that using '#' is a good idea. It may work with 
some bindings, will break others.


[1] http://www.ietf.org/rfc/rfc2396.txt



Thanks for explaining the issues with #.  There were other questions
in my last post concerning the use of / as the separator.  Since you
didn't comment on these, I'm assuming that I have correctly captured
the scenario that causes you concerns with this.

The reference to RFC2396 is extremely helpful and provides (I think)
the necessary information to come up with a good solution to your
challenge.  From this document, we have a few options for the
separator character.

Option 1: Use semicolon (;).  In section 3.3 of RFC 2394 this is defined
as delimiting a parameter or parameters that are part of a path
component.  It seems quite appropriate to use a ;callback suffix in
the last path segment of a URI to represent a callback parameter.

Option 2: Use any character that's legal within a path component but
not legal in an NCName (used for SCA service and reference names).
The possible characters are
  path segment characters in section 3.3:
: | @ |  | = | + | $ | ,
  unreserved characters in section 2.3:
! | ~ | * | ' | ( | )
I don't have a strong preference here, but : and @ look good to
me, with ! as a possible alternative.

With any of these approaches, some kind of callback suffix appears
explicitly in the URI, rather than

Re: Rationalizing SCA Domain implementations

On 8/31/07, Raymond Feng [EMAIL PROTECTED] wrote:

 Hi,

 Comments inline.

 Thanks,
 Raymond

 - Original Message -
 From: Simon Laws [EMAIL PROTECTED]
 To: tuscany-dev tuscany-dev@ws.apache.org
 Sent: Thursday, August 30, 2007 9:13 AM
 Subject: Rationalizing SCA Domain implementations


  We now have a number of domain implementations in Tuscany Java SCA
  including
 
  - The SCADomain interface
  - DefaultSCADomain
  - EmbeddedSCADomain
  - HotUpdatableSCADomain
  - DistributedDomain/Node
 
  Covering a number of scenarios
 
  - running a domain in a single node
  - running a domain across multiple nodes
  - Adding, removing, updating the contributions of a domain through the
 API
  and automatically
  - Activating/deactivating, starting/stopping deployable composites
 through
  the API
  - Starting, stopping components through the API
  - Locating service in the domain through the API
  etc.
 
  There are some scenarios that we don't cover at the moment
 
  - running multiple domains in a VM

 Why does one JVM want to join multiple SCA domains? IMHO, it might be
 over-engineered.


I think this depends on the answers to you second point.

 What else?
 
  I would like to propose that we rationalize these various
 implementations
  down to a more manageable number. I have a simple model in my mind of
 the
  building blocks we have to deal with.
 
  1/ The node.
Is responsible for running segregated domains in a VM
Associated with zero or more domains.

 I think we probably miss another layer here, the 'partition's in the same
 node. In a typical server hosting environment such as Tomcat or Geronimo,
 applications are isolated by address spaces (such as ClassLoader for java
 classes). The list of deployable composites coming from the same address
 space will form a partition. With this layer, we can better embed Tuscany
 to
 the various hosting environment and provide the flexibility for dynamic
 updates.

 With this in mind, the node will have an aggregate view of all the
 partitions within the node.


Can you say some more about what a  partition is in the context of SCA?

Asking the question in a different way, what is the implication of having
multiple partitions in the same domain? Is this like having separate nodes
but with more efficient cross node comms mechaninsm, i.e. within the same
JVM?

 2/ The domain.
Logically knows about all of the artifacts of a domain.
Associated with one or more (in the distributed case) nodes.
A local representation of the domain (the SCADomain object) provides
 the
  interface to wider domain
 
  There are some subtleties here about the timing of associating a domain
  with
  a node(s) but the simple case, which we implement at the moment,
  is if you start a domain, start a node, associate the two together and
  then
  add contributions. The contributed components run on the node with which
  the local domain object is associated (more complex node/component
  selection
  algorithms can be imagined but we don't do this at present).
 
  Here are some suggestions based on the interfaces from the list of
  existing
  domain classes above, of the kind of things we need to be able to do;
 
  Domain
   Create/destroy the domain based on its URI
 Act of creating a domain object with a globally unique URI means that
  it
  becomes part of that domain and can scope comonent invocations in
 the context of that domain.
 There should be a default hot update location if we want to maintain
  that feature.
   Contribution management
 Add/remove contributions
   Resulting composites/components sit ready to be started
   Composite Management
 Start/stop  composite
   Akin to adding a composite to the domain composite and activating
 it
   Not sure how we identify a composite to be activated - by composite
  name? Currently it's done with a reference to the composite object
 Do we need to expose separate activation operations?
   Component Management
 Start/stop component
 Add.Remove listener
   Not sure how the listener from the current interface is going to be
  used
 getComponentInfo
 There are some existng related component management interfaces here
  also
   LocateService
   public abstract B, R extends CallableReferenceB R cast(B
 target)
   public abstract B B getService(ClassB businessInterface, String
  serviceName);
  service name - component name / service name
   public abstract B ServiceReferenceB
 getServiceReference(ClassB
  businessInterface, String referenceName);
 
   We also need the domain to provide some systematic interfaces to
 support
  distributed operation, for example,
 
   ServiceDiscovery
   register/find service endpoint
 
  Node
   Create/destroy the node based on its URI
   Add/remove an association with a domain
   start/stop a nodes activity
 
  Currently we have an approach, with the EmbeddedSCADomain, where the
 class
  vends a series of

[jira] Resolved: (TUSCANY-1641) @Destroy method not called for CompositeScope

2007-08-31 Thread Raymond Feng (JIRA)


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

Raymond Feng resolved TUSCANY-1641.
---

Resolution: Fixed

Patch applied under r571516. Thank you for the fix.

 @Destroy method not called for CompositeScope
 -

 Key: TUSCANY-1641
 URL: https://issues.apache.org/jira/browse/TUSCANY-1641
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
 Environment: Linux
 Tuscany SVN revision 571406
Reporter: Mark Combellack
Assignee: Raymond Feng
 Fix For: Java-SCA-1.0

 Attachments: DestroyForCompositeScope.patch


 If you define a method on a class with Composite Scope, the @Destroy method 
 is not called when the SCA Domain is closed.
 The flow of events is:
 DefaultSCADomain.close()
  - For Each CompositeActivator
 - CompositeActivatorImpl.stop()
 - If instance of ScopedRuntimeComponent then
- compositeScopeContainer.stop()
 The problem is in the CompositeScopeContainer.stop() method:
 public synchronized void stop() {
 super.stop();
 wrapper = null;
 }
 The stop method just nulls the reference to the wrapper. However, if wrapper 
 != null then it should call wrapper.stop().
 The wrapper is actually an instance of ReflectiveInstanceWrapper which is 
 responsible for calling the @Start and @Destroy annotated methods when 
 wrapper.start() and wrapper.stop() are called.
 The final code for the CompositeScopeContainer.stop() method would be 
 something like:
 public synchronized void stop() {
 super.stop();
 if (wrapper != null) {
 try {
 wrapper.stop();
 } catch (TargetDestructionException ex) {
 // TODO: Handle this exception better
 ex.printStackTrace();
 }
 }
 wrapper = null;
 }

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


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

[jira] Assigned: (TUSCANY-1641) @Destroy method not called for CompositeScope

2007-08-31 Thread Raymond Feng (JIRA)


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

Raymond Feng reassigned TUSCANY-1641:
-

Assignee: Raymond Feng

 @Destroy method not called for CompositeScope
 -

 Key: TUSCANY-1641
 URL: https://issues.apache.org/jira/browse/TUSCANY-1641
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
 Environment: Linux
 Tuscany SVN revision 571406
Reporter: Mark Combellack
Assignee: Raymond Feng
 Fix For: Java-SCA-1.0

 Attachments: DestroyForCompositeScope.patch


 If you define a method on a class with Composite Scope, the @Destroy method 
 is not called when the SCA Domain is closed.
 The flow of events is:
 DefaultSCADomain.close()
  - For Each CompositeActivator
 - CompositeActivatorImpl.stop()
 - If instance of ScopedRuntimeComponent then
- compositeScopeContainer.stop()
 The problem is in the CompositeScopeContainer.stop() method:
 public synchronized void stop() {
 super.stop();
 wrapper = null;
 }
 The stop method just nulls the reference to the wrapper. However, if wrapper 
 != null then it should call wrapper.stop().
 The wrapper is actually an instance of ReflectiveInstanceWrapper which is 
 responsible for calling the @Start and @Destroy annotated methods when 
 wrapper.start() and wrapper.stop() are called.
 The final code for the CompositeScopeContainer.stop() method would be 
 something like:
 public synchronized void stop() {
 super.stop();
 if (wrapper != null) {
 try {
 wrapper.stop();
 } catch (TargetDestructionException ex) {
 // TODO: Handle this exception better
 ex.printStackTrace();
 }
 }
 wrapper = null;
 }

-- 
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: Rationalizing SCA Domain implementations


Hi,

Comments inline.

Thanks,
Raymond

- Original Message - 
From: Simon Laws [EMAIL PROTECTED]

To: tuscany-dev tuscany-dev@ws.apache.org
Sent: Thursday, August 30, 2007 9:13 AM
Subject: Rationalizing SCA Domain implementations


We now have a number of domain implementations in Tuscany Java SCA 
including


- The SCADomain interface
- DefaultSCADomain
- EmbeddedSCADomain
- HotUpdatableSCADomain
- DistributedDomain/Node

Covering a number of scenarios

- running a domain in a single node
- running a domain across multiple nodes
- Adding, removing, updating the contributions of a domain through the API
and automatically
- Activating/deactivating, starting/stopping deployable composites through
the API
- Starting, stopping components through the API
- Locating service in the domain through the API
etc.

There are some scenarios that we don't cover at the moment

- running multiple domains in a VM


Why does one JVM want to join multiple SCA domains? IMHO, it might be 
over-engineered.



What else?

I would like to propose that we rationalize these various implementations
down to a more manageable number. I have a simple model in my mind of the
building blocks we have to deal with.

1/ The node.
  Is responsible for running segregated domains in a VM
  Associated with zero or more domains.


I think we probably miss another layer here, the 'partition's in the same 
node. In a typical server hosting environment such as Tomcat or Geronimo, 
applications are isolated by address spaces (such as ClassLoader for java 
classes). The list of deployable composites coming from the same address 
space will form a partition. With this layer, we can better embed Tuscany to 
the various hosting environment and provide the flexibility for dynamic 
updates.


With this in mind, the node will have an aggregate view of all the 
partitions within the node.



2/ The domain.
  Logically knows about all of the artifacts of a domain.
  Associated with one or more (in the distributed case) nodes.
  A local representation of the domain (the SCADomain object) provides the
interface to wider domain

There are some subtleties here about the timing of associating a domain 
with

a node(s) but the simple case, which we implement at the moment,
is if you start a domain, start a node, associate the two together and 
then

add contributions. The contributed components run on the node with which
the local domain object is associated (more complex node/component 
selection

algorithms can be imagined but we don't do this at present).

Here are some suggestions based on the interfaces from the list of 
existing

domain classes above, of the kind of things we need to be able to do;

Domain
 Create/destroy the domain based on its URI
   Act of creating a domain object with a globally unique URI means that 
it

becomes part of that domain and can scope comonent invocations in
   the context of that domain.
   There should be a default hot update location if we want to maintain
that feature.
 Contribution management
   Add/remove contributions
 Resulting composites/components sit ready to be started
 Composite Management
   Start/stop  composite
 Akin to adding a composite to the domain composite and activating it
 Not sure how we identify a composite to be activated - by composite
name? Currently it's done with a reference to the composite object
   Do we need to expose separate activation operations?
 Component Management
   Start/stop component
   Add.Remove listener
 Not sure how the listener from the current interface is going to be
used
   getComponentInfo
   There are some existng related component management interfaces here 
also

 LocateService
 public abstract B, R extends CallableReferenceB R cast(B target)
 public abstract B B getService(ClassB businessInterface, String
serviceName);
service name - component name / service name
 public abstract B ServiceReferenceB getServiceReference(ClassB
businessInterface, String referenceName);

 We also need the domain to provide some systematic interfaces to support
distributed operation, for example,

 ServiceDiscovery
 register/find service endpoint

Node
 Create/destroy the node based on its URI
 Add/remove an association with a domain
 start/stop a nodes activity

Currently we have an approach, with the EmbeddedSCADomain, where the class
vends a series of management interfaces, contribution, model building etc.
for performing actions on the domain. This is useful as it allows
flexibility in how these management actions are implemented without 
changing

all
of the domain implementation. It would also be appropriate, in the future,
to expose some of these interfaces as services to allow for remote
management of the
domain at a node.

Would welcome thoughts about this generally. Also specifically do we need 
to

maintain the detailed interfaces provided with EmbeddedSCADomain alongside
this.

Regards

Simon

[jira] Commented: (TUSCANY-1642) SCAWSDL2Java cannot handle spaces in the path on Windows


[ 
https://issues.apache.org/jira/browse/TUSCANY-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524141
 ] 

Sean Zhou commented on TUSCANY-1642:


If I move the WSDL document to a path without spaces and change the 
targetDirectory to a path without spaces, it will work perfectly.

 SCAWSDL2Java cannot handle spaces in the path on Windows
 

 Key: TUSCANY-1642
 URL: https://issues.apache.org/jira/browse/TUSCANY-1642
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SCA-1.0
 Environment: Windows
Reporter: Sean Zhou

 SCAWSDL2Java.bat -targetDirectory C:/Documents and 
 Settings/Administrator/runtime-New_configuration2/AAA/src -javaPackage 
 com.addressbook -generateSDO /C:/Documents and 
 Settings/Administrator/runtime-New_configuration2/AAA/AddressBook.wsdl
 It will receive java.io.FileNotFoundException

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


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

[jira] Created: (TUSCANY-1642) SCAWSDL2Java cannot handle spaces in the path on Windows

SCAWSDL2Java cannot handle spaces in the path on Windows


 Key: TUSCANY-1642
 URL: https://issues.apache.org/jira/browse/TUSCANY-1642
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SCA-1.0
 Environment: Windows
Reporter: Sean Zhou


SCAWSDL2Java.bat -targetDirectory C:/Documents and 
Settings/Administrator/runtime-New_configuration2/AAA/src -javaPackage 
com.addressbook -generateSDO /C:/Documents and 
Settings/Administrator/runtime-New_configuration2/AAA/AddressBook.wsdl

It will receive java.io.FileNotFoundException

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


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

[jira] Created: (TUSCANY-1643) Tutorial for ApacheCon 2007 - Services Definition

2007-08-31 Thread Mario Antollini (JIRA)

Tutorial for ApacheCon 2007 - Services Definition
-

 Key: TUSCANY-1643
 URL: https://issues.apache.org/jira/browse/TUSCANY-1643
 Project: Tuscany
  Issue Type: Task
  Components: Java SCA Samples
Reporter: Mario Antollini
Priority: Minor


A draft definition of the services (Java interfaces so far) to be provided by 
the shopping store sample to be presented at ApacheCon 2007

-- 
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-1642) WSDL2Java cannot handle spaces in the path on Windows


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

Sean Zhou updated TUSCANY-1642:
---

Description: 
WSDL2Java.bat -targetDirectory C:/Documents and 
Settings/Administrator/runtime-New_configuration2/AAA/src -javaPackage 
com.addressbook -generateSDO /C:/Documents and 
Settings/Administrator/runtime-New_configuration2/AAA/AddressBook.wsdl

It will receive java.io.FileNotFoundException

  was:
SCAWSDL2Java.bat -targetDirectory C:/Documents and 
Settings/Administrator/runtime-New_configuration2/AAA/src -javaPackage 
com.addressbook -generateSDO /C:/Documents and 
Settings/Administrator/runtime-New_configuration2/AAA/AddressBook.wsdl

It will receive java.io.FileNotFoundException

Summary: WSDL2Java cannot handle spaces in the path on Windows  (was: 
SCAWSDL2Java cannot handle spaces in the path on Windows)

 WSDL2Java cannot handle spaces in the path on Windows
 -

 Key: TUSCANY-1642
 URL: https://issues.apache.org/jira/browse/TUSCANY-1642
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SCA-1.0
 Environment: Windows
Reporter: Sean Zhou

 WSDL2Java.bat -targetDirectory C:/Documents and 
 Settings/Administrator/runtime-New_configuration2/AAA/src -javaPackage 
 com.addressbook -generateSDO /C:/Documents and 
 Settings/Administrator/runtime-New_configuration2/AAA/AddressBook.wsdl
 It will receive java.io.FileNotFoundException

-- 
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-1643) Tutorial for ApacheCon 2007 - Services Definition

2007-08-31 Thread Mario Antollini (JIRA)


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

Mario Antollini updated TUSCANY-1643:
-

Attachment: shoppingstore-v1.zip

This zip file contains the first version of the definition of the services and 
their operations

 Tutorial for ApacheCon 2007 - Services Definition
 -

 Key: TUSCANY-1643
 URL: https://issues.apache.org/jira/browse/TUSCANY-1643
 Project: Tuscany
  Issue Type: Task
  Components: Java SCA Samples
Reporter: Mario Antollini
Priority: Minor
 Attachments: shoppingstore-v1.zip


 A draft definition of the services (Java interfaces so far) to be provided by 
 the shopping store sample to be presented at ApacheCon 2007

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

Wrapper style test in WSDL processing?

There is a test to determine whether a WSDL operation follows the wrapped
style in accordance with JAX-WS 2.0 spec.  See WSDLOperationIntrospectorImpl
(
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
)

The code is currently

public boolean isWrapperStyle() throws InvalidWSDLException {
if (wrapperStyle == null) {
wrapperStyle =
wrapper.getInputChildElements() != null  (
operation.getOutput() == null || wrapper
.getOutputChildElements() != null);
}
return wrapperStyle;
}

Which doesn't seem to cater for the case where there may be no input
parameters. I'm diving into this code now to see if I can work out what it
means but if anyone has any insight I would appreciate it.

Needless to say I have a scenario where I am trying to auto generate WSDL
for a method with the signature

String myMethod()

And it's complaining that it's not wrapped.

Simon

[jira] Created: (TUSCANY-1644) WSDL2Java doesn't accept remote WSDL URL

WSDL2Java doesn't accept remote WSDL URL


 Key: TUSCANY-1644
 URL: https://issues.apache.org/jira/browse/TUSCANY-1644
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SCA-1.0
 Environment: Windows
Reporter: Sean Zhou
 Fix For: Java-SCA-1.0


For example, the following command line will not work:

D:\TuscanyWSDL2Java.bat http://www.webservicex.net/WeatherForecast.asmx?WSDL

-- 
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: Generating Eclipse WTP Web Projects for our Webapp samples

2007-08-31 Thread Ole Ersoy


That's extremely cool!  Thanks for the tip Jean Sebastien,
- Ole



Jean-Sebastien Delfino wrote:

Hi all,

I just thought I'd share this as I found it pretty useful when working 
with our Webapp samples.


If you're using Eclipse WTP and want to get WTP Web Projects generated 
for our Webapp samples you can simply pass a -Dwtpversion=1.5 option to 
the usual mvn eclipse:eclipse command, like this:

mvn -Dwtpversion=1.5 -Peclipse eclipse:eclipse

The magic -Dwtpversion=1.5 option will add the WTP Web project nature to 
all the Eclipse projects with packagingwar/packaging in their Maven 
pom.xml. You'll then be able to add these projects to a WTP Tomcat or 
Geronimo Server configuration, to publish and run them straight from 
your Eclipse workspace.


Hope this helps.



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

Re: Notes on ws-binding

2007-08-31 Thread Giorgio Zoppi

Ok. I'll try it again debugging in my lan this night.
Cheers,
Giorgio.

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

[jira] Commented: (TUSCANY-544) WSDL2Java should support WSDLs with schema imports

2007-08-31 Thread Scott Kurz (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524150
 ] 

Scott Kurz commented on TUSCANY-544:


In my experience (admittedly not on the absolute latest version of the code), 
it's not importing XSD per-se which is the problem.   

In my experience, there are three issues with the WSDL/XSD pair here...  

1) failed to put a targetNamespace on the schema element in WSDL types
2) You do an import into the same TNS as the WSDL TNS... the SDO-based 
WSDL2Java tooling assumes you are going to do an include if you're referencing 
an external XSD with the same TNS.   The XSD2Java code I believe has the same 
restriction.  

But the BasicProfile says the style Sean pasted is legal.. and in fact 
wsgen.bat will generate using this type of pattern in my experience.

3) Your element and types use the same QName.  

I don't know which standard defines the behavior here...


--

So hopefuilly this clears up and narrows down where the problems lies a bit.  
(not that I'm adding any code with these comments ;)  

 WSDL2Java should support WSDLs with schema imports
 --

 Key: TUSCANY-544
 URL: https://issues.apache.org/jira/browse/TUSCANY-544
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SCA-M2
Reporter: Ron Gavlin
Assignee: Luciano Resende
 Fix For: Java-SCA-Next


 Many WSDLs choose to import schemas rather than embedding types inline. The 
 tuscany WSDL2JavaGenerator does not currently support this type of usage.

-- 
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-1562) Service method's throws Exception clause create problem at time of on fly generation of wsdl


[ 
https://issues.apache.org/jira/browse/TUSCANY-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524151
 ] 

Simon Nash commented on TUSCANY-1562:
-

This problem occurs when specifying an exception on the service interface with 
a full Java exception class name of the form java.lang.* or javax.*.

The axis2 java2wsdl generator (used for both static and dynamic generation of 
wsdl) has special code for these two package prefixes that does not work 
correctly.  It maps all classes in these packages to xs:anyType instead of a 
complex type.  The code that generates wsdl:message and wsdl:part elements is 
only called for complex types, so the wsdl:portType contains a wsdl:fault 
element that refers to a non-existent wsdl:message.

AXIS-2672 seems to be the same problem, though the description is sketchy.  
This is marked as targeted for the 1.4 release.

I don't know how a Tucsany user can work around this.  If the WSDL is generated 
statically, it could be fixed up by hand.  If it is generated dynamically, I 
don't see any solution.

 Service method's throws Exception clause create problem at time of on fly 
 generation of wsdl
 --

 Key: TUSCANY-1562
 URL: https://issues.apache.org/jira/browse/TUSCANY-1562
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.99, Java-SCA-Next
 Environment: Windows XP, tuscany-sca-1.0-incubating-SNAPSHOT, 
 Eclipse, Tomcat 6, maven
Reporter: Nishant Joshi
 Fix For: Java-SCA-1.0

 Attachments: Example(Using axis2_1.3-RC2).wsdl, Example.zip, 
 localhost.2007-08-24.log


 Hi, I am creating a simple programme in which when i declared throws clause 
 in my method, following error is occured, when i try to deploy my war file in 
 to Tomcat. WAR is generated using maven.
 I have also tried using custom Exception but result is same.
  Now when i have catch the exception in service method then 
 problem is solved and wsdl is generated.(so now there is no throws clause).
 So in sort problem is defining throws clause in service method create problem.
 Note: Following error is in localhost.log file of Tomcat 6.0 at time of 
 starting of Tomcat.I am using Nightly build SNAPSHOT that i have mentioned in 
 environment.
 SEVERE: exception initializing SCADomain
 org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.core.runtime.ActivationException: 
 java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts 
 for fault message : {http://example.com}Exception
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82)
   at 
 org.apache.tuscany.sca.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63)
   at 
 org.apache.tuscany.sca.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:37)
   at 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3827)
   at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4334)
   at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
   at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
   at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
   at 
 org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
   at 
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
   at 
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
   at 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
   at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
   at 
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
   at 
 org.apache.catalina.core.StandardService.start(StandardService.java:516)
   at 
 org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)

Re: Monitoring, logging and exceptions (again)


[snip]
Simon Laws wrote:



Ok, so we know there is no generally acceptable logging interface. Has


been proved time and time again. All we can hope to do is use something that
suits us and doesn't mess up anyone who wants to embed our code.

I'm perfectly happy to +1 JDK logging. However without some wrappers to do
it for us we need to define the ground rules for how we use it.

So, in line with what I believe is common practice, how about these...

End user readable information  is expected to be recorded against the
following levels
SEVERE
WARNING
INFO
CONFIG

The following levels are tracing levels and are assumed to be developer
readable only
FINE
FINER
FINEST
  


+1 from me


Loggers will be initialized against the class name to which they relate, and
a resource bundle for the package/or module.
  


How about leaving the resource-bundle part out for 1.0 and do a pass to 
externalize messages later?



private static final Logger Log = Logger.getLogger(
SomeTuscanyClassB.class.getName(), tuscany-?-messages);

We can define some global o.a.t.s loggers if we don't want to have to make
bundles for all of the non-extension modules, e.g.

private static final Logger Log = Logger.getLogger(org.apache.tuscany.sca,
tuscany-messages);
  


Hmm, wouldn't that require changes in the module containing the global 
module when an extension wants to change a message?



Log statements for user readable messages will take the following form, for
example,

Log.log(Level.INFO,
  MESSAGE1);

String componentName = Some component;

Log.log(Level.INFO,
  MESSAGE2, // message id
  componentName); // parameter

Integer params[] = {8, 9, 4};

Log.log(Level.INFO,
  MESSAGE3, // message id
  params);// parameter


Exception ex = new IllegalStateException(TEST_MESSAGE);

Log.log(Level.INFO,
  MESSAGE4, // message id
  ex);// parameter


These messages will be localized against a message bundle from the classpath
based on the configuration of the Logger (or the Logger's parent), for
example, tuscany-messages.properties, tuscany-messages_en.properties etc.

MESSAGE1 = This is a test message with no params
MESSAGE2 = This is a test message with a string param {0}
MESSAGE3 = This is a test message with numbers {0}, {1}, {2}
MESSAGE4 = This is a test message with exception
  


+1 for all that, except that again I'll be more comfortable to leave 
externalization to later after 1.0.



Which can of course be provided on an extension by extension basis if
required and if specified when the logger is created.

Developer readable messages are assumed not to be localized and so can be
output using the Logger convenience methods.

We won't use log.entering and log exiting. This level of tracing will be
provided via AspectJ injection.
  


+1


I'm assuming we don't want our logging properties to have to live in
jdk/lib/logging properties so we need an extensible/replaceable way to
initialize logging. e.g.

InputStream logConfigStream = Thread.currentThread
().getContextClassLoader().getResourceAsStream(tuscany-logging.properties
);
LogManager.getLogManager().readConfiguration(logConfigStream);
+ any other logging configuration that we need

Anyone have a good idea where to put this. It should go close to the start
of our domain/node implementation but would be good if it's replaceable. So
we could do with a new logging extension type that is one of the first
things that gets loaded.

Simon
  


What would be put in specific logging properties?


--
Jean-Sebastien


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

Re: Wrapper style test in WSDL processing?


Hi,

The operation.getInput() cannot be null to qualify for the wrapper style. 
There must be a part in the input message corresponding to the operation 
name:


input
   --- message
   --- part (only one part)
   --- element (the element name should be the same as the 
operation name)


The element should look like this:

element name=myMethod
   complexType
   sequence/ !-- an empty sequence --
   /complexType
/element

Thanks,
Raymond

- Original Message - 
From: Simon Laws [EMAIL PROTECTED]

To: tuscany-dev tuscany-dev@ws.apache.org
Sent: Friday, August 31, 2007 10:34 AM
Subject: Wrapper style test in WSDL processing?


There is a test to determine whether a WSDL operation follows the 
wrapped
style in accordance with JAX-WS 2.0 spec.  See 
WSDLOperationIntrospectorImpl

(
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
)

The code is currently

   public boolean isWrapperStyle() throws InvalidWSDLException {
   if (wrapperStyle == null) {
   wrapperStyle =
   wrapper.getInputChildElements() != null  (
operation.getOutput() == null || wrapper
   .getOutputChildElements() != null);
   }
   return wrapperStyle;
   }

Which doesn't seem to cater for the case where there may be no input
parameters. I'm diving into this code now to see if I can work out what it
means but if anyone has any insight I would appreciate it.

Needless to say I have a scenario where I am trying to auto generate WSDL
for a method with the signature

String myMethod()

And it's complaining that it's not wrapped.

Simon




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

Re: Wrapper style test in WSDL processing?

On 8/31/07, Raymond Feng [EMAIL PROTECTED] wrote:

 Hi,

 The operation.getInput() cannot be null to qualify for the wrapper style.
 There must be a part in the input message corresponding to the operation
 name:

 input
 --- message
 --- part (only one part)
 --- element (the element name should be the same as the
 operation name)

 The element should look like this:

 element name=myMethod
 complexType
 sequence/ !-- an empty sequence --
 /complexType
 /element

 Thanks,
 Raymond

 - Original Message -
 From: Simon Laws [EMAIL PROTECTED]
 To: tuscany-dev tuscany-dev@ws.apache.org
 Sent: Friday, August 31, 2007 10:34 AM
 Subject: Wrapper style test in WSDL processing?


  There is a test to determine whether a WSDL operation follows the
  wrapped
  style in accordance with JAX-WS 2.0 spec.  See
  WSDLOperationIntrospectorImpl
  (
 
 http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
  )
 
  The code is currently
 
 public boolean isWrapperStyle() throws InvalidWSDLException {
 if (wrapperStyle == null) {
 wrapperStyle =
 wrapper.getInputChildElements() != null  (
  operation.getOutput() == null || wrapper
 .getOutputChildElements() != null);
 }
 return wrapperStyle;
 }
 
  Which doesn't seem to cater for the case where there may be no input
  parameters. I'm diving into this code now to see if I can work out what
 it
  means but if anyone has any insight I would appreciate it.
 
  Needless to say I have a scenario where I am trying to auto generate
 WSDL
  for a method with the signature
 
  String myMethod()
 
  And it's complaining that it's not wrapped.
 
  Simon
 


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

 What you are saying sounds right to me, I.e. you can validly have no
parameters in your method but in this case it should build an empty sequence


element name=myMethod
complexType
sequence/ !-- an empty sequence --
/complexType
/element

And have this as the single input type. I'm deeper into the code now looking
for why this isn't the case.

Thanks Raymond

Simon

Re: Monitoring, logging and exceptions (again)

On 8/31/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 [snip]
 Simon Laws wrote:
 
  Ok, so we know there is no generally acceptable logging interface. Has
 
  been proved time and time again. All we can hope to do is use something
 that
  suits us and doesn't mess up anyone who wants to embed our code.
 
  I'm perfectly happy to +1 JDK logging. However without some wrappers to
 do
  it for us we need to define the ground rules for how we use it.
 
  So, in line with what I believe is common practice, how about these...
 
  End user readable information  is expected to be recorded against the
  following levels
  SEVERE
  WARNING
  INFO
  CONFIG
 
  The following levels are tracing levels and are assumed to be developer
  readable only
  FINE
  FINER
  FINEST
 

 +1 from me

  Loggers will be initialized against the class name to which they relate,
 and
  a resource bundle for the package/or module.
 

 How about leaving the resource-bundle part out for 1.0 and do a pass to
 externalize messages later?


I don't think it's a particularly big job putting in resource bundles but
I'll go with the majority decision if people are concerned about getting  if
done in time.  We will have to do it at some stage.

 private static final Logger Log = Logger.getLogger(
  SomeTuscanyClassB.class.getName(), tuscany-?-messages);
 
  We can define some global o.a.t.s loggers if we don't want to have to
 make
  bundles for all of the non-extension modules, e.g.
 
  private static final Logger Log = Logger.getLogger(
 org.apache.tuscany.sca,
  tuscany-messages);
 

 Hmm, wouldn't that require changes in the module containing the global
 module when an extension wants to change a message?


Only if you don;t specify a bundle for the extension . So the rule shoyuld
be you always provide an bundle for an extension. I was just making the
point that we don't absolutely need a bundle for each modules unless it's
loaded as an extension. However it may be simpler just to say 1 per module
and then it's easier to remember.

 Log statements for user readable messages will take the following form,
 for
  example,
 
  Log.log(Level.INFO,
MESSAGE1);
 
  String componentName = Some component;
 
  Log.log(Level.INFO,
MESSAGE2, // message id
componentName); // parameter
 
  Integer params[] = {8, 9, 4};
 
  Log.log(Level.INFO,
MESSAGE3, // message id
params);// parameter
 
 
  Exception ex = new IllegalStateException(TEST_MESSAGE);
 
  Log.log(Level.INFO,
MESSAGE4, // message id
ex);// parameter
 
 
  These messages will be localized against a message bundle from the
 classpath
  based on the configuration of the Logger (or the Logger's parent), for
  example, tuscany-messages.properties, tuscany-messages_en.properties
 etc.
 
  MESSAGE1 = This is a test message with no params
  MESSAGE2 = This is a test message with a string param {0}
  MESSAGE3 = This is a test message with numbers {0}, {1}, {2}
  MESSAGE4 = This is a test message with exception
 

 +1 for all that, except that again I'll be more comfortable to leave
 externalization to later after 1.0.


Ok , well  let's see what people think.  As you say not hugely difficult to
go round and hoover up all the messages and convert into bundles.

 Which can of course be provided on an extension by extension basis if
  required and if specified when the logger is created.
 
  Developer readable messages are assumed not to be localized and so can
 be
  output using the Logger convenience methods.
 
  We won't use log.entering and log exiting. This level of tracing will be
  provided via AspectJ injection.
 

 +1

  I'm assuming we don't want our logging properties to have to live in
  jdk/lib/logging properties so we need an extensible/replaceable way to
  initialize logging. e.g.
 
  InputStream logConfigStream = Thread.currentThread
  ().getContextClassLoader().getResourceAsStream(
 tuscany-logging.properties
  );
  LogManager.getLogManager
 ().readConfiguration(logConfigStream);
  + any other logging configuration that we need
 
  Anyone have a good idea where to put this. It should go close to the
 start
  of our domain/node implementation but would be good if it's replaceable.
 So
  we could do with a new logging extension type that is one of the first
  things that gets loaded.
 
  Simon
 

 What would be put in specific logging properties?


The usual logging configuration, what we want our default logging level to
be on a module by module bases, what handlers to use, configuration of the
handlers e.g. if it's a file handler where to put the file and what to call
it. etc.

I'm using the IBM JDK and that doesn't seem to come with a default

Re: [jira] Updated: (TUSCANY-1500) Many callback tests don't run


Hi,

I applied the patch4 with the following changes:

1) Remove ImplementationProvider2 and use RuntimeWireProcessorExtensionPoint 
instead to add the interceptor
2) Keep the CallableReference to the Message instead of a flag for the 
callback object
3) Use InterfaceContractMapper to test if the source implementation 
implements the callback interface


Thanks,
Raymond

- Original Message - 
From: Simon Nash (JIRA) tuscany-dev@ws.apache.org

To: tuscany-dev@ws.apache.org
Sent: Thursday, August 30, 2007 1:26 AM
Subject: [jira] Updated: (TUSCANY-1500) Many callback tests don't run




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


Simon Nash updated TUSCANY-1500:


   Attachment: patch4

Here is patch4 for this JIRA. It completes the work needed to get the 
callback-set-callback test fully working, as well as doing some minor 
cleanup on the test case.  In the core runtime it adds the check for 
NoRegisteredCallbackException as required by section 1.6.7.5 of the Java 
Common Annotations and APIs spec.


In addition to the changes in this patch, the following new file (also 
attached to this JIRA) must be added:



sca\modules\core-spi\src\main\java\org\apache\tuscany\sca\provider\ImplementationProvider2.java

I am looking at the other failing callback tests and I will post further 
patches to get them working.




Many callback tests don't run
-

Key: TUSCANY-1500
URL: https://issues.apache.org/jira/browse/TUSCANY-1500
Project: Tuscany
 Issue Type: Bug
 Components: Java SCA Core Runtime
   Affects Versions: Java-SCA-Next
Environment: Windows XP
   Reporter: Simon Nash
   Assignee: Simon Nash
Fix For: Java-SCA-1.0

Attachments: ImplementationProvider2.java, patch1, patch2, 
patch3, patch4



The following itests are currently disabled in the build.  If they are 
enabled by changing the name of the test class from xxxTest to 
xxxTestCase, they fail with various errors.

  callback-api
  callback-complex-type
  callback-id
  callback-set-callback
  callback-set-conversation


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




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

Re: Rationalizing SCA Domain implementations

In the same JVM, we now use a singleton object to keep all the metadata for 
the deployable composites running on the node. This has been proven to be 
problematic, especially in the case of Tomcat or Geronimo integration where 
applications are running in isolated address spaces. The partition is the 
portion of SCA domain visible to a given address space and its lifecycle is 
the same as an Web/JEE application (or some other modules).


Then we have the following hierarchy:

SCA domain (accross multiple nodes on the network)
   --- SCA node (I assume one node per JVM and one JVM per node)
   --- SCA partition (I assume one partition per address space in the 
JVM)


Thanks,
Raymond

- Original Message - 
From: Simon Laws [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Friday, August 31, 2007 9:46 AM
Subject: Re: Rationalizing SCA Domain implementations



On 8/31/07, Raymond Feng [EMAIL PROTECTED] wrote:


Hi,

Comments inline.

Thanks,
Raymond

- Original Message -
From: Simon Laws [EMAIL PROTECTED]
To: tuscany-dev tuscany-dev@ws.apache.org
Sent: Thursday, August 30, 2007 9:13 AM
Subject: Rationalizing SCA Domain implementations


 We now have a number of domain implementations in Tuscany Java SCA
 including

 - The SCADomain interface
 - DefaultSCADomain
 - EmbeddedSCADomain
 - HotUpdatableSCADomain
 - DistributedDomain/Node

 Covering a number of scenarios

 - running a domain in a single node
 - running a domain across multiple nodes
 - Adding, removing, updating the contributions of a domain through the
API
 and automatically
 - Activating/deactivating, starting/stopping deployable composites
through
 the API
 - Starting, stopping components through the API
 - Locating service in the domain through the API
 etc.

 There are some scenarios that we don't cover at the moment

 - running multiple domains in a VM

Why does one JVM want to join multiple SCA domains? IMHO, it might be
over-engineered.



I think this depends on the answers to you second point.


What else?

 I would like to propose that we rationalize these various
implementations
 down to a more manageable number. I have a simple model in my mind of
the
 building blocks we have to deal with.

 1/ The node.
   Is responsible for running segregated domains in a VM
   Associated with zero or more domains.

I think we probably miss another layer here, the 'partition's in the same
node. In a typical server hosting environment such as Tomcat or Geronimo,
applications are isolated by address spaces (such as ClassLoader for java
classes). The list of deployable composites coming from the same address
space will form a partition. With this layer, we can better embed Tuscany
to
the various hosting environment and provide the flexibility for dynamic
updates.

With this in mind, the node will have an aggregate view of all the
partitions within the node.



Can you say some more about what a  partition is in the context of SCA?

Asking the question in a different way, what is the implication of having
multiple partitions in the same domain? Is this like having separate 
nodes

but with more efficient cross node comms mechaninsm, i.e. within the same
JVM?


2/ The domain.
   Logically knows about all of the artifacts of a domain.
   Associated with one or more (in the distributed case) nodes.
   A local representation of the domain (the SCADomain object) provides
the
 interface to wider domain

 There are some subtleties here about the timing of associating a domain
 with
 a node(s) but the simple case, which we implement at the moment,
 is if you start a domain, start a node, associate the two together and
 then
 add contributions. The contributed components run on the node with 
 which

 the local domain object is associated (more complex node/component
 selection
 algorithms can be imagined but we don't do this at present).

 Here are some suggestions based on the interfaces from the list of
 existing
 domain classes above, of the kind of things we need to be able to do;

 Domain
  Create/destroy the domain based on its URI
Act of creating a domain object with a globally unique URI means 
 that

 it
 becomes part of that domain and can scope comonent invocations in
the context of that domain.
There should be a default hot update location if we want to maintain
 that feature.
  Contribution management
Add/remove contributions
  Resulting composites/components sit ready to be started
  Composite Management
Start/stop  composite
  Akin to adding a composite to the domain composite and activating
it
  Not sure how we identify a composite to be activated - by 
 composite

 name? Currently it's done with a reference to the composite object
Do we need to expose separate activation operations?
  Component Management
Start/stop component
Add.Remove listener
  Not sure how the listener from the current interface is going to 
 be

 used
getComponentInfo
There are some existng

Services definition for tutorial @ ApacheCon

2007-08-31 Thread Antollini, Mario

JS, Ant and Raymond,

 

I have uploaded the first version of the services the sample application
will provide (to my understanding)

 

One remark: I needed to provide an operation to start the checkout
process (to take part when the items in the cart are going to be bought
by the client/user). Therefore, even though it may not be the most
appropriate place to put it, I added a checkout operation within the
CartService. I did so because I wanted to keep the set of services as
simple as possible. However, I could still add a new service in charge
of providing the checkout functionality.

 

Any feedback will be welcome.

 

Regards,

 

Mario E. Antollini
Intel Software
ASDC
+54 351 414 5594
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]

[jira] Created: (TUSCANY-1645) XSD2JavaGenerator failed to gen on the wsdl files with only xsd:import element in xsd:schema

2007-08-31 Thread Fuhwei Lwo (JIRA)

XSD2JavaGenerator failed to gen on the wsdl files with only xsd:import 
element in xsd:schema


 Key: TUSCANY-1645
 URL: https://issues.apache.org/jira/browse/TUSCANY-1645
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
 Environment: WinXP
Reporter: Fuhwei Lwo
 Fix For: Java-SDO-Next
 Attachments: EchoService_schema1.xsd, TUSCANY-544.wsdl

NullPointerException was thrown when a WSDL with XSD definition like below was 
used by the XSD2JavaGenerator. In this case, there is no targetNamespace was 
specified in the xsd:schema

types
xsd:schema
  xsd:import namespace=http://test/; 
schemaLocation=EchoService_schema1.xsd/
/xsd:schema
  /types

This problem was derived from SCA JIRA TUSCANY-544 and related to SDO JIRA 
TUSCANY-1327.

-- 
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-1645) XSD2JavaGenerator failed to gen on the wsdl files with only xsd:import element in xsd:schema

2007-08-31 Thread Fuhwei Lwo (JIRA)


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

Fuhwei Lwo updated TUSCANY-1645:


Attachment: EchoService_schema1.xsd
TUSCANY-544.wsdl

 XSD2JavaGenerator failed to gen on the wsdl files with only xsd:import 
 element in xsd:schema
 

 Key: TUSCANY-1645
 URL: https://issues.apache.org/jira/browse/TUSCANY-1645
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
 Environment: WinXP
Reporter: Fuhwei Lwo
 Fix For: Java-SDO-Next

 Attachments: EchoService_schema1.xsd, TUSCANY-544.wsdl


 NullPointerException was thrown when a WSDL with XSD definition like below 
 was used by the XSD2JavaGenerator. In this case, there is no targetNamespace 
 was specified in the xsd:schema
 types
 xsd:schema
   xsd:import namespace=http://test/; 
 schemaLocation=EchoService_schema1.xsd/
 /xsd:schema
   /types
 This problem was derived from SCA JIRA TUSCANY-544 and related to SDO JIRA 
 TUSCANY-1327.

-- 
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: Monitoring, logging and exceptions (again)


Simon Laws wrote:



What would be put in specific logging properties?




The usual logging configuration, what we want our default logging level to
be on a module by module bases, what handlers to use, configuration of the
handlers e.g. if it's a file handler where to put the file and what to call
it. etc.

I'm using the IBM JDK and that doesn't seem to come with a default
logging.properties file. We could go with hardcoded defaults but as soon as
you want to change something it's problematic. We could ask people to drop
one into jdk/lib but that would be active for any other java apps they use.

Do you know an easy way round this?

  


I don't know an easy way around this, but I'm still a little confused. 
If we define a tuscany-logging properties file then what's going to 
happen when we do:

LogManager.getLogManager().readConfiguration(stream for 
tuscany-logging.properties);
Isn't that going to reset the logging configuration for the whole 
LogManager, altering the log configuration for other projects that use 
the JDK logger as well?


--
Jean-Sebastien


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

RE: Services definition for tutorial @ ApacheCon

2007-08-31 Thread Antollini, Mario

I forgot to add where you can find the code:
https://issues.apache.org/jira/browse/TUSCANY-1643

-Original Message-
From: Antollini, Mario [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 31, 2007 4:25 PM
To: tuscany-dev@ws.apache.org
Subject: Services definition for tutorial @ ApacheCon

JS, Ant and Raymond,

I have uploaded the first version of the services the sample application
will provide (to my understanding)

One remark: I needed to provide an operation to start the checkout
process (to take part when the items in the cart are going to be bought
by the client/user). Therefore, even though it may not be the most
appropriate place to put it, I added a checkout operation within the
CartService. I did so because I wanted to keep the set of services as
simple as possible. However, I could still add a new service in charge
of providing the checkout functionality.

Any feedback will be welcome.

Regards,

Mario E. Antollini
Intel Software
ASDC
+54 351 414 5594
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 

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

[jira] Resolved: (TUSCANY-544) WSDL2Java should support WSDLs with schema imports

2007-08-31 Thread Luciano Resende (JIRA)


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

Luciano Resende resolved TUSCANY-544.
-

Resolution: Cannot Reproduce

In general, WSDL2Java is supporting WSDLs with schema imports. There are 
special scenarios that might have bugs, as the one mentioned by Sean Zhou, but 
I'd recommend using specific JIRA for the specific scenarios. In the case of 
Sean Zhou scenario, looks like FuhWei opened TUSCANY-1645 and he is taking care 
of the issue in the XSD2JavaGenerator code.

 WSDL2Java should support WSDLs with schema imports
 --

 Key: TUSCANY-544
 URL: https://issues.apache.org/jira/browse/TUSCANY-544
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SCA-M2
Reporter: Ron Gavlin
Assignee: Luciano Resende
 Fix For: Java-SCA-Next


 Many WSDLs choose to import schemas rather than embedding types inline. The 
 tuscany WSDL2JavaGenerator does not currently support this type of usage.

-- 
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-1636) There should not be an SCABinding created under reference if there is no target on the reference 558780


[ 
https://issues.apache.org/jira/browse/TUSCANY-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524179
 ] 

Jean-Sebastien Delfino commented on TUSCANY-1636:
-

Raymond is correct, it is valid to have a binding with no target, as 
implementations should be able to wire the reference later, dynamically (this 
is not exposed by the Java SCA API at this point but is allowed by the SCA BPEL 
programming model for example).

Can the SCA binding code just test for a null URI?

Also, what did u mean by there is a null object set to the reference, which 
will override existing reference value in the component?

 There should not be an SCABinding created under reference if there is no 
 target on the reference 558780
 ---

 Key: TUSCANY-1636
 URL: https://issues.apache.org/jira/browse/TUSCANY-1636
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Reporter: Yang Lei

 In CompositeBuilderImpl, we create defeault SCABinding where there is no 
 binding defined under reference. This will break the SCABinding handling if 
 the reference does not have a target, then SCABinding willl still get 
 executed so either there is a NPE as we are not expecting target is not 
 there, or there is a null object set to the reference, which will override 
 existing reference value in the component. 
 I did the following to remove the SCABinding at the end of the 
 CompositeBuilderImpl.connectComponentReferences, the else block
 if (!targets.isEmpty()) {
   
 }else
 {
 // need to remove the SCABinding we created that did not have 
 target
 if (componentReference.getBindings().size()==1)
 {
 SCABinding binding = 
 componentReference.getBinding(SCABinding.class);
 if (binding!=null  binding.getURI()==null)
 {
 componentReference.getBindings().clear();
 }
 }
 }
 }

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

Picture on the Tuscany website SCA Java page


The picture on http://incubator.apache.org/tuscany/sca-java.html doesn't
look quite right to me.  It seems to show a node that is split between
two domains.  I think an SCA node is part of exactly one domain.  It's
possible for more than one domain to run in a single JVM, but from an
architectural perspective these domains would each instantiate a separate
node within the same JVM and would not be part of the same node.

  Simon



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

Re: Picture on the Tuscany website SCA Java page

What's the use case to have one JVM joining multiple SCA domains (even 
theoretically it's possible)? I agree with Simon that one node should only 
belong to one SCA domain but it seems that he also hinted that one JVM can 
host more than one node.


Thanks,
Raymond

- Original Message - 
From: Simon Nash [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Friday, August 31, 2007 1:20 PM
Subject: Picture on the Tuscany website SCA Java page



The picture on http://incubator.apache.org/tuscany/sca-java.html doesn't
look quite right to me.  It seems to show a node that is split between
two domains.  I think an SCA node is part of exactly one domain.  It's
possible for more than one domain to run in a single JVM, but from an
architectural perspective these domains would each instantiate a separate
node within the same JVM and would not be part of the same node.

  Simon



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




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

[jira] Updated: (TUSCANY-1642) WSDL2Java cannot handle spaces in the path on Windows


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

Jean-Sebastien Delfino updated TUSCANY-1642:


Fix Version/s: Java-SCA-1.0

 WSDL2Java cannot handle spaces in the path on Windows
 -

 Key: TUSCANY-1642
 URL: https://issues.apache.org/jira/browse/TUSCANY-1642
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SCA-1.0
 Environment: Windows
Reporter: Sean Zhou
 Fix For: Java-SCA-1.0


 WSDL2Java.bat -targetDirectory C:/Documents and 
 Settings/Administrator/runtime-New_configuration2/AAA/src -javaPackage 
 com.addressbook -generateSDO /C:/Documents and 
 Settings/Administrator/runtime-New_configuration2/AAA/AddressBook.wsdl
 It will receive java.io.FileNotFoundException

-- 
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: Monitoring, logging and exceptions (again)

On 8/31/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 Simon Laws wrote:
 
  What would be put in specific logging properties?
 
 
 
  The usual logging configuration, what we want our default logging level
 to
  be on a module by module bases, what handlers to use, configuration of
 the
  handlers e.g. if it's a file handler where to put the file and what to
 call
  it. etc.
 
  I'm using the IBM JDK and that doesn't seem to come with a default
  logging.properties file. We could go with hardcoded defaults but as soon
 as
  you want to change something it's problematic. We could ask people to
 drop
  one into jdk/lib but that would be active for any other java apps they
 use.
 
  Do you know an easy way round this?
 
 

 I don't know an easy way around this, but I'm still a little confused.
 If we define a tuscany-logging properties file then what's going to
 happen when we do:
  LogManager.getLogManager().readConfiguration(stream for
 tuscany-logging.properties);
 Isn't that going to reset the logging configuration for the whole
 LogManager, altering the log configuration for other projects that use
 the JDK logger as well?

 --
 Jean-Sebastien


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

 Yes , say if we embed tuscany in some other project and we were to read
the logging.properties file as above we would mess up the settings of the
embedding application. Thats why we have to be able to remove any
configuration we provide, for example, for our samples.

Simon

[jira] Updated: (TUSCANY-1645) XSD2JavaGenerator failed to gen on the wsdl files with only xsd:import element in xsd:schema

2007-08-31 Thread Fuhwei Lwo (JIRA)


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

Fuhwei Lwo updated TUSCANY-1645:


Attachment: 1645.patch

The NPE was caused by trying to codegen on null XSD namesapce. The SDO codegen 
tool needs the XSD target namespace to generate the static SDO APIs. In this 
case, since there is no targetNamespace specified in the xsd:schema, 
getSchemaNamespace() method in the XSD2JavaGenerator returns null and causes 
NPE.

My patch is to further check whether there is any XSD import I can use. If 
there is one, return its namespace for the codegen starting point.

I don't think this solution is sufficient because I think it's possible to have 
multiple imports as codegen starting points. By looking at the current 
implementation we have, it only allows single codegen starting point then 
codegen on its dependencies. This means if I have 2 imports and they are not 
related, the second import won't be gened.

Let me know if I am on the right track. Thanks.

 XSD2JavaGenerator failed to gen on the wsdl files with only xsd:import 
 element in xsd:schema
 

 Key: TUSCANY-1645
 URL: https://issues.apache.org/jira/browse/TUSCANY-1645
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
 Environment: WinXP
Reporter: Fuhwei Lwo
 Fix For: Java-SDO-Next

 Attachments: 1645.patch, EchoService_schema1.xsd, TUSCANY-544.wsdl


 NullPointerException was thrown when a WSDL with XSD definition like below 
 was used by the XSD2JavaGenerator. In this case, there is no targetNamespace 
 was specified in the xsd:schema
 types
 xsd:schema
   xsd:import namespace=http://test/; 
 schemaLocation=EchoService_schema1.xsd/
 /xsd:schema
   /types
 This problem was derived from SCA JIRA TUSCANY-544 and related to SDO JIRA 
 TUSCANY-1327.

-- 
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-1562) Service method's throws Exception clause create problem at time of on fly generation of wsdl


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

Simon Nash updated TUSCANY-1562:


Attachment: jira1562.zip

I'm attaching an itest that demonstrates this problem.  It can be unzipped 
under sca/itest and run from there with mvn.  It does not use a webapp.

 Service method's throws Exception clause create problem at time of on fly 
 generation of wsdl
 --

 Key: TUSCANY-1562
 URL: https://issues.apache.org/jira/browse/TUSCANY-1562
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.99, Java-SCA-Next
 Environment: Windows XP, tuscany-sca-1.0-incubating-SNAPSHOT, 
 Eclipse, Tomcat 6, maven
Reporter: Nishant Joshi
 Fix For: Java-SCA-1.0

 Attachments: Example(Using axis2_1.3-RC2).wsdl, Example.zip, 
 localhost.2007-08-24.log


 Hi, I am creating a simple programme in which when i declared throws clause 
 in my method, following error is occured, when i try to deploy my war file in 
 to Tomcat. WAR is generated using maven.
 I have also tried using custom Exception but result is same.
  Now when i have catch the exception in service method then 
 problem is solved and wsdl is generated.(so now there is no throws clause).
 So in sort problem is defining throws clause in service method create problem.
 Note: Following error is in localhost.log file of Tomcat 6.0 at time of 
 starting of Tomcat.I am using Nightly build SNAPSHOT that i have mentioned in 
 environment.
 SEVERE: exception initializing SCADomain
 org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.core.runtime.ActivationException: 
 java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts 
 for fault message : {http://example.com}Exception
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82)
   at 
 org.apache.tuscany.sca.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63)
   at 
 org.apache.tuscany.sca.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:37)
   at 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3827)
   at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4334)
   at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
   at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
   at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
   at 
 org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
   at 
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
   at 
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
   at 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
   at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
   at 
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
   at 
 org.apache.catalina.core.StandardService.start(StandardService.java:516)
   at 
 org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
 Caused by: org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.core.runtime.ActivationException: 
 java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts 
 for fault message : {http://example.com}Exception
   at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:169)
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
   ... 27 more
 Caused by: org.apache.tuscany.sca.core.runtime.ActivationException: 
 java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts 
 for

[jira] Updated: (TUSCANY-1562) Service method's throws Exception clause create problem at time of on fly generation of wsdl


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

Simon Nash updated TUSCANY-1562:


Attachment: (was: jira1562.zip)

 Service method's throws Exception clause create problem at time of on fly 
 generation of wsdl
 --

 Key: TUSCANY-1562
 URL: https://issues.apache.org/jira/browse/TUSCANY-1562
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.99, Java-SCA-Next
 Environment: Windows XP, tuscany-sca-1.0-incubating-SNAPSHOT, 
 Eclipse, Tomcat 6, maven
Reporter: Nishant Joshi
 Fix For: Java-SCA-1.0

 Attachments: Example(Using axis2_1.3-RC2).wsdl, Example.zip, 
 localhost.2007-08-24.log


 Hi, I am creating a simple programme in which when i declared throws clause 
 in my method, following error is occured, when i try to deploy my war file in 
 to Tomcat. WAR is generated using maven.
 I have also tried using custom Exception but result is same.
  Now when i have catch the exception in service method then 
 problem is solved and wsdl is generated.(so now there is no throws clause).
 So in sort problem is defining throws clause in service method create problem.
 Note: Following error is in localhost.log file of Tomcat 6.0 at time of 
 starting of Tomcat.I am using Nightly build SNAPSHOT that i have mentioned in 
 environment.
 SEVERE: exception initializing SCADomain
 org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.core.runtime.ActivationException: 
 java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts 
 for fault message : {http://example.com}Exception
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82)
   at 
 org.apache.tuscany.sca.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63)
   at 
 org.apache.tuscany.sca.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:37)
   at 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3827)
   at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4334)
   at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
   at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
   at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
   at 
 org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
   at 
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
   at 
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
   at 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
   at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
   at 
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
   at 
 org.apache.catalina.core.StandardService.start(StandardService.java:516)
   at 
 org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
 Caused by: org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.core.runtime.ActivationException: 
 java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts 
 for fault message : {http://example.com}Exception
   at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:169)
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
   ... 27 more
 Caused by: org.apache.tuscany.sca.core.runtime.ActivationException: 
 java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts 
 for fault message : {http://example.com}Exception
   at

Re: [jira] Updated: (TUSCANY-1500) Many callback tests don't run


Thanks very much Raymond, and thanks for the improvements to my patch.

I have one minor comment on the changes.  In CallbackInterfaceInterceptor
the invoke() method is as follows:

public Message invoke(Message msg) {
CallableReference? callableReference = msg.getCallableReference();
if (callableReference instanceof ServiceReference) {
if (((ServiceReference?)callableReference).getCallback() == null) 
{
throw new NoRegisteredCallbackException(Callback target does not 
implement the callback interface);
}
}
return next.invoke(msg);
}

If the callableReference is not an instance of ServiceReference, then it
does not have a callback object and so I would expect the exception to
be thrown.  Something like:

public Message invoke(Message msg) {
CallableReference? callableReference = msg.getCallableReference();
if (callableReference instanceof ServiceReference 
((ServiceReference?)callableReference).getCallback() != null) {
return next.invoke(msg);
} else {
throw new NoRegisteredCallbackException(Callback target does not 
implement the callback interface);
}
}

  Simon

Raymond Feng wrote:


Hi,

I applied the patch4 with the following changes:

1) Remove ImplementationProvider2 and use 
RuntimeWireProcessorExtensionPoint instead to add the interceptor
2) Keep the CallableReference to the Message instead of a flag for the 
callback object
3) Use InterfaceContractMapper to test if the source implementation 
implements the callback interface


Thanks,
Raymond

- Original Message - From: Simon Nash (JIRA) 
tuscany-dev@ws.apache.org

To: tuscany-dev@ws.apache.org
Sent: Thursday, August 30, 2007 1:26 AM
Subject: [jira] Updated: (TUSCANY-1500) Many callback tests don't run




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


Simon Nash updated TUSCANY-1500:


   Attachment: patch4

Here is patch4 for this JIRA. It completes the work needed to get the 
callback-set-callback test fully working, as well as doing some minor 
cleanup on the test case.  In the core runtime it adds the check for 
NoRegisteredCallbackException as required by section 1.6.7.5 of the 
Java Common Annotations and APIs spec.


In addition to the changes in this patch, the following new file (also 
attached to this JIRA) must be added:



sca\modules\core-spi\src\main\java\org\apache\tuscany\sca\provider\ImplementationProvider2.java 



I am looking at the other failing callback tests and I will post 
further patches to get them working.




Many callback tests don't run
-

Key: TUSCANY-1500
URL: https://issues.apache.org/jira/browse/TUSCANY-1500
Project: Tuscany
 Issue Type: Bug
 Components: Java SCA Core Runtime
   Affects Versions: Java-SCA-Next
Environment: Windows XP
   Reporter: Simon Nash
   Assignee: Simon Nash
Fix For: Java-SCA-1.0

Attachments: ImplementationProvider2.java, patch1, patch2, 
patch3, patch4



The following itests are currently disabled in the build.  If they 
are enabled by changing the name of the test class from xxxTest to 
xxxTestCase, they fail with various errors.

  callback-api
  callback-complex-type
  callback-id
  callback-set-callback
  callback-set-conversation



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





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

[jira] Updated: (TUSCANY-1633) To support reference target for SCA Binding using URI on r558780


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

Jean-Sebastien Delfino updated TUSCANY-1633:


Fix Version/s: Java-SCA-1.0

 To support reference target  for SCA Binding using URI on r558780
 ---

 Key: TUSCANY-1633
 URL: https://issues.apache.org/jira/browse/TUSCANY-1633
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
 Environment: Windows
Reporter: Yang Lei
 Fix For: Java-SCA-1.0


 We assume we can use SCA binding 's URI for its target service. We see the 
 following problems:
 1. When there is a SCABinding element under the reference or we are trying to 
 create one when there is none, the URI is not set. So added  a else block to 
 the following code in CompositeBuilderImpl,matchBinding method:
 if (binding instanceof WireableBinding) { 
  .
 } else {
 //use terget serviceBinding's URI as referece's 
 binding URI
 //This is to support reference target
 if (cloned instanceof SCABinding  cloned.getURI() 
 == null) {
 cloned.setURI(serviceBinding.getURI());
 }
 }
 2. When there is a SCABinding element defined on service side, URI is not set 
 we need to add the else block:
 // Create and configure an SCA binding for the service
 if (componentService.getBindings().isEmpty()) {
 SCABinding scaBinding = 
 componentService.getBinding(SCABinding.class);
 if (scaBinding == null) {
 scaBinding = scaBindingFactory.createSCABinding();
 scaBinding.setName(componentService.getName());
 componentService.getBindings().add(scaBinding);
 }
 scaBinding.setComponent(component);
 scaBinding.setURI(uri);
  }else
  {
 SCABinding scaBinding = 
 componentService.getBinding(SCABinding.class);
 if (scaBinding != null  scaBinding.getURI()==null) {
 scaBinding.setURI(uri);
 }
  }

-- 
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-1562) Service method's throws Exception clause create problem at time of on fly generation of wsdl


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

Simon Nash updated TUSCANY-1562:


Attachment: jira1562.zip

Second attempt at attaching the itest: the first was deleted because of a 
problem with it.

 Service method's throws Exception clause create problem at time of on fly 
 generation of wsdl
 --

 Key: TUSCANY-1562
 URL: https://issues.apache.org/jira/browse/TUSCANY-1562
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.99, Java-SCA-Next
 Environment: Windows XP, tuscany-sca-1.0-incubating-SNAPSHOT, 
 Eclipse, Tomcat 6, maven
Reporter: Nishant Joshi
 Fix For: Java-SCA-1.0

 Attachments: Example(Using axis2_1.3-RC2).wsdl, Example.zip, 
 jira1562.zip, localhost.2007-08-24.log


 Hi, I am creating a simple programme in which when i declared throws clause 
 in my method, following error is occured, when i try to deploy my war file in 
 to Tomcat. WAR is generated using maven.
 I have also tried using custom Exception but result is same.
  Now when i have catch the exception in service method then 
 problem is solved and wsdl is generated.(so now there is no throws clause).
 So in sort problem is defining throws clause in service method create problem.
 Note: Following error is in localhost.log file of Tomcat 6.0 at time of 
 starting of Tomcat.I am using Nightly build SNAPSHOT that i have mentioned in 
 environment.
 SEVERE: exception initializing SCADomain
 org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.core.runtime.ActivationException: 
 java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts 
 for fault message : {http://example.com}Exception
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82)
   at 
 org.apache.tuscany.sca.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63)
   at 
 org.apache.tuscany.sca.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:37)
   at 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3827)
   at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4334)
   at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
   at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
   at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
   at 
 org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
   at 
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
   at 
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
   at 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
   at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
   at 
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
   at 
 org.apache.catalina.core.StandardService.start(StandardService.java:516)
   at 
 org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
 Caused by: org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.core.runtime.ActivationException: 
 java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts 
 for fault message : {http://example.com}Exception
   at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:169)
   at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
   ... 27 more
 Caused by: org.apache.tuscany.sca.core.runtime.ActivationException: 
 java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts 
 for fault message :

[jira] Commented: (TUSCANY-1645) XSD2JavaGenerator failed to gen on the wsdl files with only xsd:import element in xsd:schema

2007-08-31 Thread Luciano Resende (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524190
 ] 

Luciano Resende commented on TUSCANY-1645:
--

I have committed the wsld and xsd from TUSCANY-544 to java/sca/itest/wsdl2java 
(commented out for now). We could use that for validating the fix. I have also 
applied the patch locally and that seems to fix the issue, so please enable the 
new wsdl/xsd on the sca itest (in the pom.xml) once you committ this patch.

 XSD2JavaGenerator failed to gen on the wsdl files with only xsd:import 
 element in xsd:schema
 

 Key: TUSCANY-1645
 URL: https://issues.apache.org/jira/browse/TUSCANY-1645
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
 Environment: WinXP
Reporter: Fuhwei Lwo
 Fix For: Java-SDO-Next

 Attachments: 1645.patch, EchoService_schema1.xsd, TUSCANY-544.wsdl


 NullPointerException was thrown when a WSDL with XSD definition like below 
 was used by the XSD2JavaGenerator. In this case, there is no targetNamespace 
 was specified in the xsd:schema
 types
 xsd:schema
   xsd:import namespace=http://test/; 
 schemaLocation=EchoService_schema1.xsd/
 /xsd:schema
   /types
 This problem was derived from SCA JIRA TUSCANY-544 and related to SDO JIRA 
 TUSCANY-1327.

-- 
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] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks


See inline.

  Simon

Jean-Sebastien Delfino wrote:


Simon Nash wrote:

I think it would be good to step back from details of which characters 
are

usable in URIs and look at the bigger picture.



Right :)


The major question we have
to decide is whether the pseudo-services used by callbacks are to be 
treated

from the user's perspective
 a. exactly like SCA services in every respect



+1

 b. exactly like SCA services except for a very small number of 
differences
 c. as a different thing from an SCA service with its own set of rules 
for

how it is used

By treating these exactly like SCA services, I mean doing the following
things with them:
 1. Specifying as a target of a reference wire
 2. Specifying a callback interface and binding in addition to a forward
interface and binding
 3. Creating a ServiceReference that can be passed to setCallback()
 4. Creating a ServiceReference that can be used for normal forward
invocations
 5. Mapping to an endpoint URI using the standard algorithm defined in
the SCA assembly spec
 6. Enforcing name uniqueness rules with respect to other services
 7. Including in the calculation of whether a component only has a single
service so that its default URI need not include the service name
 8. Automatically creating an exposed endpoint on a configured host 
server

There could be other aspects that I have overlooked.  Please send your
additions to this list.



+1 for 1 through 8

I'm assuming that this is symmetric and that a callback on a service 
will work like a reference.


The reference representing the callback will have its target endpoint 
configured at the time a request is received with the endpoint of the 
originator of the request. The ability to configure the endpoint of a 
reference at run-time is actually a core function of service references, 
not specific to callbacks. Although, the Java SCA API does not expose 
that capability yet, the BPEL programming model does, for regular 
references as well.


Conclusion:
- service/callback works like a regular reference
- reference/callback works like a regular service


I am +1 with nearly all of this but I want to dig deeper into your
statement that the target endpoint of the callback is configured
at the time a request is received.  This is a tricky area and I am
part way through writing a post that goes into considerable detail
about exactly when the target endpoint should be configured in order
to correctly support various scenarios.  I'll complete this and post
it in the next day or so for review and comment.

  Simon



As a simple solution I'd like to propose that a callback reference 
defines

an SCA service with the same name as the reference, and that this service
can be used exactly like an SCA service except for points 1 and 2 above,
which are explicitly precluded by the SCA assembly spec.  This callback
service would support all the other points on the list above and any 
other

properties of SCA services that I may have overlooked in the above list.

The soundbite version is: Callbacks are full SCA services that can't be
wired and can't themselves have callbacks.



+1 that looks like a clean and simple design to me, I also like the fact 
that the service is named exactly like the callback reference.




Any thoughts or comments on this, or other suggestions?

  Simon

Simon Nash wrote:


See inline.

  Simon

Jean-Sebastien Delfino wrote:

(cut)



The # symbol has a special meaning in URIs as it separates a URI 
from a fragment id. This form of URI will prevent bindings to use 
fragment ids to identify the target operation or to append some 
context to the URI for example.


RFC 2396 [1], section 4.1 clearly states this:
When a URI reference is used to perform a retrieval action on the
identified resource, the optional fragment identifier, separated from
the URI by a crosshatch (#) character, consists of additional
reference information to be interpreted *BY THE USER AGENT* after the
retrieval action has been successfully completed.  As such, *IT IS NOT
PART OF A URI*, but is often used in conjunction with a URI.

So I don't think that using '#' is a good idea. It may work with 
some bindings, will break others.


[1] http://www.ietf.org/rfc/rfc2396.txt



Thanks for explaining the issues with #.  There were other questions
in my last post concerning the use of / as the separator.  Since you
didn't comment on these, I'm assuming that I have correctly captured
the scenario that causes you concerns with this.

The reference to RFC2396 is extremely helpful and provides (I think)
the necessary information to come up with a good solution to your
challenge.  From this document, we have a few options for the
separator character.

Option 1: Use semicolon (;).  In section 3.3 of RFC 2394 this is defined
as delimiting a parameter or parameters that are part of a path
component.  It seems quite appropriate to use a ;callback suffix in
the last path segment of a URI to represent a

Re: Picture on the Tuscany website SCA Java page



Raymond Feng wrote:

What's the use case to have one JVM joining multiple SCA domains (even 
theoretically it's possible)? I agree with Simon that one node should 
only belong to one SCA domain but it seems that he also hinted that one 
JVM can host more than one node.



We have APIs that allow this.  Just write:
  SCADomain scaDomain1 = SCADomain.newInstance(domain1.composite);
  SCADomain scaDomain2 = SCADomain.newInstance(domain2.composite);

Regarding use cases, it can be useful for testing purposes.

  Simon


Thanks,
Raymond

- Original Message - From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, August 31, 2007 1:20 PM
Subject: Picture on the Tuscany website SCA Java page



The picture on http://incubator.apache.org/tuscany/sca-java.html doesn't
look quite right to me.  It seems to show a node that is split between
two domains.  I think an SCA node is part of exactly one domain.  It's
possible for more than one domain to run in a single JVM, but from an
architectural perspective these domains would each instantiate a separate
node within the same JVM and would not be part of the same node.

  Simon







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

Re: Monitoring, logging and exceptions (again)


Simon Laws wrote:

On 8/31/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
  

Simon Laws wrote:


What would be put in specific logging properties?



The usual logging configuration, what we want our default logging level
  

to


be on a module by module bases, what handlers to use, configuration of
  

the


handlers e.g. if it's a file handler where to put the file and what to
  

call


it. etc.

I'm using the IBM JDK and that doesn't seem to come with a default
logging.properties file. We could go with hardcoded defaults but as soon
  

as


you want to change something it's problematic. We could ask people to
  

drop


one into jdk/lib but that would be active for any other java apps they
  

use.


Do you know an easy way round this?


  

I don't know an easy way around this, but I'm still a little confused.
If we define a tuscany-logging properties file then what's going to
happen when we do:


LogManager.getLogManager().readConfiguration(stream for
  

tuscany-logging.properties);
Isn't that going to reset the logging configuration for the whole
LogManager, altering the log configuration for other projects that use
the JDK logger as well?

--
Jean-Sebastien


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

Yes , say if we embed tuscany in some other project and we were to read


the logging.properties file as above we would mess up the settings of the
embedding application. Thats why we have to be able to remove any
configuration we provide, for example, for our samples.

Simon

  


How about not messing up the settings  - i.e. not impose or provide a 
configuration properties file - and let the user configure the JDK 
logger the way he wants?


Sometimes not providing anything is better than providing something 
that's going to get in the way, even if we document how to remove the 
obstacle we have created :)


--
Jean-Sebastien


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

Re: Picture on the Tuscany website SCA Java page

On 8/31/07, Raymond Feng [EMAIL PROTECTED] wrote:

 What's the use case to have one JVM joining multiple SCA domains (even
 theoretically it's possible)? I agree with Simon that one node should only
 belong to one SCA domain but it seems that he also hinted that one JVM can
 host more than one node.

 Thanks,
 Raymond

 - Original Message -
 From: Simon Nash [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Friday, August 31, 2007 1:20 PM
 Subject: Picture on the Tuscany website SCA Java page


  The picture on http://incubator.apache.org/tuscany/sca-java.html doesn't
  look quite right to me.  It seems to show a node that is split between
  two domains.  I think an SCA node is part of exactly one domain.  It's
  possible for more than one domain to run in a single JVM, but from an
  architectural perspective these domains would each instantiate a
 separate
  node within the same JVM and would not be part of the same node.
 
Simon
 
 
 
  -
  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]

 We are maybe using the term Node to mean different things.

For me a node provides runtime resources (1,2 or 3 below) to one ore more
domains. I used the word Node instead of runtime as we already use the term
runtime in the code (ReallySmallRuntime) and the runtime is currently owned
by the domain.

So the resources that a node might represent are

1 - A part of a JVM
Scenario: some application container is making runtime resources available
to our domain applications

2 - A single JVM
Scenario: a stand-alone tuscany program

3 - A collection of JVMs
Scenario: a high performance compute cluster. We may choose to run component
instances across multiple JVMs for performance reasons but the cluster is
not visible to the topology of the domain. As far is it is concerned the
cluster is one node.

This is  distinct from the distributed domain scenario we have implemented
to date where multiple nodes are used to enable the distribution of the
components in the domain.

4. Raymond has raised something else in another thread about partitions. I
will let Raymond explain that.

We also individually consider that a Node might be associated with one
domain or many domains.

The key point is what we think a node is. From Simon's comment these
domains would each instantiate a separate node within the same JVM. To make
this work there must be a mechanism within the JVM that allows domains to be
associated with the JVM. For me this is the node but I'm not hooked on this
particular term.

As for scenarios of multiple domains in a JVM.  I imagine a JVM supporting
multiple domains in the same way that an application server can support
multiple unrelated applications. This may sound a bit marginal for nodes
with resources of types 1


Simon

Re: Picture on the Tuscany website SCA Java page

On 8/31/07, Simon Laws [EMAIL PROTECTED] wrote:



 On 8/31/07, Raymond Feng [EMAIL PROTECTED] wrote:
 
  What's the use case to have one JVM joining multiple SCA domains (even
  theoretically it's possible)? I agree with Simon that one node should
  only
  belong to one SCA domain but it seems that he also hinted that one JVM
  can
  host more than one node.
 
  Thanks,
  Raymond
 
  - Original Message -
  From: Simon Nash [EMAIL PROTECTED]
  To:  tuscany-dev@ws.apache.org
  Sent: Friday, August 31, 2007 1:20 PM
  Subject: Picture on the Tuscany website SCA Java page
 
 
   The picture on http://incubator.apache.org/tuscany/sca-java.htmldoesn't
   look quite right to me.  It seems to show a node that is split between
   two domains.  I think an SCA node is part of exactly one domain.  It's
 
   possible for more than one domain to run in a single JVM, but from an
   architectural perspective these domains would each instantiate a
  separate
   node within the same JVM and would not be part of the same node.
  
 Simon
  
  
  
   -
   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]
 
  We are maybe using the term Node to mean different things.

 For me a node provides runtime resources (1,2 or 3 below) to one ore more
 domains. I used the word Node instead of runtime as we already use the term
 runtime in the code (ReallySmallRuntime) and the runtime is currently owned
 by the domain.

 So the resources that a node might represent are

 1 - A part of a JVM
 Scenario: some application container is making runtime resources available
 to our domain applications

 2 - A single JVM
 Scenario: a stand-alone tuscany program

 3 - A collection of JVMs
 Scenario: a high performance compute cluster. We may choose to run
 component instances across multiple JVMs for performance reasons but the
 cluster is not visible to the topology of the domain. As far is it is
 concerned the cluster is one node.

 This is  distinct from the distributed domain scenario we have implemented
 to date where multiple nodes are used to enable the distribution of the
 components in the domain.

 4. Raymond has raised something else in another thread about partitions.
 I will let Raymond explain that.

 We also individually consider that a Node might be associated with one
 domain or many domains.

 The key point is what we think a node is. From Simon's comment these
 domains would each instantiate a separate node within the same JVM. To make
 this work there must be a mechanism within the JVM that allows domains to be
 associated with the JVM. For me this is the node but I'm not hooked on this
 particular term.

 As for scenarios of multiple domains in a JVM.  I imagine a JVM supporting
 multiple domains in the same way that an application server can support
 multiple unrelated applications. This may sound a bit marginal for nodes
 with resources of types 1


 Simon







 Oops, pressed send too soon. I was going to finish with...

This may sound a bit marginal for nodes with resources of type 1, I thought
business as usual for type 2 and particuarly important
for nodes with resources of type 3. This is why I was using the word node
rather than JVM directly.

Simon

Re: Monitoring, logging and exceptions (again)

On 8/31/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 Simon Laws wrote:
  On 8/31/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
 
  Simon Laws wrote:
 
  What would be put in specific logging properties?
 
 
  The usual logging configuration, what we want our default logging
 level
 
  to
 
  be on a module by module bases, what handlers to use, configuration of
 
  the
 
  handlers e.g. if it's a file handler where to put the file and what to
 
  call
 
  it. etc.
 
  I'm using the IBM JDK and that doesn't seem to come with a default
  logging.properties file. We could go with hardcoded defaults but as
 soon
 
  as
 
  you want to change something it's problematic. We could ask people to
 
  drop
 
  one into jdk/lib but that would be active for any other java apps they
 
  use.
 
  Do you know an easy way round this?
 
 
 
  I don't know an easy way around this, but I'm still a little confused.
  If we define a tuscany-logging properties file then what's going to
  happen when we do:
 
  LogManager.getLogManager().readConfiguration(stream for
 
  tuscany-logging.properties);
  Isn't that going to reset the logging configuration for the whole
  LogManager, altering the log configuration for other projects that use
  the JDK logger as well?
 
  --
  Jean-Sebastien
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
  Yes , say if we embed tuscany in some other project and we were to read
 
  the logging.properties file as above we would mess up the settings of
 the
  embedding application. Thats why we have to be able to remove any
  configuration we provide, for example, for our samples.
 
  Simon
 
 

 How about not messing up the settings  - i.e. not impose or provide a
 configuration properties file - and let the user configure the JDK
 logger the way he wants?

 Sometimes not providing anything is better than providing something
 that's going to get in the way, even if we document how to remove the
 obstacle we have created :)

 --
 Jean-Sebastien


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

 I don't think we can get away with providing nothing. Even from a tuscany
developers point of view we are going to want a logging.properties file
checked into svn somewhere and probably some instructions describing what to
do with it.

We could rely on the dropping it into jdk/lib for logging during
development. Not clear that all developers will be happy with that but we
can ask.

We will have to ensure that we get what we need with the default logging
settings for the samples/demos. I could live with that but we need to try to
make sure it's ok.

Simon

[jira] Closed: (TUSCANY-1548) multi-valued properties should require indexed xpath

2007-08-31 Thread Michael Yoder (JIRA)


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

Michael Yoder closed TUSCANY-1548.
--

Resolution: Fixed

Resolved with applied patch.

 multi-valued properties should require indexed xpath
 

 Key: TUSCANY-1548
 URL: https://issues.apache.org/jira/browse/TUSCANY-1548
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-M3
 Environment: all
Reporter: Michael Yoder
 Fix For: Cpp-Next

 Attachments: TUSCANY-1548.txt


 The C++ SDO spec XPath clearly shows access to many-valued properties 
 requiring [] or dot notation to denote an index. In order to retreive a whole 
 list the SDO spec uses the getList() API to retrieve a list.
 6.1.13. The get/set API on Class DataObject
 ...
 Multi-valued properties are located by the getList API.
 Multi-valued properties accessed in an xpath without an index should be 
 invalid usage (Tuscany SDO is currently accesses the first element in the 
 list).

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

SOAP support in JMS Binding

2007-08-31 Thread Dinesh Shahane

I was experimenting with JMS binding to transport SOAP and XML messages.
Current JMS binding implementation supports Text and Object messages and
Text messages do allow carrying XML. I was thinking of extending this
binding to support SOAP messages as specified in
http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/raw/%3C80A4
[EMAIL PROTECTED]/3.
However I was not sure if it falls under Web services binding. Could someone
shed some light on this topic?

Re: Rationalizing SCA Domain implementations

On 8/31/07, Raymond Feng [EMAIL PROTECTED] wrote:

 In the same JVM, we now use a singleton object to keep all the metadata
 for
 the deployable composites running on the node. This has been proven to be
 problematic, especially in the case of Tomcat or Geronimo integration
 where
 applications are running in isolated address spaces. The partition is the
 portion of SCA domain visible to a given address space and its lifecycle
 is
 the same as an Web/JEE application (or some other modules).

 Then we have the following hierarchy:

 SCA domain (accross multiple nodes on the network)
 --- SCA node (I assume one node per JVM and one JVM per node)
 --- SCA partition (I assume one partition per address space in the
 JVM)

 Thanks,
 Raymond

 - Original Message -
 From: Simon Laws [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Friday, August 31, 2007 9:46 AM
 Subject: Re: Rationalizing SCA Domain implementations


  On 8/31/07, Raymond Feng [EMAIL PROTECTED] wrote:
 
  Hi,
 
  Comments inline.
 
  Thanks,
  Raymond
 
  - Original Message -
  From: Simon Laws [EMAIL PROTECTED]
  To: tuscany-dev tuscany-dev@ws.apache.org
  Sent: Thursday, August 30, 2007 9:13 AM
  Subject: Rationalizing SCA Domain implementations
 
 
   We now have a number of domain implementations in Tuscany Java SCA
   including
  
   - The SCADomain interface
   - DefaultSCADomain
   - EmbeddedSCADomain
   - HotUpdatableSCADomain
   - DistributedDomain/Node
  
   Covering a number of scenarios
  
   - running a domain in a single node
   - running a domain across multiple nodes
   - Adding, removing, updating the contributions of a domain through
 the
  API
   and automatically
   - Activating/deactivating, starting/stopping deployable composites
  through
   the API
   - Starting, stopping components through the API
   - Locating service in the domain through the API
   etc.
  
   There are some scenarios that we don't cover at the moment
  
   - running multiple domains in a VM
 
  Why does one JVM want to join multiple SCA domains? IMHO, it might be
  over-engineered.
 
 
  I think this depends on the answers to you second point.
 
  What else?
  
   I would like to propose that we rationalize these various
  implementations
   down to a more manageable number. I have a simple model in my mind of
  the
   building blocks we have to deal with.
  
   1/ The node.
 Is responsible for running segregated domains in a VM
 Associated with zero or more domains.
 
  I think we probably miss another layer here, the 'partition's in the
 same
  node. In a typical server hosting environment such as Tomcat or
 Geronimo,
  applications are isolated by address spaces (such as ClassLoader for
 java
  classes). The list of deployable composites coming from the same
 address
  space will form a partition. With this layer, we can better embed
 Tuscany
  to
  the various hosting environment and provide the flexibility for dynamic
  updates.
 
  With this in mind, the node will have an aggregate view of all the
  partitions within the node.
 
 
  Can you say some more about what a  partition is in the context of
 SCA?
 
  Asking the question in a different way, what is the implication of
 having
  multiple partitions in the same domain? Is this like having separate
  nodes
  but with more efficient cross node comms mechaninsm, i.e. within the
 same
  JVM?
 
  2/ The domain.
 Logically knows about all of the artifacts of a domain.
 Associated with one or more (in the distributed case) nodes.
 A local representation of the domain (the SCADomain object)
 provides
  the
   interface to wider domain
  
   There are some subtleties here about the timing of associating a
 domain
   with
   a node(s) but the simple case, which we implement at the moment,
   is if you start a domain, start a node, associate the two together
 and
   then
   add contributions. The contributed components run on the node with
   which
   the local domain object is associated (more complex node/component
   selection
   algorithms can be imagined but we don't do this at present).
  
   Here are some suggestions based on the interfaces from the list of
   existing
   domain classes above, of the kind of things we need to be able to do;
  
   Domain
Create/destroy the domain based on its URI
  Act of creating a domain object with a globally unique URI means
   that
   it
   becomes part of that domain and can scope comonent invocations in
  the context of that domain.
  There should be a default hot update location if we want to
 maintain
   that feature.
Contribution management
  Add/remove contributions
Resulting composites/components sit ready to be started
Composite Management
  Start/stop  composite
Akin to adding a composite to the domain composite and
 activating
  it
Not sure how we identify a composite to be activated - by
   composite
   name? Currently it's done with a

[jira] Resolved: (TUSCANY-1438) Change TuscanySCA Native build system to use ant

2007-08-31 Thread Brady Johnson (JIRA)


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

Brady Johnson resolved TUSCANY-1438.


Resolution: Fixed


I think enough patches have been applied to warrant resolving this issue.

Any additional issues related to the ant build system should be dealt with in 
new JIRAs.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


 Change TuscanySCA Native build system to use ant
 

 Key: TUSCANY-1438
 URL: https://issues.apache.org/jira/browse/TUSCANY-1438
 Project: Tuscany
  Issue Type: Improvement
  Components: C++ SCA
Affects Versions: Cpp-Next
 Environment: all platforms
Reporter: Brady Johnson
Priority: Minor
 Fix For: Cpp-Next

 Attachments: README_ANT_INSTALL.txt, samples.CppBigBank.build.xml, 
 tuscany_patch_update10_jira1438, tuscany_patch_update10_jira1438.corrected, 
 tuscany_patch_update2_jira1438, tuscany_patch_update3_jira1438, 
 tuscany_patch_update4_jira1438, tuscany_patch_update5_jira1438, 
 tuscany_patch_update6_jira1438, tuscany_patch_update7_jira1438, 
 tuscany_patch_update8_jira1438, tuscany_patch_update9_jira1438, 
 TuscanySCANative.ant.display.system, tuscanySCAnative_ant.tar.gz, 
 tuscanySCAnative_ant_update1.tar.gz


 In an effort to simplify the build process, I would like to propose switching 
 over to use ant instead of automake. It will be much easier to maintain, and 
 is used by many more developers today than automake.
 Per a request by Pete Robbins to show what the build scripts would look like 
 for cpp/sca/runtime/core, I will attach a patch with the build infrastructure 
 to build, link, and install said library.
 
 Brady Johnson
 Lead Software Developer - HydraSCA
 Rogue Wave Software - [EMAIL PROTECTED]

-- 
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: SOAP support in JMS Binding

On 8/31/07, Dinesh Shahane [EMAIL PROTECTED] wrote:

 I was experimenting with JMS binding to transport SOAP and XML messages.
 Current JMS binding implementation supports Text and Object messages and
 Text messages do allow carrying XML. I was thinking of extending this
 binding to support SOAP messages as specified in

 http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/raw/%3C80A4
 [EMAIL PROTECTED]/3.
 However I was not sure if it falls under Web services binding. Could
 someone
 shed some light on this topic?

 Hi Dinesh

There was some discussion about this a few weeks back [1]. As far as I know
no one  has done any work on it to date. Take a look and see what you think.
Thinking back I think the  emphasis of that discussion what providing a JMS
transport to the ws binding through various mean. I'm going to go back and
read what was said also. I don't remember if anyone talked about approaching
it from the point of view of the jms binding.

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20760.html

Boolean instead of boolean for autowire attributes


Hi,

I'm reviewing our support for autowiring and found out there is an issue 
with our Composite/Component/ComponentReference models.


By the assembly spec, there is difference between the following two cases:

a) component name=C1
b) component name=C1 autowire=false

Case a) will inherit the autowire from the containing composite while case 
b) will override the one from the composite.


In the current code, we use a boolean to represent the setting in 
Composite/Component/ComponentReference interface and it cannot reflect the 
null value. I propose that we make the following changes:


1) Change the method void setAutowire(boolean autowire) to void 
setAutowire(Boolean autowire). Thanks to the JDK5 autoboxing, this will not 
break any existing code.

2) Change the implementation of isAutowire() to default null value to false.
3) Add a new method to Boolean getAutowire() to the 
Composite/Component/ComponentReference
4) Update the CompositeProcessor and CompositeConfigurationBuilderImpl to 
read/propagate the autowire settings correctly.


I have all these changes working locally. If there's no objections, I'll 
check in the code soon.


Thanks,
Raymond 



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

[jira] Updated: (TUSCANY-1142) Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with named complexType


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

Jean-Sebastien Delfino updated TUSCANY-1142:


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

 Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with 
 named complexType 
 

 Key: TUSCANY-1142
 URL: https://issues.apache.org/jira/browse/TUSCANY-1142
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SCA-M2
Reporter: Scott Kurz
 Fix For: Java-SCA-1.0


 Our WSDL2Java tool maps the following WSDL pattern onto a non-wrapped Java 
 interface even when using doc-lit-wrapped WSDL:
 ...types
 
 complexType name=getGreetings
   sequence
 element name=name type=xsd:string/
   /sequence
 /complexType
 element name=getGreetings type=tns:getGreetings/
 ...
 /types
 I noticed that wsimport seems to unwrap this and produce:
   getGreetings(String)
 whereas our WSDL2Java treats this as non-wrapped and generates:
   getGreetings(getGreetings)
 The key line of Tuscany code is:
 org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped()
  if (typeMappingEntry.isAnonymous()) {
 wrapped = true;
 }   
 As I claim in this JIRA, TUSCANY-1019, it would be nice to ALSO have the 
 ability to generate a non-wrapped Java interface from the given WSDL pattern, 
 but we should also allow for generation of a wrapped interface (the wrapped 
 by my guess should be the default).
 Yang Zhong posted this reply in agreement to the Tuscany dev list.
 Once binding is involved within WSDL2Java, one WSDL portType/message can end
 up with multiple Java classes respective to different bindings.
 It mixes business logic and wire format :-(
 Assuming involving binding is de facto, and only one binding each WSDL
 portType/message,
 maybe we can change JavaInterfaceEmitter.isWrapped to an algorithm such as:
 1. not wrapped if the style is not document or the use is not literal
 2. not wrapped if the message has more than one parts
 3. not wrapped if the part isn't element or its local name doesn't match the
 operation local name
 4. not wrapped if the operation name isn't unique within the portType
 Yes, I agree with Scott not to take isAnonymous() into account.

-- 
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-1511) Conversational - spec funnies and other improvements


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

Jean-Sebastien Delfino updated TUSCANY-1511:


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

 Conversational - spec funnies and other improvements
 

 Key: TUSCANY-1511
 URL: https://issues.apache.org/jira/browse/TUSCANY-1511
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
 Environment: All
Reporter: Simon Laws
 Fix For: Java-SCA-1.0


 We closed http://issues.apache.org/jira/browse/TUSCANY-1377 when we got to 
 the stage where conversation support was basically back up and running. There 
 are still some outstanding issues recorded against that report that come down 
 to lack of clarity in the spec and/or are awaiting other bits of the Tuscany 
 runtime to be completed. Here is the list so far.
 Features Currently Supported
 ---
 
 @Conversational - service  callback interfaces
 @Scope(CONVERSATION)
 @Scope(STATELESS)
 @Init
 @Destroy
 @ConversationAttributes(maxAge=2 days,
maxIdleTime=5 minutes )
 @ConversationId
 @EndsConversation - service and callback interfaces
 ServiceReference
getConversationID()
setConversationID(Object)
 CallableReference (can be persisted,can be passed)
isConversational()
getConversation()
 Conversation
getConversationID()
end()
 ConversationEndedException
 Restrictions And Required Clarifications
 
 The specification is not clear on a number of points related to Stateful 
 callbacks. 
 1/ In the current implementation the spec has been interpreted to mean that 
 the client component, i.e. the component implementing the callback 
 interface, must be marked as conversational in order that callback messages 
 return to the same instance of the client component that originated the 
 conversational call.  In this case the target of a callback (the source of 
 the original message) has to be stored against a conversationId so that the 
 callback can find it and invoke the callback operation on it. Currently, at 
 the source component, the incoming conversationid is reused for outgoing 
 messages to allow this to happen (the component instance will automatically 
 have been registered against this id when it was created). 
 A better solution would be to allow the reference logic to always create a 
 new conversation id (or accept a user defined conversation id) but, for 
 stateful callbacks this implies that the source component instance has to be 
 registered against multiple conversation ids in the conversational scope 
 container. As pumbing this in is a little tricky we need discuss round 
 alternative solutions.
 2/ The spec isn't explicit about what happens at the server  when 
 Conversation.end() is used on the target service. In the current 
 implementation it will not free any resources held at the target. A protocol 
 is required between source and target to carry this end() instruction. As it 
 stands the target conversation will eventually time out. Subsequent requests 
 to the target will create a new conversation.
 3/ @EndsConversation on the target component where a stateful callback is 
 defined will end the callback conversation at the target only, I.e. the 
 component
 instance representing the conversation at the source end will remain in 
 place. It remains until the callback calls an @EndConversation annotated 
 message. This is tricky
 because the source component instance may have been created as part of 
 another conversation which hasn't ended yet. Not clear whether the intention 
 of the spec is to get both to happen at once.
 The specification also talks about the ability to pass round references that 
 refer to ongoing conversations. 
 No passing of services references, referring to conversational services, is 
 currently supported. This is primarily because the service reference is not 
 currently serializeable but
 the spec could also benefit from some clarrification in this area. For 
 example, If a callable reference is passed off to another service how does 
 that callable reference know what the state of the conversation is?
 There are also a few other pieces that are awaiting the completion of other 
 bits of work. 
 @Scope(COMPOSITE) excluded due to ML conversation 
 (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20573.html)
 @ConversationAttributes(singlePrincipal=false). Awaiting plicy/security work
 The WS binding is being targetted as the first remote binding with 
 conversation support but this is not complete

Re: Boolean instead of boolean for autowire attributes


Raymond Feng wrote:

Hi,

I'm reviewing our support for autowiring and found out there is an 
issue with our Composite/Component/ComponentReference models.


By the assembly spec, there is difference between the following two 
cases:


a) component name=C1
b) component name=C1 autowire=false

Case a) will inherit the autowire from the containing composite while 
case b) will override the one from the composite.


In the current code, we use a boolean to represent the setting in 
Composite/Component/ComponentReference interface and it cannot reflect 
the null value. I propose that we make the following changes:


1) Change the method void setAutowire(boolean autowire) to void 
setAutowire(Boolean autowire). Thanks to the JDK5 autoboxing, this 
will not break any existing code.
2) Change the implementation of isAutowire() to default null value to 
false.
3) Add a new method to Boolean getAutowire() to the 
Composite/Component/ComponentReference
4) Update the CompositeProcessor and CompositeConfigurationBuilderImpl 
to read/propagate the autowire settings correctly.


I have all these changes working locally. If there's no objections, 
I'll check in the code soon.


Thanks,
Raymond



+1, would be good to also @deprecate isAutowire then.

Are there any other boolean attributes in the model deserving a similar 
treatment?


--
Jean-Sebastien


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

[jira] Created: (TUSCANY-1646) Web Service binding doesn't handle wsdli:wsdlLocation

Web Service binding doesn't handle wsdli:wsdlLocation
-

 Key: TUSCANY-1646
 URL: https://issues.apache.org/jira/browse/TUSCANY-1646
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-0.99
Reporter: Jean-Sebastien Delfino
 Fix For: Java-SCA-1.0


According to the Web Service binding spec, it should be possible to specify the 
location of the WSDL file used to configure a Web Service binding.

Our WebServiceBindingProcessor is able to read that location but later ignores 
it and does not use it to get the the WSDL file. 


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


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

[jira] Created: (TUSCANY-1647) Web Service binding doesn't handle SOAP1/2 policy intent

Web Service binding doesn't handle SOAP1/2 policy intent


 Key: TUSCANY-1647
 URL: https://issues.apache.org/jira/browse/TUSCANY-1647
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding Extension
Reporter: Jean-Sebastien Delfino
 Fix For: Java-SCA-1.0


The Web Service binding should use SOAP 1.2 when configured with a soap/1.2 
policy intent, as described in section 2.3.1 of the SCA WebService binding spec.


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


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

[jira] Created: (TUSCANY-1648) WS Binding WSDL generation should follow the rules in section 2.3.5 of the WS binding spec

WS Binding WSDL generation should follow the rules in section 2.3.5 of the WS 
binding spec
--

 Key: TUSCANY-1648
 URL: https://issues.apache.org/jira/browse/TUSCANY-1648
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-0.99
Reporter: Jean-Sebastien Delfino
 Fix For: Java-SCA-1.0


The WSDL automatically generated by the Web Service binding should be generated 
as described in section 2.3.5 of the WS binding specification.

Our current WSDL generation algorithm generates valid WSDL, but different from 
what's described in the SCA spec. 

-- 
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-1494) Implement a functional SCA Policy Framework


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

Jean-Sebastien Delfino updated TUSCANY-1494:


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

 Implement a functional SCA Policy Framework 
 

 Key: TUSCANY-1494
 URL: https://issues.apache.org/jira/browse/TUSCANY-1494
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Venkatakrishnan
Assignee: Venkatakrishnan
 Fix For: Java-SCA-1.0


 Implement a  functional policy framework for Java SCA.  

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


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

[jira] Created: (TUSCANY-1649) Implement SCA transaction policy intents

Implement SCA transaction policy intents


 Key: TUSCANY-1649
 URL: https://issues.apache.org/jira/browse/TUSCANY-1649
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
Reporter: Jean-Sebastien Delfino
 Fix For: Java-SCA-Next


Implement a model, XML syntax support, and runtime for transaction policy 
intents.

The SCA spec for this is not ready yet, but a discussion has started on the 
subject there:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01656.html



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


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

[jira] Created: (TUSCANY-1650) Integrate implementation.DAS with SCA Transaction Policy

2007-08-31 Thread Luciano Resende (JIRA)

Integrate implementation.DAS with SCA Transaction Policy


 Key: TUSCANY-1650
 URL: https://issues.apache.org/jira/browse/TUSCANY-1650
 Project: Tuscany
  Issue Type: New Feature
Affects Versions: Java-SCA-Next
Reporter: Luciano Resende
 Fix For: Java-SCA-Next




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


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

[jira] Created: (TUSCANY-1651) Implement support for SCA security policy intents

Implement support for SCA security policy intents
-

 Key: TUSCANY-1651
 URL: https://issues.apache.org/jira/browse/TUSCANY-1651
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
Reporter: Jean-Sebastien Delfino
 Fix For: Java-SCA-1.0


We should implement support for the security policy intents described in the 
SCA Policy spec 1.0 sections 1.7.1 and 1.7.2.

It shouldn't be too hard to leverage Axis2 support for WS security to add 
support for the to the Web Service Binding.


-- 
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-1639) I would suggent a improvement on WSDLInterfaceProcessor

[
https://issues.apache.org/jira/browse/TUSCANY-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524247
]

Jean-Sebastien Delfino commented on TUSCANY-1639:
-

Right, it is sometimes useful to be able to point to the actual location of the
WSDL file.

I'd like to suggest a minor variation of what you're describing.

Instead of using the uri attribute, the SCA specification suggests to use:
interface wsdlLocation=location/
to point to the location of a WSDL file.

This is documented on lines 2307, 2847 and 2943 in the SCA assembly spec 1.0
document.

Doing it this way will also allow Tuscany to support other schemes than ?wsdl,
since whatever is specified in the wsdlLocation attribute will be used as a
location hint for the WSDL.

It would be great if you could work on that and provide support for loading
WSDL from the specified location! You just need to attach a patch to this JIRA
and we'll review it. Thanks!

I would suggent a improvement on WSDLInterfaceProcessor
---

Key: TUSCANY-1639
URL: https://issues.apache.org/jira/browse/TUSCANY-1639
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-Next
Environment: jdk1.5 eclipse windiows latest svn code
Reporter: gengshaoguang
Fix For: Java-SCA-Next

Hi everyone,
I would suggest the following:
When reference a wsdl with referenceinterface.wsdl
interface=[uri]//reference, the [uri] atttribute must be based on a
preloaded local saved wsdl file.
Would it be better if the developer specify a ?wsdl like uri, then the
WSDLInterfaceProcessor could load it from remote/dynamic place instead of
from classpath.
If no one against my suggestion, I would like to do some thing more on this.

--
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-1639) I would suggent a improvement on WSDLInterfaceProcessor