date:20110209

maven dependency

2011-02-09 Thread Matt Van Wely

Hello All, if this is the wrong forum for this question please let me
know.  I appreciate any help you can provide...

I've been struggling for some time now trying to determine which maven
dependencies are required to satisfy the Tuscany runtime.  Is there a
simple maven dependency which provides all necessary runtime jars or
is it recommended that I hand pick the required ones for the
bindings/runtimes in my composite?  I have a simple app that uses
Spring, Java and WS bindings but I'm not able to satisfy all the
dependencies and therefore keep hitting NoClassDef...  I've attached a
sample composite file with my pom file hoping that someone would be
able to help.

My current error is:  Caused by: java.lang.ClassNotFoundException:
org.apache.tuscany.sca.policy.security.http.ssl.HTTPSPolicy  - and it
difficult to figure out which maven dependency satisfys that need. Is
there a page which details all the different maven dependencies?

Thanks,
Matt-
http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";>
	4.0.0

	
		com.rim.platform.wff
		wff-samples
		0.0.1-SNAPSHOT
		../pom.xml
	


	
		2.0-Beta1
	

	com.rim.platform.wff
	tuscanysca-sample
	0.0.1-SNAPSHOT
	jar
	Tuscany SCA


	

		
		
			org.apache.tuscany.sca
			tuscany-core
			${tuscany.version}
		

		
			org.apache.tuscany.sca
			tuscany-feature-api
			pom
			${tuscany.version}
		

		
			org.apache.tuscany.sca
			tuscany-node-impl
			${tuscany.version}
		

		
			org.apache.tuscany.sca
			tuscany-data-api
			${tuscany.version}
		

		
			org.apache.tuscany.sca
			tuscany-sca-api
			${tuscany.version}
			runtime
		

		
			org.apache.tuscany.sca
			tuscany-implementation-spring
			${tuscany.version}
			runtime
		

		
			org.apache.tuscany.sca
			tuscany-implementation-spring-runtime
			${tuscany.version}
			runtime
		

		
			org.apache.tuscany.sca
			tuscany-implementation-java
			${tuscany.version}
			runtime
		

		
			org.apache.tuscany.sca
			tuscany-implementation-java-runtime
			${tuscany.version}
			runtime
		

		
		
			org.apache.tuscany.sca
			tuscany-sca-client-impl
			${tuscany.version}
			runtime
		

		
			org.apache.tuscany.sca
			tuscany-binding-ws
			${tuscany.version}
			runtime
		


		
			org.apache.tuscany.sca
			tuscany-binding-ws-runtime-axis2
			${tuscany.version}
			runtime
		

		
			org.apache.tuscany.sca
			tuscany-binding-ws-runtime-jaxws
			${tuscany.version}
			runtime
		

		
			org.apache.tuscany.sca
			tuscany-binding-ws-runtime-jaxws-ri
			${tuscany.version}
			runtime
		

		
			org.apache.tuscany.sca
			tuscany-binding-ws-wsdlgen
			${tuscany.version}
			runtime
		

		
			org.apache.tuscany.sca
			tuscany-policy-wspolicy
			${tuscany.version}
			runtime
		
		
	

	
		${project.artifactId}

problem with binding-corba-runtime test running with my local changes... need a different ORB?

2011-02-09 Thread Scott Kurz

Before trying to tackle
 https://issues.apache.org/jira/browse/TUSCANY-3832
I was trying to deal with the fact that I broke the
binding-corba-runtime module tests, hitting a CORBA MARSHAL exception.

This module does use a mock 'TestOperation' (which implements
Operation which I'd changed in my patch), leading me to think maybe I
was dealing with an incompatible change serialization type of issue.

But I'm kind of stuck.   I don't see us actually passing TestOperation
as a parameter.In looking at the IDL I don't see why I'd need to
do another idl2java, but maybe I'm wrong.

I don't know CORBA all that well and was wondering if anyone had any ideas

When I use the Sun JDK (1.6) I see:
   org.omg.CORBA.MARSHAL:   vmcid: SUN  minor code: 207  completed: No

When I use the IBM JDK (1.6):
   org.omg.CORBA.MARSHAL: No available data: Request 14:read beyond
end of data. No fragments available.  vmcid: OMG  minor code: 8
completed: Maybe

Here are the failed tests:
  
test_primitivesSetter(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase)
  
test_arraysSetter(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase)
  
test_TestObject_setStruct(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase)
  test_enums(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase)
  
test_nonCorbaServants(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase)
  
test_arraysPassing(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase)

I'm doing an offline mvn so I don't overwrite my local changes to
other modules.

I found this post suggesting the Sun JDK 207 code could be addressed
by using the IBM ORB in the Sun JDK
  http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14036393
but I'm guessing that using the IBM JDK is just as good.

Any ideas??

Thanks,
Scott

Re: Issues building Apache Tuscany SCA iTest Distribution Launcher Embedded JSE module

2011-02-09 Thread Florian Moga

Hi Mike,

Thanks for the tips. I've debugged through it and it turns out that the
stop() method of DefaultRMIHost doesn't even get called. I've done some
local changes that call that stop method (even though it's really ugly as I
had to use casting because the RMIHost interface doesn't have a stop method
and ExtensibleRMIHost doesn't provide a stop method through it's public
API). Even with those hacks, the problem is still reproducible... I'm trying
to figure out a way of monitoring what's happening in the concurrent
environment as simple debugging isn't that helpful in reproducing it.

Florian



On Wed, Feb 9, 2011 at 12:08 PM, Mike Edwards <
mike.edwards.inglen...@gmail.com> wrote:

> On 07/02/2011 10:56, Florian Moga wrote:
>
>> On Mon, Feb 7, 2011 at 12:43 PM, Simon Laws > > wrote:
>>
>>So when you do a full build the build always hangs?
>>
>> Yes.
>>
>>Is that test still in the build as I don't experience that.
>>
>> Yes.
>>
>>What environment are you on?
>>
>> Ubuntu 10.10, Sun JVM 6u22, Maven 2.2.1, Ant 1.7.1
>> Same happens with OpenJDK
>>
>>
>>Simon
>>
>>
>>--
>>Apache Tuscany committer: tuscany.apache.org <
>> http://tuscany.apache.org>
>>Co-author of a book about Tuscany and SCA: tuscanyinaction.com <
>> http://tuscanyinaction.com>
>>
>>
>>  Florian,
>
> My experience with this testcase is that it fails with a hang on an
> intermittent basis, relatively infrequently.
>
> I am running on Windows XP with Sun JDK 1.6.0_22.
>
> I looked into reports of hangs relating to the RMI code and there are
> reports of such hangs if the RMI Registry is not released correctly when
> stopping it.  RMI uses a pile of threads and can have connections open
> between Client and Server side that need to be properly closed.
>
> A thread dump when the hang occurs does show an RMI thread waiting on some
> kind of lock, but I am not able to make much sense of what is going on.
>
> I suspect that the place to start looking is in the RMIHost code - and in
> the stop() method of DefaultRMIHost...
>
>
> Yours,  Mike.
>

[jira] Commented: (TUSCANY-3834) Exceptions in application code during @Destroy seem to cause the runtime to stop without trying to stop all of the components

2011-02-09 Thread Simon Laws (JIRA)


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

Simon Laws commented on TUSCANY-3834:
-

There were extra changes made to 1.x under TUSCANY-2851 that we should also 
take account of as they don't seem to have been applied to 2.x.

> Exceptions in application code during @Destroy seem to cause the runtime to 
> stop without trying to stop all of the components
> -
>
> Key: TUSCANY-3834
> URL: https://issues.apache.org/jira/browse/TUSCANY-3834
> Project: Tuscany
>  Issue Type: Bug
>  Components: SCA Java Runtime
>Affects Versions: Java-SCA-2.x, Java-SCA-1.x
> Environment: All
>Reporter: Simon Laws
>Assignee: Simon Laws
>
> This affects 1.x and probably affects 2.x
> It looks like the runtime doesn't continue shutting down if any of the 
> operations marked @Destroy throws an exception. 

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (TUSCANY-3834) Exceptions in application code during @Destroy seem to cause the runtime to stop without trying to stop all of the components

2011-02-09 Thread Simon Laws (JIRA)


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

Simon Laws reassigned TUSCANY-3834:
---

Assignee: Simon Laws

> Exceptions in application code during @Destroy seem to cause the runtime to 
> stop without trying to stop all of the components
> -
>
> Key: TUSCANY-3834
> URL: https://issues.apache.org/jira/browse/TUSCANY-3834
> Project: Tuscany
>  Issue Type: Bug
>  Components: SCA Java Runtime
>Affects Versions: Java-SCA-2.x, Java-SCA-1.x
> Environment: All
>Reporter: Simon Laws
>Assignee: Simon Laws
>
> This affects 1.x and probably affects 2.x
> It looks like the runtime doesn't continue shutting down if any of the 
> operations marked @Destroy throws an exception. 

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

2011-02-09 Thread Simon Nash


ant elder wrote:

On Wed, Feb 9, 2011 at 10:56 AM, Simon Nash  wrote:

ant elder wrote:

On Tue, Feb 8, 2011 at 2:12 PM, Simon Nash  wrote:

ant elder wrote:

On Tue, Feb 8, 2011 at 11:17 AM, Simon Nash  wrote:

Mike Edwards wrote:

On 08/02/2011 10:08, ant elder wrote:

On Tue, Feb 8, 2011 at 9:56 AM, Simon Laws
 wrote:

I can see that relaxing the current spec restrictiveness would be
difficult as things would break in some circumstances, but it does
seem like there will be situations when the assembler really knows
it
would be fine but even so they can't get the PBR optimization
because
the impls aren't coded with the @AllowsPassByReference annotation.
Isn't that a similar situation to where the remotable annotation
was
added to the interface SCDL element, and there could be a similar
allowsPassByReference attribute added to the service and reference
SCDL elements?

 ...ant


Hi Ant.

Can you say a bit more about the "situations when the assembler
really
knows it would be fine"? Reading previous posts to this thread
doesn't
convince me that that is the case.

Simon


We'll have to wait for Raymond to see if thats anything like his
situation, but there are lots of ways the assembler could know, he
may
well have full access to the source but still be limited in making
any
updates due to production lifecycle or control issues. This seems
like
a similar situation as Java EE appservers have and I believe many
appservers have mechanisims for overriding and enabling PBR support
in
their ORB or EJB modules to gain performance benefits.

 ...ant


Folks,

One possibility to start with would be to add a Tuscany extension
attribute which could be used by an Assembler to mark a particular
service
and/or reference as "AllowsPassByReference".

This would cope with the situation where the Java components are not
marked, but the assembler knows enough about them to know that the
marking
is correct.


Yours,  Mike.



I'm very dubious about the wisdom of this.  I bear the scars from a
previous life of a situation where a flag was added to an enterprise
application server (which shall remain nameless) to override the PBV
semantics required by the architecture in the interests of performance
optimization when the user of the product "knew" that using PBR would
be safe.  Needless to say, on a number of occasions this flag was set
incorrectly and this resulted in accusations of runtime bugs that were
eventually shown after laborious debugging to have been caused by the
PBR "optimization" being enabled incorrectly.

IMO it's the implementation's responsibility to make the correct
assertions about whether it's PBR-safe.  Implementations that don't
assert @AllowsPassByReference will have worse performance than those
that do support it.  If a component developer cares about performance,
they need to code their implementation to play by the APBR rules and
turn on the flag to say they have done that.  If the flag isn't turned
on by the implementer, I can't imagine that an assembler will have a
detailed enough knowledge of the implementation to be able to safely
provide the APBR assertion that the component developer couldn't/
wouldn't/didn't provide.

(Deep breath) Now I feel better after getting that off my chest :-)

 Simon



As an attempt to justify this: we don't have any samples that use
@AllowsPassByReference, and I don't recall ever seeing many in Tuscany
or elsewhere that do, but i think all those samples i've seen probably
would have worked fine with it as they don't modify anything
afterwards. I think it would be relatively uncommon to code something
that would be unsuitable for using @AllowsPassByReference. So Joe
developer writing his code probably wont use @AllowsPassByReference
either, may not even know it exists, and any performance issues likely
wont get found until much later when running in a production system by
which time it can be very hard and time consuming to get the code
modified, re-test, QA'd and redeploying into the live system.


OK, that's a good point and we should fix the Tuscany samples so that
people reading them get the message about using APBR.


One further comment from me too :)

Well the thing with that is that _if_ we should be worried that having
a PBR override facility is dangerous because people will see it as a
"go faster" flag and turn it on when they shouldn't then the same
could just as easily will happen with the annotation - someone will
copy the sample for their code, that will get copied around all the
impls they and their colleagues write and people may or may not notice
or understand why the annotation is there or just think its a Good
Thing as it improves performance. One day one of their impls wont be
suitable for using PBR and it will intermittently go wrong and be even
harder to track down as you'll have to actually understand what all
the impl code does.


Well, that could certainly happen, just like any other kind of
implementation bug.  As it's in the implementation it

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

2011-02-09 Thread ant elder

On Wed, Feb 9, 2011 at 10:56 AM, Simon Nash  wrote:
> ant elder wrote:
>>
>> On Tue, Feb 8, 2011 at 2:12 PM, Simon Nash  wrote:
>>>
>>> ant elder wrote:

 On Tue, Feb 8, 2011 at 11:17 AM, Simon Nash  wrote:
>
> Mike Edwards wrote:
>>
>> On 08/02/2011 10:08, ant elder wrote:
>>>
>>> On Tue, Feb 8, 2011 at 9:56 AM, Simon Laws
>>>  wrote:
>
> I can see that relaxing the current spec restrictiveness would be
> difficult as things would break in some circumstances, but it does
> seem like there will be situations when the assembler really knows
> it
> would be fine but even so they can't get the PBR optimization
> because
> the impls aren't coded with the @AllowsPassByReference annotation.
> Isn't that a similar situation to where the remotable annotation
> was
> added to the interface SCDL element, and there could be a similar
> allowsPassByReference attribute added to the service and reference
> SCDL elements?
>
>  ...ant
>
 Hi Ant.

 Can you say a bit more about the "situations when the assembler
 really
 knows it would be fine"? Reading previous posts to this thread
 doesn't
 convince me that that is the case.

 Simon

>>> We'll have to wait for Raymond to see if thats anything like his
>>> situation, but there are lots of ways the assembler could know, he
>>> may
>>> well have full access to the source but still be limited in making
>>> any
>>> updates due to production lifecycle or control issues. This seems
>>> like
>>> a similar situation as Java EE appservers have and I believe many
>>> appservers have mechanisims for overriding and enabling PBR support
>>> in
>>> their ORB or EJB modules to gain performance benefits.
>>>
>>>  ...ant
>>>
>> Folks,
>>
>> One possibility to start with would be to add a Tuscany extension
>> attribute which could be used by an Assembler to mark a particular
>> service
>> and/or reference as "AllowsPassByReference".
>>
>> This would cope with the situation where the Java components are not
>> marked, but the assembler knows enough about them to know that the
>> marking
>> is correct.
>>
>>
>> Yours,  Mike.
>>
>>
> I'm very dubious about the wisdom of this.  I bear the scars from a
> previous life of a situation where a flag was added to an enterprise
> application server (which shall remain nameless) to override the PBV
> semantics required by the architecture in the interests of performance
> optimization when the user of the product "knew" that using PBR would
> be safe.  Needless to say, on a number of occasions this flag was set
> incorrectly and this resulted in accusations of runtime bugs that were
> eventually shown after laborious debugging to have been caused by the
> PBR "optimization" being enabled incorrectly.
>
> IMO it's the implementation's responsibility to make the correct
> assertions about whether it's PBR-safe.  Implementations that don't
> assert @AllowsPassByReference will have worse performance than those
> that do support it.  If a component developer cares about performance,
> they need to code their implementation to play by the APBR rules and
> turn on the flag to say they have done that.  If the flag isn't turned
> on by the implementer, I can't imagine that an assembler will have a
> detailed enough knowledge of the implementation to be able to safely
> provide the APBR assertion that the component developer couldn't/
> wouldn't/didn't provide.
>
> (Deep breath) Now I feel better after getting that off my chest :-)
>
>  Simon
>
>
 As an attempt to justify this: we don't have any samples that use
 @AllowsPassByReference, and I don't recall ever seeing many in Tuscany
 or elsewhere that do, but i think all those samples i've seen probably
 would have worked fine with it as they don't modify anything
 afterwards. I think it would be relatively uncommon to code something
 that would be unsuitable for using @AllowsPassByReference. So Joe
 developer writing his code probably wont use @AllowsPassByReference
 either, may not even know it exists, and any performance issues likely
 wont get found until much later when running in a production system by
 which time it can be very hard and time consuming to get the code
 modified, re-test, QA'd and redeploying into the live system.

>>> OK, that's a good point and we should fix the Tuscany samples so that
>>> people reading them get the message about using APBR.
>>>
>>
>> One further comment from me too :)
>>
>> Well the thing with that is that _if_ we should be worried that having
>> a PBR override fa

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

2011-02-09 Thread Mike Edwards


On 09/02/2011 10:56, Simon Nash wrote:

On interesting idea (taking up the theme of @RequiresPassByValue) would
to require @AllowsPassByReference to always be present (specifying "true"
or "false") on every service method and every reference. That would
force developers to think about the issue and explicitly state their
intentions. It would make "Hello World" rather ugly, though :-(

Simon



Yuk !!

Yours,  Mike.

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

2011-02-09 Thread Simon Nash


ant elder wrote:

On Tue, Feb 8, 2011 at 2:12 PM, Simon Nash  wrote:

ant elder wrote:

On Tue, Feb 8, 2011 at 11:17 AM, Simon Nash  wrote:

Mike Edwards wrote:

On 08/02/2011 10:08, ant elder wrote:

On Tue, Feb 8, 2011 at 9:56 AM, Simon Laws
 wrote:

I can see that relaxing the current spec restrictiveness would be
difficult as things would break in some circumstances, but it does
seem like there will be situations when the assembler really knows it
would be fine but even so they can't get the PBR optimization because
the impls aren't coded with the @AllowsPassByReference annotation.
Isn't that a similar situation to where the remotable annotation was
added to the interface SCDL element, and there could be a similar
allowsPassByReference attribute added to the service and reference
SCDL elements?

 ...ant


Hi Ant.

Can you say a bit more about the "situations when the assembler really
knows it would be fine"? Reading previous posts to this thread doesn't
convince me that that is the case.

Simon


We'll have to wait for Raymond to see if thats anything like his
situation, but there are lots of ways the assembler could know, he may
well have full access to the source but still be limited in making any
updates due to production lifecycle or control issues. This seems like
a similar situation as Java EE appservers have and I believe many
appservers have mechanisims for overriding and enabling PBR support in
their ORB or EJB modules to gain performance benefits.

  ...ant


Folks,

One possibility to start with would be to add a Tuscany extension
attribute which could be used by an Assembler to mark a particular
service
and/or reference as "AllowsPassByReference".

This would cope with the situation where the Java components are not
marked, but the assembler knows enough about them to know that the
marking
is correct.


Yours,  Mike.



I'm very dubious about the wisdom of this.  I bear the scars from a
previous life of a situation where a flag was added to an enterprise
application server (which shall remain nameless) to override the PBV
semantics required by the architecture in the interests of performance
optimization when the user of the product "knew" that using PBR would
be safe.  Needless to say, on a number of occasions this flag was set
incorrectly and this resulted in accusations of runtime bugs that were
eventually shown after laborious debugging to have been caused by the
PBR "optimization" being enabled incorrectly.

IMO it's the implementation's responsibility to make the correct
assertions about whether it's PBR-safe.  Implementations that don't
assert @AllowsPassByReference will have worse performance than those
that do support it.  If a component developer cares about performance,
they need to code their implementation to play by the APBR rules and
turn on the flag to say they have done that.  If the flag isn't turned
on by the implementer, I can't imagine that an assembler will have a
detailed enough knowledge of the implementation to be able to safely
provide the APBR assertion that the component developer couldn't/
wouldn't/didn't provide.

(Deep breath) Now I feel better after getting that off my chest :-)

 Simon



As an attempt to justify this: we don't have any samples that use
@AllowsPassByReference, and I don't recall ever seeing many in Tuscany
or elsewhere that do, but i think all those samples i've seen probably
would have worked fine with it as they don't modify anything
afterwards. I think it would be relatively uncommon to code something
that would be unsuitable for using @AllowsPassByReference. So Joe
developer writing his code probably wont use @AllowsPassByReference
either, may not even know it exists, and any performance issues likely
wont get found until much later when running in a production system by
which time it can be very hard and time consuming to get the code
modified, re-test, QA'd and redeploying into the live system.


OK, that's a good point and we should fix the Tuscany samples so that
people reading them get the message about using APBR.



One further comment from me too :)

Well the thing with that is that _if_ we should be worried that having
a PBR override facility is dangerous because people will see it as a
"go faster" flag and turn it on when they shouldn't then the same
could just as easily will happen with the annotation - someone will
copy the sample for their code, that will get copied around all the
impls they and their colleagues write and people may or may not notice
or understand why the annotation is there or just think its a Good
Thing as it improves performance. One day one of their impls wont be
suitable for using PBR and it will intermittently go wrong and be even
harder to track down as you'll have to actually understand what all
the impl code does.


Well, that could certainly happen, just like any other kind of
implementation bug.  As it's in the implementation it'll show up
wherever the implementation is used and therefore is like

Re: Issues building Apache Tuscany SCA iTest Distribution Launcher Embedded JSE module

2011-02-09 Thread Mike Edwards


On 07/02/2011 10:56, Florian Moga wrote:

On Mon, Feb 7, 2011 at 12:43 PM, Simon Laws mailto:simonsl...@googlemail.com>> wrote:

So when you do a full build the build always hangs?

Yes.

Is that test still in the build as I don't experience that.

Yes.

What environment are you on?

Ubuntu 10.10, Sun JVM 6u22, Maven 2.2.1, Ant 1.7.1
Same happens with OpenJDK


Simon


--
Apache Tuscany committer: tuscany.apache.org 
Co-author of a book about Tuscany and SCA: tuscanyinaction.com 




Florian,

My experience with this testcase is that it fails with a hang on an intermittent basis, relatively 
infrequently.


I am running on Windows XP with Sun JDK 1.6.0_22.

I looked into reports of hangs relating to the RMI code and there are reports of such hangs if the 
RMI Registry is not released correctly when stopping it.  RMI uses a pile of threads and can have 
connections open between Client and Server side that need to be properly closed.


A thread dump when the hang occurs does show an RMI thread waiting on some kind of lock, but I am 
not able to make much sense of what is going on.


I suspect that the place to start looking is in the RMIHost code - and in the stop() method of 
DefaultRMIHost...



Yours,  Mike.

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

2011-02-09 Thread Florian Moga

On Mon, Feb 7, 2011 at 10:57 PM, Florian Moga  wrote:

> How does the shell operate with webapps? I've tried loading
> helloworld-webapp with mvn tuscany:run and I got a ClassNotFoundException on
> a jetty related class. I've added jetty dependencies to the shell module and
> now i'm getting:
>
> Feb 7, 2011 8:33:48 PM
> org.apache.tuscany.sca.core.runtime.impl.EndpointReferenceBinderImpl []
> (ComponentReferenceTargetNotFound)
> WARNING: Component reference target not found at deployment time, it might
> be a remote service elsewhere in the SCA Domain so well try and resolve it
> again at runtime: {1}
> 2011-02-07 20:33:48.163::INFO:  Logging to STDERR via
> org.mortbay.log.StdErrLog
>
> Embedded error: org.apache.tuscany.sca.runtime.ActivationException:
> java.lang.UnsupportedOperationException
>
> Could you give me some tips on what to do next?
>
>
Are you able to start a webapp using the shell?

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

2011-02-09 Thread ant elder

On Mon, Feb 7, 2011 at 8:57 PM, Florian Moga  wrote:
> How does the shell operate with webapps?

Presently it doesn't, for the webapp samples you have to run them in
some server, so either deploy them to your appserver or some of them
have the Jetty or Tomcat plugin in their pom.xml so you can run them
with "mvn jetty:run".

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

2011-02-09 Thread ant elder

On Tue, Feb 8, 2011 at 8:04 PM, Florian Moga  wrote:
> On Tue, Feb 8, 2011 at 9:18 PM, ant elder  wrote:
>>
>> Ok so views on both sides, to move this along how about:
>>
>> - take a branch from current trunk for the beta2 RC3, maybe or not I
>> or someone will actually go ahead and do the work to make a release
>> from that branch
>
> Does this mean that samples will be in their current format for beta2? Or
> shall we leave only be helloworld-contribution and helloworld-webapp?
>

As things are now I'd probably just do the svn copy to the branch and
then leave everything as is, if/when the release is made from the
branch then the others could get removed.

   ...ant

Re: [1.x] exceptions in @Destroy

2011-02-09 Thread Simon Laws

On Tue, Feb 8, 2011 at 7:01 PM, ant elder  wrote:
> On Tue, Feb 8, 2011 at 4:09 PM, Simon Laws  wrote:
>> I noticed that when an exception is thrown from @Destroy the runtime
>> stops shutting down properly and just throws the exception
>> (TUSCANY-3834). I actually suspect this affects 1.x and 2.x.
>>
>> I extended the java-init-exceptions test to play with this (doesn't
>> fit with the test name but there you go but the otherwise the existing
>> test is perfect). Now this test was added under TUSCANY-2851. However
>> it's not included in the build. This is a bit of a long shot but
>> anyone remember if it was excluded for a good reason?
>>
>
> As it was me that added that i went back through the commit history to
> have a look, i don't think there is any reason to keep it out of the
> build.
>
>   ...ant
>

Ok thanks Ant.

Simon


-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

2011-02-09 Thread ant elder

On Tue, Feb 8, 2011 at 2:12 PM, Simon Nash  wrote:
> ant elder wrote:
>>
>> On Tue, Feb 8, 2011 at 11:17 AM, Simon Nash  wrote:
>>>
>>> Mike Edwards wrote:

 On 08/02/2011 10:08, ant elder wrote:
>
> On Tue, Feb 8, 2011 at 9:56 AM, Simon Laws
>  wrote:
>>>
>>> I can see that relaxing the current spec restrictiveness would be
>>> difficult as things would break in some circumstances, but it does
>>> seem like there will be situations when the assembler really knows it
>>> would be fine but even so they can't get the PBR optimization because
>>> the impls aren't coded with the @AllowsPassByReference annotation.
>>> Isn't that a similar situation to where the remotable annotation was
>>> added to the interface SCDL element, and there could be a similar
>>> allowsPassByReference attribute added to the service and reference
>>> SCDL elements?
>>>
>>>  ...ant
>>>
>> Hi Ant.
>>
>> Can you say a bit more about the "situations when the assembler really
>> knows it would be fine"? Reading previous posts to this thread doesn't
>> convince me that that is the case.
>>
>> Simon
>>
> We'll have to wait for Raymond to see if thats anything like his
> situation, but there are lots of ways the assembler could know, he may
> well have full access to the source but still be limited in making any
> updates due to production lifecycle or control issues. This seems like
> a similar situation as Java EE appservers have and I believe many
> appservers have mechanisims for overriding and enabling PBR support in
> their ORB or EJB modules to gain performance benefits.
>
>   ...ant
>
 Folks,

 One possibility to start with would be to add a Tuscany extension
 attribute which could be used by an Assembler to mark a particular
 service
 and/or reference as "AllowsPassByReference".

 This would cope with the situation where the Java components are not
 marked, but the assembler knows enough about them to know that the
 marking
 is correct.


 Yours,  Mike.


>>> I'm very dubious about the wisdom of this.  I bear the scars from a
>>> previous life of a situation where a flag was added to an enterprise
>>> application server (which shall remain nameless) to override the PBV
>>> semantics required by the architecture in the interests of performance
>>> optimization when the user of the product "knew" that using PBR would
>>> be safe.  Needless to say, on a number of occasions this flag was set
>>> incorrectly and this resulted in accusations of runtime bugs that were
>>> eventually shown after laborious debugging to have been caused by the
>>> PBR "optimization" being enabled incorrectly.
>>>
>>> IMO it's the implementation's responsibility to make the correct
>>> assertions about whether it's PBR-safe.  Implementations that don't
>>> assert @AllowsPassByReference will have worse performance than those
>>> that do support it.  If a component developer cares about performance,
>>> they need to code their implementation to play by the APBR rules and
>>> turn on the flag to say they have done that.  If the flag isn't turned
>>> on by the implementer, I can't imagine that an assembler will have a
>>> detailed enough knowledge of the implementation to be able to safely
>>> provide the APBR assertion that the component developer couldn't/
>>> wouldn't/didn't provide.
>>>
>>> (Deep breath) Now I feel better after getting that off my chest :-)
>>>
>>>  Simon
>>>
>>>
>>
>> As an attempt to justify this: we don't have any samples that use
>> @AllowsPassByReference, and I don't recall ever seeing many in Tuscany
>> or elsewhere that do, but i think all those samples i've seen probably
>> would have worked fine with it as they don't modify anything
>> afterwards. I think it would be relatively uncommon to code something
>> that would be unsuitable for using @AllowsPassByReference. So Joe
>> developer writing his code probably wont use @AllowsPassByReference
>> either, may not even know it exists, and any performance issues likely
>> wont get found until much later when running in a production system by
>> which time it can be very hard and time consuming to get the code
>> modified, re-test, QA'd and redeploying into the live system.
>>
> OK, that's a good point and we should fix the Tuscany samples so that
> people reading them get the message about using APBR.
>

One further comment from me too :)

Well the thing with that is that _if_ we should be worried that having
a PBR override facility is dangerous because people will see it as a
"go faster" flag and turn it on when they shouldn't then the same
could just as easily will happen with the annotation - someone will
copy the sample for their code, that will get copied around all the
impls they and their colleagues write and people may or may not notice
or understand why the annotation is there

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

2011-02-09 Thread Simon Nash


One further comment below regarding my earlier response.

  Simon

Simon Nash wrote:

Raymond Feng wrote:
Thanks for the quick response. I agree with the points you are making. 
A few more arguments:

(cut)
2) If the client side modifies the input data in a different thread 
after issuing a call to the service, the PBV may get the wrong 
snapshot of the parameters too.

 >
That's one of the conditions that disqualifies the client from asserting
@AllowsPassByReference.  See section 2.3.2.


My apologies for not picking up on your point about PBV (not PBR) here.
You're right that modification in this small time window is a problem for
PBV as well as PBR.  The same applies to service-side modification of
returned results or exceptions on a separate thread before the PBV
snasphot is taken.  These problems are extremely hard to diagnose
(I speak from experience many years ago of some all-night debugging
sessions just before shipping a product) and anyone who has been
through this never makes the same mistake again!  So the possibility
of modification in this small time window is something that must be
avoided in all cases, irrespective of whether APBR is asserted.

  Simon

maven dependency

problem with binding-corba-runtime test running with my local changes... need a different ORB?

Re: Issues building Apache Tuscany SCA iTest Distribution Launcher Embedded JSE module

[jira] Commented: (TUSCANY-3834) Exceptions in application code during @Destroy seem to cause the runtime to stop without trying to stop all of the components

[jira] Assigned: (TUSCANY-3834) Exceptions in application code during @Destroy seem to cause the runtime to stop without trying to stop all of the components

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

Re: Issues building Apache Tuscany SCA iTest Distribution Launcher Embedded JSE module

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

Re: [1.x] exceptions in @Destroy

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

Re: [DISCUSS] SCA AllowsPassByReference spec clarification

16 matches

Site Navigation

Mail list logo

Footer information