Re: Running Tuscany/SCA in Google Android mobile platform

[Adriano Crestani]

I have started to change the SCA code.

Initially, the objects instantiated dynamically were not being instantiated,
because info about which class to instantiate is extract from some text
files contained in SCA modules' jars. Unfortunately, when Android converter
converts the SCA modules' jars to .dex files, it ignores the non-class
files, and they are not included. It happens because Android has a very
specific way to store the app resources, which is completely different from
Java.

Though, as Luciano suggested, I started to modify these dynamic
instantiation for static. It's working for now : ). All these modifications
were made only on host-embedded module code, which I have copied into [1]
and renamed to host-android.

Also, one of those static instantiated classes was trying to access the
javax.naming.InitialContext in its constructor, but it's not supported by
Android and I commented the code. As this class belonged to SCA core module,
I also copied this module into the mobile-android sandbox and renamed the
module to core-android.

So, all the modifications made so far are in the [2].

Now, as I was expecting, I got some ClassNotFoundExceptions on SCA code when
it tries to use the Java XML API. It happens because Android implements only
a small part of this API. So, next step is try to adapt the SCA XML access
into Android way to access XML. Does anybody know some other XML API that is
javax.xml independent I could use instead of Android one?

Suggestions? : )

Adriano Crestani

[1]
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/host-android/
[2]
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android/



On Mon, Mar 17, 2008 at 1:41 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> I'd probably categorize the experiment we are doing now, as a learning
> experience to familiarize with the Mobile environment available in
> Google Android. For this, we have choosen to try running one of the
> simplest samples we had (calculator) in the Android JVM
> environment In the long run, the idea is to have a more
> light-weight "sca mobile core/runtime" available, similar to what we
> did for Web 2.0 (implementation-widget) and described by Mike below.
>
> But it's indeed good to discuss these items with the community, would
> be also good to have the community contributing requirements/scenarios
> for a Tuscany mobile story. And we are all open and welcoming any
> help.
>
>
> On Mon, Mar 17, 2008 at 8:22 AM, Mike Edwards
> <[EMAIL PROTECTED]> wrote:
> > Brandon Werner wrote:
> >  > Can you explain the benefit of moving SCA/SDO over to the Android
> platform?
> >  > I can understand wanting to have the ability to consume simple XML
> services
> >  > and perhaps consume disconnected datagraphs, but I don't understand
> why the
> >  > world wouldn't want a more light-weight way of doing that than
> ripping out
> >  > something that was meant for the JEE / JSE.
> >  >
> >  > 
> >  Brandon,
> >
> >  So you think that a device using the Andriod platform is likely to want
> >  to use services and a service-oriented approach to building
> >  applications.  But you think that SCA is too "heavyweight"?  Is that
> >  simply a question of the size of the code involved (I note that the
> core
> >  of Tuscany is quite small) or is the SCA approach too "heavyweight" in
> >  some other sense?
> >
> >  I wonder if you've taken a look a the implementation.widget exemplified
> >  in the Tutorial demo code?  This applies SCA principles to AJAX widgets
> >  running in the browser - simplifying the connectivity a great deal (in
> >  my opinion) and yet adding little overhead.
> >
> >  In the longer run, we may want to look to do something similar for the
> >  Android platforms, perhaps with Java rather than the more limited
> >  JavaScript components.  Starting with the current SCA package seems
> >  reasonable to me - once we have experience with how that works, we will
> >  have a better idea what needs to be changed and tailored for the
> Android
> >  platform.
> >
> >
> >  Yours,  Mike.
> >
> >
> >
> >  -
> >  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Feed Binding, was Re: svn commit: r639187 - in /incubator/tuscany/branches/sca-java-1.2: distribution/bundle/pom.xml distribution/manifest/pom.xml samples/calculator-distributed/build.xml

[Luciano Resende]

Thanks for volunteering !

On Thu, Mar 20, 2008 at 12:12 PM, Jean-Sebastien Delfino
<[EMAIL PROTECTED]> wrote:
> Luciano Resende wrote:
>  > I'm adding back the Feed binding to the distribution as there is still
>  > one sample that uses rome atom/rss binding.
>  >
>
>  I can fix the sample to use the new binding if that helps. Having both
>  the old and new bindings is likely to cause confusion, as people will
>  not know which one gets picked.
>
>  --
>  Jean-Sebastien
>
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>



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

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

Re: Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor

[scabooz]

Hi guys,

I'm not an XML expert but I think if you wanted that qualified intent
to be in a separate namespace you'd do it like this:

http://www.apache.org/tuscany"; ..>

   
   Used to indicate that a component implementation requires a
managed global transaction.
   
   


You cannot put the QName into intent/@name.

I don't understand why anyone would want to put qualifiers in a
namespace different than the parent intent.

A recent decision in the OASIS Policy spec has made separate
namespaces impossible so I don't think you should spend much time
worrying about it.

Dave

- Original Message - 
From: "Venkata Krishnan" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, March 20, 2008 8:43 AM
Subject: Re: Qualifiable Policy intents - QNames or NCNames? was: About 
StAXArtifactProcessor




Hi Sebastien,

Here is a snippet from
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy-transaction/src/main/resources/org/apache/tuscany/sca/policy/transaction/definitions.xml

- definitions.xml -

http://www.osoa.org/xmlns/sca/1.0"; targetNamespace="
http://www.osoa.org/xmlns/sca/1.0";
   xmlns:sca="http://www.osoa.org/xmlns/sca/1.0"; xmlns:tuscany="
http://tuscany.apache.org/xmlns/sca/1.0";>

   
   Used to indicate the transaction environment desired 
by

a component implementation.
   

   
   
   Used to indicate that a component implementation requires a
managed global transaction.
   
   

   
   
   Used to indicate that a component implementation requires a
managed local transaction.
   
   

..

---

Over here, the intents "managedTransaction.global" and "
managedTransaction.local" are qualified intents with "managedTransaction"
being the qualifiable intent.  Since we have decided that the 'name'
attribute of an 'intent' element is going to be NCName we end up forcing 
the
qualifiable intent to also belong to the targetnamespace.  If it belonged 
to

namespace other than the target, then we'd have to deal with how we can
represent this for example we could resort to ...


   
   Used to indicate that a component implementation requires a
managed global transaction.
   
   

where we could say that managedTransaction is an intent defined under the
namespace that the prefix 'tuscany' points to.   But if we did this, the
'name' attribute must be read a QName which ends us in a contradiction.

Thanks

- Venkat



On Thu, Mar 20, 2008 at 2:14 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:


Venkata Krishnan wrote:
> Hi Sebastien,
>
> Thanks.  Please find my comments inline.  Not much though :)
>
> On Tue, Mar 18, 2008 at 3:46 AM, Jean-Sebastien Delfino <
> [EMAIL PROTECTED]> wrote:
>
>> Venkata Krishnan wrote:
 2) Unless I'm missing something, I don't think that you need to set
the
 targetNamespace of QualifiedIntent.qualifiableIntents, as it looks
like
 it's already read as a QName from the XML stream (and this QName 
 does

 not have to be in the current targetNamespace).
>>>
>>> First, I think that the Qualifiable intent needs to be in the current
>>> namespace since I I am not sure and the specs does not mention 
>>> either,

>> on
>>> how we could represent a qualified intent whose qualifiable intent
>> belongs
>>> to a different namespace.  So going with the assumption, in this
context
>> the
>>> qualifiable intent needs to be assigned the targetnamspace. Only then
>> would
>>> it be correctly resolved during the resolution phase.
>>>
>> Then I don't understand this code:
>> PolicyIntentProcessor:74
>>qualifiableIntent.setName(getQNameValue(reader,
>>policyIntentName.substring(0, qualifierIndex)));
>>
>> which reads a QName from the XMLStreamReader.
>>
>> Either (a) the qualifiableIntent is always in the target namespace, 
>> and

>> then it's name is defined as an NCName and we shouldn't be trying to
>> read it as a QName, or (b) the qualifiable intent name is actually
>> defined as a QName and then it can belong to another namespace.
>>
>> If I understand it correctly, the policy-xsd defines these names as
>> QNames, leading me to believe that (b) is the correct option.
>
>
> Given the context of disussion in this thread (a) seems to be what it
should
> be.  When cleaning up I missed out this line and I will fix it 
> rightaway

> :(.  But it ends up working because the name is reset with the
> targetnamespace later.  Why I say (a) is because we'd then have
consistency
> with all intent names being NCNames.  Ofcourse, this means that the
> qualifiable intents should also be from the same namespace.
>
> If we allowed intent names to be QNames then (b) would apply and we 
> have

the
> freedom of having qualifiable intents belonging to a different 
> namespace

> than the targetnamespace.  But that will get us back to the bunch

Re: New dependency on Drools

[Luciano Resende]

Are all these dependencies using ASL license ?

On Thu, Mar 20, 2008 at 1:09 PM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:
> These are files needed by JBoss Rules (aka Drools) for its all features:
>  totale 7,4M
>  -rw-r--r-- 1 giorgio giorgio  90K 2007-12-01 19:56 antlr-runtime-3.0.jar
>  -rw-r--r-- 1 giorgio giorgio 412K 2007-12-01 19:12 ant-nodeps-1.6.5.jar
>  -rw-r--r-- 1 giorgio giorgio 3,9M 2007-12-01 19:12 core-3.2.3.v_686_R32x.jar
>  -rw-r--r-- 1 giorgio giorgio  11K 2007-12-01 18:18 drools-ant-4.0.3.jar
>  -rw-r--r-- 1 giorgio giorgio 541K 2007-12-01 18:18 drools-compiler-4.0.3.jar
>  -rw-r--r-- 1 giorgio giorgio 1,1M 2007-12-01 18:18 drools-core-4.0.3.jar
>  -rw-r--r-- 1 giorgio giorgio  77K 2007-12-01 18:18
>  drools-decisiontables-4.0.3.jar
>  -rw-r--r-- 1 giorgio giorgio  23K 2007-12-01 18:18 drools-jsr94-4.0.3.jar
>  -rw-r--r-- 1 giorgio giorgio 442K 2007-12-01 19:12 janino-2.5.10.jar
>  -rw-r--r-- 1 giorgio giorgio  14K 2007-12-01 19:12 jsr94-1.1.jar
>  -rw-r--r-- 1 giorgio giorgio 488K 2007-12-01 19:12 jxl-2.4.2.jar
>  -rw-r--r-- 1 giorgio giorgio 412K 2007-12-01 19:12 mvel14-1.2.10.jar
>
>  Cheers,
>  Giorgio
>
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>



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

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

Re: [SCA 1.2] Stable SCA distribution for testing purposes

[Luciano Resende]

I have uploaded a new set of stable binaries as preparation for
tonight Release Candidate. These files were based on SCA 1.2 branch
revision #639399.

On Tue, Mar 18, 2008 at 12:18 AM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> I'm in the process of uploading SCA distribution (binary and source )
>  for testing purpose. Let's use it for testing, and report issues via
>  JIRA and assign to SCA 1.2 release as appropriate.
>
>  [1] http://people.apache.org/~lresende/tuscany/sca-1.2-stable/
>
>  --
>  Luciano Resende
>  Apache Tuscany Committer
>  http://people.apache.org/~lresende
>  http://lresende.blogspot.com/
>



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

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

Re: New dependency on Drools

[Giorgio Zoppi]

These are files needed by JBoss Rules (aka Drools) for its all features:
totale 7,4M
-rw-r--r-- 1 giorgio giorgio  90K 2007-12-01 19:56 antlr-runtime-3.0.jar
-rw-r--r-- 1 giorgio giorgio 412K 2007-12-01 19:12 ant-nodeps-1.6.5.jar
-rw-r--r-- 1 giorgio giorgio 3,9M 2007-12-01 19:12 core-3.2.3.v_686_R32x.jar
-rw-r--r-- 1 giorgio giorgio  11K 2007-12-01 18:18 drools-ant-4.0.3.jar
-rw-r--r-- 1 giorgio giorgio 541K 2007-12-01 18:18 drools-compiler-4.0.3.jar
-rw-r--r-- 1 giorgio giorgio 1,1M 2007-12-01 18:18 drools-core-4.0.3.jar
-rw-r--r-- 1 giorgio giorgio  77K 2007-12-01 18:18
drools-decisiontables-4.0.3.jar
-rw-r--r-- 1 giorgio giorgio  23K 2007-12-01 18:18 drools-jsr94-4.0.3.jar
-rw-r--r-- 1 giorgio giorgio 442K 2007-12-01 19:12 janino-2.5.10.jar
-rw-r--r-- 1 giorgio giorgio  14K 2007-12-01 19:12 jsr94-1.1.jar
-rw-r--r-- 1 giorgio giorgio 488K 2007-12-01 19:12 jxl-2.4.2.jar
-rw-r--r-- 1 giorgio giorgio 412K 2007-12-01 19:12 mvel14-1.2.10.jar

Cheers,
Giorgio

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

Re: [jira] Commented: (TUSCANY-2099) Porting Workpool-Distributed demo to current.

[Giorgio Zoppi]

2008/3/20, Simon Laws (JIRA) :
>
> [ 
> https://issues.apache.org/jira/browse/TUSCANY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580743#action_12580743
>  ]
>
>
>  Simon Laws commented on TUSCANY-2099:
>  -
>
>
> Hi Girogio. I've committed the patch. It's difficult to comment in detail 
> until we have the code working. What I was wondering though is whether new 
> components really need to be installed dynamically, with all the code 
> complexity involved, or whether the same effect can be produced by relying on 
> separate, for example, conversational, instances of the same component for 
> running jobs.

I don't know. But for example in the first case, it opens the
possibility to distribute new
components over jvm instances.

What I'm not clear on is whether 1) all of the components you start
are all of the same type and just run jobs or whether 2) the jobs them
selves are components. Looking at the code it seems that 1) is the
case. Anyhow I'm not suggesting you change the design on the fly but
there may be some opportunities for simplification down the line.

Every kind of suggestion is appreciated. The case is 1).


>  Simon
>
>
>  > Porting Workpool-Distributed demo to current.
>  > -
>  >
>  > Key: TUSCANY-2099
>  > URL: https://issues.apache.org/jira/browse/TUSCANY-2099
>  > Project: Tuscany
>  >  Issue Type: New Feature
>  >Reporter: Giorgio Zoppi
>  >Assignee: Simon Laws
>  > Fix For: Java-SCA-Next
>  >
>  > Attachments: firstpatch.diff
>  >
>  >
>  > This is the first patch to adapt workpool demo to current. Still it 
> doens't compile.
>
>  --
>  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: Feed Binding, was Re: svn commit: r639187 - in /incubator/tuscany/branches/sca-java-1.2: distribution/bundle/pom.xml distribution/manifest/pom.xml samples/calculator-distributed/build.xml

[Jean-Sebastien Delfino]

Luciano Resende wrote:

I'm adding back the Feed binding to the distribution as there is still
one sample that uses rome atom/rss binding.



I can fix the sample to use the new binding if that helps. Having both 
the old and new bindings is likely to cause confusion, as people will 
not know which one gets picked.


--
Jean-Sebastien

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

Feed Binding, was Re: svn commit: r639187 - in /incubator/tuscany/branches/sca-java-1.2: distribution/bundle/pom.xml distribution/manifest/pom.xml samples/calculator-distributed/build.xml

[Luciano Resende]

I'm adding back the Feed binding to the distribution as there is still
one sample that uses rome atom/rss binding.

On Thu, Mar 20, 2008 at 12:44 AM,  <[EMAIL PROTECTED]> wrote:
> Author: jsdelfino
>  Date: Thu Mar 20 00:44:42 2008
>  New Revision: 639187
>
>  URL: http://svn.apache.org/viewvc?rev=639187&view=rev
>  Log:
>  Added missing JARs to distribution build. Removed obsolete feed binding 
> JARs. Fixed class names in calculator-distributed/build.xml.
>
>  Modified:
> incubator/tuscany/branches/sca-java-1.2/distribution/bundle/pom.xml
> incubator/tuscany/branches/sca-java-1.2/distribution/manifest/pom.xml
> 
> incubator/tuscany/branches/sca-java-1.2/samples/calculator-distributed/build.xml
>
>  Modified: incubator/tuscany/branches/sca-java-1.2/distribution/bundle/pom.xml
>  URL: 
> http://svn.apache.org/viewvc/incubator/tuscany/branches/sca-java-1.2/distribution/bundle/pom.xml?rev=639187&r1=639186&r2=639187&view=diff
>  
> ==
>  --- incubator/tuscany/branches/sca-java-1.2/distribution/bundle/pom.xml 
> (original)
>  +++ incubator/tuscany/branches/sca-java-1.2/distribution/bundle/pom.xml Thu 
> Mar 20 00:44:42 2008
>  @@ -64,7 +64,7 @@
>  
>  
>  ${pom.groupId}
>  -tuscany-binding-feed
>  +tuscany-binding-atom
>  ${pom.version}
>  
>  
>  @@ -94,6 +94,11 @@
>  
>  
>  ${pom.groupId}
>  +tuscany-binding-rss
>  +${pom.version}
>  +
>  +
>  +${pom.groupId}
>  tuscany-binding-rss-rome
>  ${pom.version}
>  
>  @@ -380,11 +385,26 @@
>  
>  
>  ${pom.groupId}
>  +tuscany-node2-api
>  +${pom.version}
>  +
>  +
>  +${pom.groupId}
>  tuscany-node-impl
>  ${pom.version}
>  
>  
>  ${pom.groupId}
>  +tuscany-node2-impl
>  +${pom.version}
>  +
>  +
>  +${pom.groupId}
>  +tuscany-node2-launcher
>  +${pom.version}
>  +
>  +
>  +${pom.groupId}
>  tuscany-policy
>  ${pom.version}
>  
>  @@ -507,12 +527,6 @@
>  
>  implementation="org.codehaus.mojo.shade.resource.AppendingTransformer">
>  
> META-INF/services/org.apache.tuscany.sca.assembly.SCABindingFactory
>  -
>  -implementation="org.codehaus.mojo.shade.resource.AppendingTransformer">
>  -
> META-INF/services/org.apache.tuscany.sca.binding.feed.AtomBindingFactory
>  -
>  -implementation="org.codehaus.mojo.shade.resource.AppendingTransformer">
>  -
> META-INF/services/org.apache.tuscany.sca.binding.feed.RSSBindingFactory
>  
>  implementation="org.codehaus.mojo.shade.resource.AppendingTransformer">
>  
> META-INF/services/org.apache.tuscany.sca.binding.atom.AtomBindingFactory
>
>  Modified: 
> incubator/tuscany/branches/sca-java-1.2/distribution/manifest/pom.xml
>  URL: 
> http://svn.apache.org/viewvc/incubator/tuscany/branches/sca-java-1.2/distribution/manifest/pom.xml?rev=639187&r1=639186&r2=639187&view=diff
>  
> ==
>  --- incubator/tuscany/branches/sca-java-1.2/distribution/manifest/pom.xml 
> (original)
>  +++ incubator/tuscany/branches/sca-java-1.2/distribution/manifest/pom.xml 
> Thu Mar 20 00:44:42 2008
>  @@ -57,7 +57,7 @@
>  
>  
>  ${pom.groupId}
>  -tuscany-binding-feed
>  +tuscany-binding-atom
>  ${pom.version}
>  
>  
>  @@ -67,6 +67,11 @@
>  
>  
>  ${pom.groupId}
>  +tuscany-binding-rss
>  +${pom.version}
>  +
>  +
>  +${pom.groupId}
>  tuscany-binding-rss-rome
>  ${pom.version}
>  
>  @@ -343,7 +348,22 @@
>  
>  
>  ${pom.groupId}
>  +tuscany-node2-api
>  +${pom.version}
>  +
>  +
>  +${pom.groupId}
>  tuscany-node-impl
>  +${pom.version}
>  +
>  +
>  +${pom.groupId}
>  +tuscany-node2-impl
>  +${pom.version}
>  +
>  +
>  +${pom.groupId}
>  +tuscany-node2-launcher
>  ${pom.version}
>  
>  
>
>  Modified: 
> incubator/tuscany/branches/sca-j

Re: Build error on java\sca -- Error extracting plugin descriptor: 'No mojo descriptors found in plugin.

[Simon Laws]

On Thu, Mar 20, 2008 at 12:37 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Thu, Mar 20, 2008 at 8:35 AM, Vamsavardhana Reddy <[EMAIL PROTECTED]>
> wrote:
>
> > Forgot to mention in my earlier post.  I am using Maven 2.0.6, Sun JDK
> > 1.5.0on Windows XP.
> >
> > ++Vamsi
> >
> > On Thu, Mar 20, 2008 at 2:02 PM, Vamsavardhana Reddy <
> > [EMAIL PROTECTED]>
> > wrote:
> >
> > > I am hitting a build error on trunk, i.e. java/sca.  The error message
> > is
> > > "Error extracting plugin descriptor: 'No mojo descriptors found in
> > plugin."
> > > Any hints on how to resolve this problem?  Output from command window
> > is
> > > given below.
> > >
> > >
> > > [INFO]
> > >
> > -
> > > ---
> > > [INFO] Building Apache Tuscany SCA Definitions Shade Transformer for
> > > Distributio
> > > n Bundle
> > > [INFO]task-segment: [install]
> > > [INFO]
> > >
> > -
> > > ---
> > > [INFO] [plugin:descriptor]
> > > [INFO] Using 2 extractors.
> > > [INFO] Applying extractor for language: java
> > > [INFO] Extractor for language: java found 0 mojo descriptors.
> > > [INFO] Applying extractor for language: bsh
> > > [INFO] Extractor for language: bsh found 0 mojo descriptors.
> > > [INFO]
> > >
> > 
> > > [ERROR] BUILD ERROR
> > > [INFO]
> > >
> > 
> > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found
> > in
> > > plugin.
> > > '
> > >
> > > [INFO]
> > >
> > 
> > > [INFO] For more information, run Maven with the -e switch
> > > [INFO]
> > >
> > 
> > > [INFO] Total time: 7 minutes 56 seconds
> > > [INFO] Finished at: Thu Mar 20 13:50:19 IST 2008
> > > [INFO] Final Memory: 63M/118M
> > > [INFO]
> > >
> > 
> > >
> >
>
> Hi Vamsi
>
> I'm not seeing this problem. Are you sure you want to build the
> distribution?
>
> Simon
>
I take it back, I realize that issue you have here is with the new shade
transformer that we have and which lives in tools/maven/maven-definitions. I
believe this is only used during the bundle build which I expect you don't
need to do so you should be safe to skip this module for now.

Unfortunately I still have no idea why it's failing for you.

Regards

Simon

Re: Verification Testing

[Kevin Williams]

I would like to tie individual tests in this new suite to specific
functional requirements from the specifications.  The best way to do
this may be to reference named requirements from annotated versions of
the specs.

Would it make sense to store these annotated versions somewhere in the project?

Thanks,

--Kevin

On Thu, Mar 20, 2008 at 3:21 AM, Vamsavardhana Reddy
<[EMAIL PROTECTED]> wrote:
> +1
>
>  ++Vamsi
>
>  On Wed, Mar 19, 2008 at 11:10 PM, Kevin Williams <[EMAIL PROTECTED]>
>  wrote:
>
>
>
>  > I am thinking of adding a new test bucket specifically for
>  > verification testing against the specification set.  I believe it
>  > would add value to the project and may also be a place where
>  > developers new to Tuscany might contribute.  Does this sound like a
>  > reasonable idea?
>  > Thanks,
>  > --Kevin
>  >
>
>
> > -
>  > 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] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany

[Rajini Sivaram (JIRA)]

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

Rajini Sivaram commented on TUSCANY-2097:
-

Thank you, Ant. 

I have modified the OSGi testcase which runs calculator-script to set the 
system property python.cachedir to target/cachedir (revision 639327). So mvn 
clean should now clear that as well.

> Build errors in itest/osgi-tuscany
> --
>
> Key: TUSCANY-2097
> URL: https://issues.apache.org/jira/browse/TUSCANY-2097
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA OSGi Integration
>Affects Versions: Java-SCA-Next
> Environment: Windows, Sun JDK 1.5.0_14
>Reporter: Simon Nash
> Fix For: Java-SCA-Next
>
> Attachments: jira2097.log
>
>
> Here is a summary of the build errors I am seeing.  I will attach my full 
> build log to this JIRA.
> 1. revision.location error creating archive.  This seems to show up on
>every test, and it does not seem to cause a hard failure in the test.
> java.io.FileNotFoundException: 
> F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-
> test\.felix.test\bundle1\version0.0\revision.location (The system cannot find 
> th
> e file specified)
> ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. 
> (ja
> va.io.FileNotFoundException: 
> F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te
> st\.felix.test\bundle1\version0.0\revision.location (The system cannot find 
> the
> file specified))
> 2. InvocationTargetException in CalculatorRMIReferencetestCase.
> java.lang.reflect.InvocationTargetException
> . 
> Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested 
> ex
> ception is:
> java.net.BindException: Address already in use: JVM_Bind
> 3. Various errors in testOSGiTuscany_BindingWS
> -> ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete 
> archi
> ve directory - 
> F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test
> \bundle5
> java.util.zip.ZipException: The system cannot find the file specified
> org.osgi.framework.BundleException: Could not create bundle object.
> .
> Caused by: java.util.zip.ZipException: The system cannot find the file 
> specified

-- 
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: Keeping up with the dev list and the flood of JIRA messages

[ant elder]

On Thu, Mar 20, 2008 at 3:12 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

> Venkata Krishnan wrote:
> > Hi,
> >
> > Yes its a bit distracting but then I find it ok since I'd like to know
> as
> > much of the JIRAs as the other discussions.  I don't filter them out
> thro
> > mail filters coz am a bit apprehensive that at times I might entirely
> ignore
> > what goes in there.
> >
> > The JIRAs are the ones I read out first and clear out of the way.  I
> then
> > run thro the other mails.
> >
> > - Venkat
> >
> I'm doing the same as Venkat, and for the same reason.  I would prefer
> not to have the JIRA messages directed elsewhere.  However, I would
> like some help in learning how to do as Luciano suggests and suppress
> the generation of email notifications for trivial updates.
>
>   Simon
>

When signed in to JIRA and looking at a list of JIRAs in the issue navigator
at the top right you should see a link named "Bulk Change", click on that
you can select JIRAs to modify, and when doing so at the bottom of on one
the panels there's a tick box for " Send mail for this update " that you can
untick. Obviously you need to be a bit discriminating about what sort of
updates use that with :)

   ...ant

[jira] Updated: (TUSCANY-2050) WSDL/xml interface referring to wsdl with XSD imports that cannot be resolved throws nullpointer

[Raymond Feng (JIRA)]

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

Raymond Feng updated TUSCANY-2050:
--

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

Move to SCA-Java-Next as we cannot reproduce the problem.

> WSDL/xml interface referring to wsdl with XSD imports that cannot be resolved 
> throws nullpointer
> 
>
> Key: TUSCANY-2050
> URL: https://issues.apache.org/jira/browse/TUSCANY-2050
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
>Reporter: clemens utschig
>Priority: Critical
> Fix For: Java-SCA-Next
>
>
> having a wsdl interface, that points to a valid wsdl which contains XML 
> schema imports that cannot be resolved throws nullpointer.
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
>   at 
> org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886)
>   at 
> org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620)
>   at 
> org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175)
>   at 
> org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82)
>   at 
> org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359)
>   at 
> org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver.loadOnDemand(XSDModelResolver.java:143)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver.aggregate(XSDModelResolver.java:173)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver.resolveModel(XSDModelResolver.java:104)
>   at 
> org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:127)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver.readInlineSchemas(WSDLModelResolver.java:389)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver.loadDefinition(WSDLModelResolver.java:323)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver.loadOnDemand(WSDLModelResolver.java:288)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver.aggregate(WSDLModelResolver.java:223)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver.resolveModel(WSDLModelResolver.java:256)
>   at 
> org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:127)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolveWSDLInterface(WSDLInterfaceProcessor.java:144)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolve(WSDLInterfaceProcessor.java:168)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolve(WSDLInterfaceProcessor.java:43)
>   at 
> org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:242)
>   at 
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
>   at 
> org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:290)
>   at 
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:752)
>   at 
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:74)
>   at 
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
>   at 
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:113)
>   at 
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:47)
>   at 
> org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:423)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:333)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:155)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:125)
>   at 
> org.apache.tuscan

Re: New dependency on Drools

[Simon Nash]

Simon Laws wrote:

On Thu, Mar 20, 2008 at 1:04 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:


I've just committed the patch from TUSCANY-2099. The patch is a few more
steps on the way to getting the workpool demo running with the latest code
and it introduces a new dependency on Drools. It's ASL2 licenses but I want
to call it out here in case anyone has any concerns.

Thanks

Simon



I should have said this only affects trunk and is not a 1.2 dependency.

Simon


How big is Drools?  Does it drag anything else that we don't already use?

  Simon


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

Re: Keeping up with the dev list and the flood of JIRA messages

[Simon Nash]

Venkata Krishnan wrote:

Hi,

Yes its a bit distracting but then I find it ok since I'd like to know as
much of the JIRAs as the other discussions.  I don't filter them out thro
mail filters coz am a bit apprehensive that at times I might entirely ignore
what goes in there.

The JIRAs are the ones I read out first and clear out of the way.  I then
run thro the other mails.

- Venkat


I'm doing the same as Venkat, and for the same reason.  I would prefer
not to have the JIRA messages directed elsewhere.  However, I would
like some help in learning how to do as Luciano suggests and suppress
the generation of email notifications for trivial updates.

  Simon


On Thu, Mar 20, 2008 at 3:10 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:


Hi,

Just curious, are people able to keep up with the list discussions in
the middle of that flood of JIRA messages?

Is everybody routing JIRAs to a separate folder? I'm finding it
difficult to see through the traffic without doing that.

Thoughts? Can we improve this to make it easier for people to follow?
--
Jean-Sebastien

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







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

SDO XMLDocument serialization of Schema Location and NoNamespace Schema Location

[David Adcox]

When I set either a schema location or a nonamespace schema location
on an XMLDocument object, then serialize that object, I do not see
either location value represented in the serialized document.  The 2.1
spec does not explicitly state that this is a supported behavior, but
given the nature of the other attributes on XMLDocument, it seemed
natural to expect these values to be persisted.

Thanks in advance for any comments

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

Re: Keeping up with the dev list and the flood of JIRA messages

[Dan Becker]

Jean-Sebastien Delfino wrote:
Just curious, are people able to keep up with the list discussions in 
the middle of that flood of JIRA messages?


Is everybody routing JIRAs to a separate folder? I'm finding it 
difficult to see through the traffic without doing that.


Thoughts? Can we improve this to make it easier for people to follow?


I know from my perspective, the volume of Tuscany and Geronimo lists are 
huge. Easily 100 to 200 messages a day.


I use filtering of my mail reader to help sort the messages. I color 
Tuscany messages red and Geronimo black. I put the JIRA traffic to its 
own folder, with JIRA open, close and comments to subfolders.


It is ironic, but the threads I am most interesting in are usually the 
ones with no prefixes: ones that bring up new topics or new issues for 
instance.


--
Thanks, Dan Becker

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

Re: Can't get build.xml to work with calculator-distributed

[Simon Laws]

On Thu, Mar 20, 2008 at 12:56 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Thu, Mar 20, 2008 at 7:46 AM, Jean-Sebastien Delfino <
> [EMAIL PROTECTED]> wrote:
>
> > Luciano Resende wrote:
> > > Do you still see issues after revision #639171 ? If so, could you
> > > please give me the names of missing jars ? I have tried to capture the
> > > differences in [1]
> > >
> > > [1]
> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Release+-+Java+SCA+1.2#Release-JavaSCA1.2-Modulesincludedinthedistribution
> > >
> > > On Wed, Mar 19, 2008 at 11:29 PM, Jean-Sebastien Delfino
> > > <[EMAIL PROTECTED]> wrote:
> > >> Simon Laws wrote:
> > >>  > On Wed, Mar 19, 2008 at 5:57 PM, Jean-Sebastien Delfino <
> > >>  > [EMAIL PROTECTED]> wrote:
> > >>  >
> > >>  >> Simon Laws wrote:
> > >>  >>> I'm trying to run the calculator-distribute sample with the
> > workspace
> > >>  >>> changes from an ant build.xml. I'm getting
> > >>  >>>
> > >>  >>> runDomain:
> > >>  >>>  [java] 19-Mar-2008 11:23:38
> > >>  >>> org.apache.tuscany.sca.workspace.admin.launcher
> > >>  >>> .DomainAdminLauncher main
> > >>  >>>  [java] INFO: Apache Tuscany SCA Domain Administration
> > starting...
> > >>  >>>  [java] 19-Mar-2008 11:23:39
> > >>  >>> org.apache.tuscany.sca.workspace.admin.launcher
> > >>  >>> .DomainAdminLauncherUtil collectJARFiles
> > >>  >>>  [java] INFO: Runtime classpath: 153 JARs from
> > C:\simon\tuscany\sca-
> > >>  >>> java-1.2
> > >>  >>> \distribution\target\apache-
> > >>  >>> tuscany-sca-1.2-incubating-SNAPSHOT.dir\tuscany-sca-
> > >>  >>> 1.2-incubating-SNAPSHOT\lib
> > >>  >>>  [java] 19-Mar-2008 11:23:39
> > >>  >>> org.apache.tuscany.sca.workspace.admin.launcher
> > >>  >>> .DomainAdminLauncher main
> > >>  >>>  [java] SEVERE: SCA Domain Administration could not be
> > started
> > >>  >>>  [java] java.lang.ClassNotFoundException:
> > >>  >>> org.apache.tuscany.sca.workspace.a
> > >>  >>> dmin.launcher.DomainAdminLauncherBootstrap
> > >>  >>>  [java] at java.lang.Class.forName(Class.java:163)
> > >>  >>>  [java] at
> > >>  >>> org.apache.tuscany.sca.workspace.admin.launcher.DomainAdminLa
> > >>  >>> uncher.main(DomainAdminLauncher.java:53)
> > >>  >>>  [java] at node.LaunchDomain.main(LaunchDomain.java:30)
> > >>  >>>  [java] Exception in thread "main"
> > java.lang.ClassNotFoundException:
> > >>  >>> org.apa
> > >>  >>>
> > che.tuscany.sca.workspace.admin.launcher.DomainAdminLauncherBootstrap
> > >>  >>>  [java] at java.lang.Class.forName(Class.java:163)
> > >>  >>>  [java] at
> > >>  >>> org.apache.tuscany.sca.workspace.admin.launcher.DomainAdminLa
> > >>  >>> uncher.main(DomainAdminLauncher.java:53)
> > >>  >>>  [java] at node.LaunchDomain.main(LaunchDomain.java:30)
> > >>  >>>  [java] Java Result: 1
> > >>  >>>
> > >>  >>> Now the classpath looks ok to me in that it includes the tuscany
> > >>  >> manifest
> > >>  >>> jar so should have all the dependencies.
> > >>  >> Does the manifest reference
> > tuscany-workspace-admin-1.2-incubating.jar?
> > >>  >>
> > >>  >> The distribution I built yesterday didn't have it, but I saw some
> > >>  >> commits from Luciano changing the distro assembly files
> > yesterday...
> > >>  >>
> > >>  >> --
> > >>  >> Jean-Sebastien
> > >>  >>
> > >>  >>
> > -
> > >>  >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>  >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>  >>
> > >>  >>
> > >>  > Yeah, I should have said that I made those changes locally. The
> > manifest
> > >>  > references the jars. Should is still work with a reference to the
> > manifest
> > >>  > jar or do I need to go and set TUSCANY_HOME which is mentioned in
> > the code.
> > >>  > If it should work as is I'll investigate more. I just didn't want
> > to spend
> > >>  > the time until I knew that I was going in the right direction.
> > >>  >
> > >>  > Simon
> > >>  >
> > >>
> > >>  I started to fix this issue in revision r639167 (trunk) and r639170
> > (1.2
> > >>  branch) although I'm still having problems with tuscany-sca-manifest
> > as
> > >>  it's missing a number of JARs.
> > >>
> > >>  As a result of these changes the domain admin app can now be started
> > as:
> > >>  java -jar .../modules/tuscany-node2-launcher-1.2-incubating.jardomain
> > >>
> > >>  --
> > >>
> > >>
> > >> Jean-Sebastien
> > >>
> >
> > The maintenance of manifest/pom.xml and bundle/pom.xml is really error
> > prone :(
> >
> > I fixed the errors I could see in these poms, added some missing JARs
> > and removed obsolete references to the old feed binding JARs.
> >
> > I also fixed incorrect class names in calculator-distributed/build.xml.
> >
> > I am able to start the domain and nodes from calculator-distributed with
> > these fixes (SVN revision r639187) but then I'm seeing a weird NPE in
> > the SDO runtime:
> >
> >  [java] Caused by: java.lang.NullPointerExcept

Re: Alias Name Support in Tuscany SDO

[Frank Budinsky]

It's not sufficient just to add a new aliasName to the list. You'd also 
need to push the change back down to the EAnnotation, from which the list 
contents is derived:

  public List getAliasNames(EModelElement modelElement) {
EAnnotation eAnnotation = getAnnotation(modelElement, false);
List list = null;
if (eAnnotation != null) {
  String aliasNames = (String)eAnnotation.getDetails().get(
"aliasNames");
  if (aliasNames != null) {
list = new ArrayList();
StringTokenizer st = new StringTokenizer(aliasNames, " ");
while (st.hasMoreTokens()) {
  String t = st.nextToken();
  list.add(t);
}
  }
}
return list;
  }

Frank.




"David Adcox" <[EMAIL PROTECTED]> 
03/20/2008 08:22 AM
Please respond to
tuscany-dev@ws.apache.org


To
tuscany-dev@ws.apache.org
cc

Subject
Alias Name Support in Tuscany SDO






Currently, alias name support is disabled in SDO, intentionally.  The
SDOHelperImpl.addAliasName(Type,String) and
SDOHelperImpl.addAliasName(Property,String) throw an
UnsupportedOperationException when called.  Does this function still
need to be disabled?  When I remove these guards, my test cases seem
to function properly.

-
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] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2097:


The cachedir folder will be coming from the Jython script engine. I don't think 
we can control the name but the location can be controlled by setting a system 
property, python.cachedir, see 
http://www.jython.org/Project/userguide.html#registry-properties. we don't get 
that when running standalone as the default that gets used isn't writable so it 
fails to be created.

> Build errors in itest/osgi-tuscany
> --
>
> Key: TUSCANY-2097
> URL: https://issues.apache.org/jira/browse/TUSCANY-2097
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA OSGi Integration
>Affects Versions: Java-SCA-Next
> Environment: Windows, Sun JDK 1.5.0_14
>Reporter: Simon Nash
> Fix For: Java-SCA-Next
>
> Attachments: jira2097.log
>
>
> Here is a summary of the build errors I am seeing.  I will attach my full 
> build log to this JIRA.
> 1. revision.location error creating archive.  This seems to show up on
>every test, and it does not seem to cause a hard failure in the test.
> java.io.FileNotFoundException: 
> F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-
> test\.felix.test\bundle1\version0.0\revision.location (The system cannot find 
> th
> e file specified)
> ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. 
> (ja
> va.io.FileNotFoundException: 
> F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te
> st\.felix.test\bundle1\version0.0\revision.location (The system cannot find 
> the
> file specified))
> 2. InvocationTargetException in CalculatorRMIReferencetestCase.
> java.lang.reflect.InvocationTargetException
> . 
> Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested 
> ex
> ception is:
> java.net.BindException: Address already in use: JVM_Bind
> 3. Various errors in testOSGiTuscany_BindingWS
> -> ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete 
> archi
> ve directory - 
> F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test
> \bundle5
> java.util.zip.ZipException: The system cannot find the file specified
> org.osgi.framework.BundleException: Could not create bundle object.
> .
> Caused by: java.util.zip.ZipException: The system cannot find the file 
> specified

-- 
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: Alias Name Support in Tuscany SDO

[kelvin goodson]

I traced back the origins of the commented out line [1],  and it was
introduced in commented out form (in a different file). That would tend to
suggest that it was there as a reminder of the right thing to do one other
infrastructure was in place,  rather than being commented out  because it
wasn't right.  If uncommenting this  line causes  the right kind of
behaviour and does not introduce other test errors,  then I guess that more
recent changes have made this line of code viable.


[1]
http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/util/SDOUtil.java?r1=394728&r2=396004&pathrev=396004


On 20/03/2008, David Adcox <[EMAIL PROTECTED]> wrote:
>
> Currently, alias name support is disabled in SDO, intentionally.  The
> SDOHelperImpl.addAliasName(Type,String) and
> SDOHelperImpl.addAliasName(Property,String) throw an
> UnsupportedOperationException when called.  Does this function still
> need to be disabled?  When I remove these guards, my test cases seem
> to function properly.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: New dependency on Drools

[Simon Laws]

On Thu, Mar 20, 2008 at 1:04 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> I've just committed the patch from TUSCANY-2099. The patch is a few more
> steps on the way to getting the workpool demo running with the latest code
> and it introduces a new dependency on Drools. It's ASL2 licenses but I want
> to call it out here in case anyone has any concerns.
>
> Thanks
>
> Simon
>

I should have said this only affects trunk and is not a 1.2 dependency.

Simon

[jira] Commented: (TUSCANY-2099) Porting Workpool-Distributed demo to current.

[Simon Laws (JIRA)]

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

Simon Laws commented on TUSCANY-2099:
-

Hi Girogio. I've committed the patch. It's difficult to comment in detail until 
we have the code working. What I was wondering though is whether new components 
really need to be installed dynamically, with all the code complexity involved, 
or whether the same effect can be produced by relying on separate, for example, 
conversational, instances of the same component for running jobs. What I'm not 
clear on is whether 1) all of the components you start are all of the same type 
and just run jobs or whether 2) the jobs them selves are components. Looking at 
the code it seems that 1) is the case. Anyhow I'm not suggesting you change the 
design on the fly but there may be some opportunities for simplification down 
the line. 

Simon

> Porting Workpool-Distributed demo to current.
> -
>
> Key: TUSCANY-2099
> URL: https://issues.apache.org/jira/browse/TUSCANY-2099
> Project: Tuscany
>  Issue Type: New Feature
>Reporter: Giorgio Zoppi
>Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: firstpatch.diff
>
>
> This is the first patch to adapt workpool demo to current. Still it doens't 
> compile.

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

New dependency on Drools

[Simon Laws]

I've just committed the patch from TUSCANY-2099. The patch is a few more
steps on the way to getting the workpool demo running with the latest code
and it introduces a new dependency on Drools. It's ASL2 licenses but I want
to call it out here in case anyone has any concerns.

Thanks

Simon

Re: Can't get build.xml to work with calculator-distributed

[Simon Laws]

On Thu, Mar 20, 2008 at 7:46 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Luciano Resende wrote:
> > Do you still see issues after revision #639171 ? If so, could you
> > please give me the names of missing jars ? I have tried to capture the
> > differences in [1]
> >
> > [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Release+-+Java+SCA+1.2#Release-JavaSCA1.2-Modulesincludedinthedistribution
> >
> > On Wed, Mar 19, 2008 at 11:29 PM, Jean-Sebastien Delfino
> > <[EMAIL PROTECTED]> wrote:
> >> Simon Laws wrote:
> >>  > On Wed, Mar 19, 2008 at 5:57 PM, Jean-Sebastien Delfino <
> >>  > [EMAIL PROTECTED]> wrote:
> >>  >
> >>  >> Simon Laws wrote:
> >>  >>> I'm trying to run the calculator-distribute sample with the
> workspace
> >>  >>> changes from an ant build.xml. I'm getting
> >>  >>>
> >>  >>> runDomain:
> >>  >>>  [java] 19-Mar-2008 11:23:38
> >>  >>> org.apache.tuscany.sca.workspace.admin.launcher
> >>  >>> .DomainAdminLauncher main
> >>  >>>  [java] INFO: Apache Tuscany SCA Domain Administration
> starting...
> >>  >>>  [java] 19-Mar-2008 11:23:39
> >>  >>> org.apache.tuscany.sca.workspace.admin.launcher
> >>  >>> .DomainAdminLauncherUtil collectJARFiles
> >>  >>>  [java] INFO: Runtime classpath: 153 JARs from
> C:\simon\tuscany\sca-
> >>  >>> java-1.2
> >>  >>> \distribution\target\apache-
> >>  >>> tuscany-sca-1.2-incubating-SNAPSHOT.dir\tuscany-sca-
> >>  >>> 1.2-incubating-SNAPSHOT\lib
> >>  >>>  [java] 19-Mar-2008 11:23:39
> >>  >>> org.apache.tuscany.sca.workspace.admin.launcher
> >>  >>> .DomainAdminLauncher main
> >>  >>>  [java] SEVERE: SCA Domain Administration could not be started
> >>  >>>  [java] java.lang.ClassNotFoundException:
> >>  >>> org.apache.tuscany.sca.workspace.a
> >>  >>> dmin.launcher.DomainAdminLauncherBootstrap
> >>  >>>  [java] at java.lang.Class.forName(Class.java:163)
> >>  >>>  [java] at
> >>  >>> org.apache.tuscany.sca.workspace.admin.launcher.DomainAdminLa
> >>  >>> uncher.main(DomainAdminLauncher.java:53)
> >>  >>>  [java] at node.LaunchDomain.main(LaunchDomain.java:30)
> >>  >>>  [java] Exception in thread "main"
> java.lang.ClassNotFoundException:
> >>  >>> org.apa
> >>  >>>
> che.tuscany.sca.workspace.admin.launcher.DomainAdminLauncherBootstrap
> >>  >>>  [java] at java.lang.Class.forName(Class.java:163)
> >>  >>>  [java] at
> >>  >>> org.apache.tuscany.sca.workspace.admin.launcher.DomainAdminLa
> >>  >>> uncher.main(DomainAdminLauncher.java:53)
> >>  >>>  [java] at node.LaunchDomain.main(LaunchDomain.java:30)
> >>  >>>  [java] Java Result: 1
> >>  >>>
> >>  >>> Now the classpath looks ok to me in that it includes the tuscany
> >>  >> manifest
> >>  >>> jar so should have all the dependencies.
> >>  >> Does the manifest reference
> tuscany-workspace-admin-1.2-incubating.jar?
> >>  >>
> >>  >> The distribution I built yesterday didn't have it, but I saw some
> >>  >> commits from Luciano changing the distro assembly files
> yesterday...
> >>  >>
> >>  >> --
> >>  >> Jean-Sebastien
> >>  >>
> >>  >>
> -
> >>  >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>  >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>  >>
> >>  >>
> >>  > Yeah, I should have said that I made those changes locally. The
> manifest
> >>  > references the jars. Should is still work with a reference to the
> manifest
> >>  > jar or do I need to go and set TUSCANY_HOME which is mentioned in
> the code.
> >>  > If it should work as is I'll investigate more. I just didn't want to
> spend
> >>  > the time until I knew that I was going in the right direction.
> >>  >
> >>  > Simon
> >>  >
> >>
> >>  I started to fix this issue in revision r639167 (trunk) and r639170 (
> 1.2
> >>  branch) although I'm still having problems with tuscany-sca-manifest
> as
> >>  it's missing a number of JARs.
> >>
> >>  As a result of these changes the domain admin app can now be started
> as:
> >>  java -jar .../modules/tuscany-node2-launcher-1.2-incubating.jar domain
> >>
> >>  --
> >>
> >>
> >> Jean-Sebastien
> >>
>
> The maintenance of manifest/pom.xml and bundle/pom.xml is really error
> prone :(
>
> I fixed the errors I could see in these poms, added some missing JARs
> and removed obsolete references to the old feed binding JARs.
>
> I also fixed incorrect class names in calculator-distributed/build.xml.
>
> I am able to start the domain and nodes from calculator-distributed with
> these fixes (SVN revision r639187) but then I'm seeing a weird NPE in
> the SDO runtime:
>
>  [java] Caused by: java.lang.NullPointerException
>  [java] at
> commonj.sdo.impl.HelperProvider.getDefaultContext(HelperProvider.java:379)
>  [java] at
> org.apache.tuscany.sca.databinding.sdo.SDODataBinding.introspect(
> SDODataBinding.java:61)
>  [java] at
>
> org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBind

[jira] Updated: (TUSCANY-2098) Bidirectional properties are not working in XSD2JavaGenerator

[Surinder Pal Singh Bindra (JIRA)]

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

Surinder Pal Singh Bindra updated TUSCANY-2098:
---

Attachment: XmlDMSImpl.java
XmlDMS.java

> Bidirectional properties are not working in XSD2JavaGenerator
> -
>
> Key: TUSCANY-2098
> URL: https://issues.apache.org/jira/browse/TUSCANY-2098
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0
>Reporter: Surinder Pal Singh Bindra
>Priority: Blocker
> Attachments: library.xsd, libraryDataGraphGenerated.xml, 
> SdoClient.java, XmlDMS.java, XmlDMSImpl.java
>
>
> Bidirectional relations seems to be broken in XSD2JavaGenerator. It generates 
> code which can't be compiled. Here is the sample schema.
> 
> http://www.generated.example.sdo.org/Library"; 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
> xmlns:sdoXML="commonj.sdo/xml" 
> xmlns:sdoJava="commonj.sdo/java" xmlns:sdo="commonj.sdo" 
> xmlns:lib="http://www.generated.example.sdo.org/Library";
> sdoJava:package="org.sdo.example.generated.library">
> 
>  
>   
>   
>   
>   
>sdoXML:oppositeProperty="books" sdoXML:propertyType="lib:Writer"/>
>   
>   
>
>   
>
>maxOccurs="unbounded" sdoXML:oppositeProperty="author" 
> sdoXML:propertyType="lib:Book"/>
>   
>   
>   
> 
>   
>minOccurs="0" maxOccurs="unbounded" />
>maxOccurs="unbounded" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 

-- 
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-2098) Bidirectional properties are not working in XSD2JavaGenerator

[Surinder Pal Singh Bindra (JIRA)]

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

Surinder Pal Singh Bindra updated TUSCANY-2098:
---

Attachment: (was: library.xsd)

> Bidirectional properties are not working in XSD2JavaGenerator
> -
>
> Key: TUSCANY-2098
> URL: https://issues.apache.org/jira/browse/TUSCANY-2098
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0
>Reporter: Surinder Pal Singh Bindra
>Priority: Blocker
> Attachments: library.xsd, libraryDataGraphGenerated.xml, 
> SdoClient.java
>
>
> Bidirectional relations seems to be broken in XSD2JavaGenerator. It generates 
> code which can't be compiled. Here is the sample schema.
> 
> http://www.generated.example.sdo.org/Library"; 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
> xmlns:sdoXML="commonj.sdo/xml" 
> xmlns:sdoJava="commonj.sdo/java" xmlns:sdo="commonj.sdo" 
> xmlns:lib="http://www.generated.example.sdo.org/Library";
> sdoJava:package="org.sdo.example.generated.library">
> 
>  
>   
>   
>   
>   
>sdoXML:oppositeProperty="books" sdoXML:propertyType="lib:Writer"/>
>   
>   
>
>   
>
>maxOccurs="unbounded" sdoXML:oppositeProperty="author" 
> sdoXML:propertyType="lib:Book"/>
>   
>   
>   
> 
>   
>minOccurs="0" maxOccurs="unbounded" />
>maxOccurs="unbounded" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 

-- 
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: Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor

[Venkata Krishnan]

Hi Sebastien,

Here is a snippet from
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy-transaction/src/main/resources/org/apache/tuscany/sca/policy/transaction/definitions.xml

- definitions.xml -

http://www.osoa.org/xmlns/sca/1.0"; targetNamespace="
http://www.osoa.org/xmlns/sca/1.0";
xmlns:sca="http://www.osoa.org/xmlns/sca/1.0"; xmlns:tuscany="
http://tuscany.apache.org/xmlns/sca/1.0";>


Used to indicate the transaction environment desired by
a component implementation.




Used to indicate that a component implementation requires a
managed global transaction.





Used to indicate that a component implementation requires a
managed local transaction.



..

---

Over here, the intents "managedTransaction.global" and "
managedTransaction.local" are qualified intents with "managedTransaction"
being the qualifiable intent.  Since we have decided that the 'name'
attribute of an 'intent' element is going to be NCName we end up forcing the
qualifiable intent to also belong to the targetnamespace.  If it belonged to
namespace other than the target, then we'd have to deal with how we can
represent this for example we could resort to ...



Used to indicate that a component implementation requires a
managed global transaction.



where we could say that managedTransaction is an intent defined under the
namespace that the prefix 'tuscany' points to.   But if we did this, the
'name' attribute must be read a QName which ends us in a contradiction.

Thanks

- Venkat



On Thu, Mar 20, 2008 at 2:14 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Venkata Krishnan wrote:
> > Hi Sebastien,
> >
> > Thanks.  Please find my comments inline.  Not much though :)
> >
> > On Tue, Mar 18, 2008 at 3:46 AM, Jean-Sebastien Delfino <
> > [EMAIL PROTECTED]> wrote:
> >
> >> Venkata Krishnan wrote:
>  2) Unless I'm missing something, I don't think that you need to set
> the
>  targetNamespace of QualifiedIntent.qualifiableIntents, as it looks
> like
>  it's already read as a QName from the XML stream (and this QName does
>  not have to be in the current targetNamespace).
> >>>
> >>> First, I think that the Qualifiable intent needs to be in the current
> >>> namespace since I I am not sure and the specs does not mention either,
> >> on
> >>> how we could represent a qualified intent whose qualifiable intent
> >> belongs
> >>> to a different namespace.  So going with the assumption, in this
> context
> >> the
> >>> qualifiable intent needs to be assigned the targetnamspace. Only then
> >> would
> >>> it be correctly resolved during the resolution phase.
> >>>
> >> Then I don't understand this code:
> >> PolicyIntentProcessor:74
> >>qualifiableIntent.setName(getQNameValue(reader,
> >>policyIntentName.substring(0, qualifierIndex)));
> >>
> >> which reads a QName from the XMLStreamReader.
> >>
> >> Either (a) the qualifiableIntent is always in the target namespace, and
> >> then it's name is defined as an NCName and we shouldn't be trying to
> >> read it as a QName, or (b) the qualifiable intent name is actually
> >> defined as a QName and then it can belong to another namespace.
> >>
> >> If I understand it correctly, the policy-xsd defines these names as
> >> QNames, leading me to believe that (b) is the correct option.
> >
> >
> > Given the context of disussion in this thread (a) seems to be what it
> should
> > be.  When cleaning up I missed out this line and I will fix it rightaway
> > :(.  But it ends up working because the name is reset with the
> > targetnamespace later.  Why I say (a) is because we'd then have
> consistency
> > with all intent names being NCNames.  Ofcourse, this means that the
> > qualifiable intents should also be from the same namespace.
> >
> > If we allowed intent names to be QNames then (b) would apply and we have
> the
> > freedom of having qualifiable intents belonging to a different namespace
> > than the targetnamespace.  But that will get us back to the bunch of
> issues
> > that has been discussed in
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28653.html.
> >
> > I guess it can't be that qualified intents alone have names that are
> QNames
> > and the rest will be NCNames.
> >
> > Thanks
> >
> > - Venkat
> >
>
> I'm still not sure I understand, I am assuming that when we read XML
> declarations:
>
> - declarations of type  get turned into a QName
> with ns = targetNamespace, localPart = anNCName
>
> - declarations of type  just get the
> QName as-is, and do not assume that it belongs to the document's
> targetNamespace.
>
> But I'm probably missing something as it also seems to make sense to
> restrict intent qualifiers to be in the same namespace 

[jira] Updated: (TUSCANY-2098) Bidirectional properties are not working in XSD2JavaGenerator

[Surinder Pal Singh Bindra (JIRA)]

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

Surinder Pal Singh Bindra updated TUSCANY-2098:
---

Attachment: SdoClient.java
libraryDataGraphGenerated.xml
library.xsd

> Bidirectional properties are not working in XSD2JavaGenerator
> -
>
> Key: TUSCANY-2098
> URL: https://issues.apache.org/jira/browse/TUSCANY-2098
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0
>Reporter: Surinder Pal Singh Bindra
>Priority: Blocker
> Attachments: library.xsd, library.xsd, libraryDataGraphGenerated.xml, 
> SdoClient.java
>
>
> Bidirectional relations seems to be broken in XSD2JavaGenerator. It generates 
> code which can't be compiled. Here is the sample schema.
> 
> http://www.generated.example.sdo.org/Library"; 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
> xmlns:sdoXML="commonj.sdo/xml" 
> xmlns:sdoJava="commonj.sdo/java" xmlns:sdo="commonj.sdo" 
> xmlns:lib="http://www.generated.example.sdo.org/Library";
> sdoJava:package="org.sdo.example.generated.library">
> 
>  
>   
>   
>   
>   
>sdoXML:oppositeProperty="books" sdoXML:propertyType="lib:Writer"/>
>   
>   
>
>   
>
>maxOccurs="unbounded" sdoXML:oppositeProperty="author" 
> sdoXML:propertyType="lib:Book"/>
>   
>   
>   
> 
>   
>minOccurs="0" maxOccurs="unbounded" />
>maxOccurs="unbounded" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 

-- 
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] Reopened: (TUSCANY-2098) Bidirectional properties are not working in XSD2JavaGenerator

[Surinder Pal Singh Bindra (JIRA)]

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

Surinder Pal Singh Bindra reopened TUSCANY-2098:



Hi Kelvin Goodson ,
  Looks like even dynamic SDO api's do not work in this case. I am attaching 
the client code, the schema file and the generated xml file. Just notice that 
new book is not getting appended at the books node under  library node, but it 
is getting added under author node.


> Bidirectional properties are not working in XSD2JavaGenerator
> -
>
> Key: TUSCANY-2098
> URL: https://issues.apache.org/jira/browse/TUSCANY-2098
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0
>Reporter: Surinder Pal Singh Bindra
>Priority: Blocker
> Attachments: library.xsd
>
>
> Bidirectional relations seems to be broken in XSD2JavaGenerator. It generates 
> code which can't be compiled. Here is the sample schema.
> 
> http://www.generated.example.sdo.org/Library"; 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
> xmlns:sdoXML="commonj.sdo/xml" 
> xmlns:sdoJava="commonj.sdo/java" xmlns:sdo="commonj.sdo" 
> xmlns:lib="http://www.generated.example.sdo.org/Library";
> sdoJava:package="org.sdo.example.generated.library">
> 
>  
>   
>   
>   
>   
>sdoXML:oppositeProperty="books" sdoXML:propertyType="lib:Writer"/>
>   
>   
>
>   
>
>maxOccurs="unbounded" sdoXML:oppositeProperty="author" 
> sdoXML:propertyType="lib:Book"/>
>   
>   
>   
> 
>   
>minOccurs="0" maxOccurs="unbounded" />
>maxOccurs="unbounded" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 

-- 
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: Build error on java\sca -- Error extracting plugin descriptor: 'No mojo descriptors found in plugin.

[Simon Laws]

On Thu, Mar 20, 2008 at 8:35 AM, Vamsavardhana Reddy <[EMAIL PROTECTED]>
wrote:

> Forgot to mention in my earlier post.  I am using Maven 2.0.6, Sun JDK
> 1.5.0on Windows XP.
>
> ++Vamsi
>
> On Thu, Mar 20, 2008 at 2:02 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]>
> wrote:
>
> > I am hitting a build error on trunk, i.e. java/sca.  The error message
> is
> > "Error extracting plugin descriptor: 'No mojo descriptors found in
> plugin."
> > Any hints on how to resolve this problem?  Output from command window is
> > given below.
> >
> >
> > [INFO]
> >
> -
> > ---
> > [INFO] Building Apache Tuscany SCA Definitions Shade Transformer for
> > Distributio
> > n Bundle
> > [INFO]task-segment: [install]
> > [INFO]
> >
> -
> > ---
> > [INFO] [plugin:descriptor]
> > [INFO] Using 2 extractors.
> > [INFO] Applying extractor for language: java
> > [INFO] Extractor for language: java found 0 mojo descriptors.
> > [INFO] Applying extractor for language: bsh
> > [INFO] Extractor for language: bsh found 0 mojo descriptors.
> > [INFO]
> > 
> > [ERROR] BUILD ERROR
> > [INFO]
> > 
> > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in
> > plugin.
> > '
> >
> > [INFO]
> > 
> > [INFO] For more information, run Maven with the -e switch
> > [INFO]
> > 
> > [INFO] Total time: 7 minutes 56 seconds
> > [INFO] Finished at: Thu Mar 20 13:50:19 IST 2008
> > [INFO] Final Memory: 63M/118M
> > [INFO]
> > 
> >
>

Hi Vamsi

I'm not seeing this problem. Are you sure you want to build the
distribution?

Simon

Alias Name Support in Tuscany SDO

[David Adcox]

Currently, alias name support is disabled in SDO, intentionally.  The
SDOHelperImpl.addAliasName(Type,String) and
SDOHelperImpl.addAliasName(Property,String) throw an
UnsupportedOperationException when called.  Does this function still
need to be disabled?  When I remove these guards, my test cases seem
to function properly.

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

Re: Keeping up with the dev list and the flood of JIRA messages

[Venkata Krishnan]

Hi,

Yes its a bit distracting but then I find it ok since I'd like to know as
much of the JIRAs as the other discussions.  I don't filter them out thro
mail filters coz am a bit apprehensive that at times I might entirely ignore
what goes in there.

The JIRAs are the ones I read out first and clear out of the way.  I then
run thro the other mails.

- Venkat


On Thu, Mar 20, 2008 at 3:10 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Hi,
>
> Just curious, are people able to keep up with the list discussions in
> the middle of that flood of JIRA messages?
>
> Is everybody routing JIRAs to a separate folder? I'm finding it
> difficult to see through the traffic without doing that.
>
> Thoughts? Can we improve this to make it easier for people to follow?
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[jira] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany

[Rajini Sivaram (JIRA)]

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

Rajini Sivaram commented on TUSCANY-2097:
-

Simon,

Thank you for trying out the latest build. "cachedir" directory is created by 
the calculator-script sample when it is running under OSGi. I think it is 
created by one of the script engines, but I couldn't figure out if the 
directory name is specified somewhere in Tuscany. I also have no idea why the 
directory is not created when the sample is run outside of OSGi. Does anyone 
have any clues?


> Build errors in itest/osgi-tuscany
> --
>
> Key: TUSCANY-2097
> URL: https://issues.apache.org/jira/browse/TUSCANY-2097
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA OSGi Integration
>Affects Versions: Java-SCA-Next
> Environment: Windows, Sun JDK 1.5.0_14
>Reporter: Simon Nash
> Fix For: Java-SCA-Next
>
> Attachments: jira2097.log
>
>
> Here is a summary of the build errors I am seeing.  I will attach my full 
> build log to this JIRA.
> 1. revision.location error creating archive.  This seems to show up on
>every test, and it does not seem to cause a hard failure in the test.
> java.io.FileNotFoundException: 
> F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-
> test\.felix.test\bundle1\version0.0\revision.location (The system cannot find 
> th
> e file specified)
> ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. 
> (ja
> va.io.FileNotFoundException: 
> F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te
> st\.felix.test\bundle1\version0.0\revision.location (The system cannot find 
> the
> file specified))
> 2. InvocationTargetException in CalculatorRMIReferencetestCase.
> java.lang.reflect.InvocationTargetException
> . 
> Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested 
> ex
> ception is:
> java.net.BindException: Address already in use: JVM_Bind
> 3. Various errors in testOSGiTuscany_BindingWS
> -> ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete 
> archi
> ve directory - 
> F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test
> \bundle5
> java.util.zip.ZipException: The system cannot find the file specified
> org.osgi.framework.BundleException: Could not create bundle object.
> .
> Caused by: java.util.zip.ZipException: The system cannot find the file 
> specified

-- 
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-2105) NoClassDefFoundError: org/osgi/framework/BundleException running osgi-supplychain

[Rajini Sivaram (JIRA)]

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

Rajini Sivaram commented on TUSCANY-2105:
-

Luciano,

I modified all the OSGi modules to use Felix 1.0.3 rather than 1.0.1 in the 1.2 
branch. Sorry, I wasn't trying to overwrite your changes, but the we had some 
fixes for classloading and deadlocks in Felix that went into 1.0.3. I hope you 
don't mind.

- Rajini

> NoClassDefFoundError: org/osgi/framework/BundleException running 
> osgi-supplychain
> -
>
> Key: TUSCANY-2105
> URL: https://issues.apache.org/jira/browse/TUSCANY-2105
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-1.2
>Reporter: Luciano Resende
>Assignee: Luciano Resende
>Priority: Blocker
> Fix For: Java-SCA-1.2
>
>
> run:
>  [java] Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/osgi/framework/BundleException
>  [java] at 
> org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver.resolveModel(OSGiBundleReferenceModelResolver.java:89)
>  [java] at 
> org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:150)
>  [java] at 
> org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:207)
>  [java] at 
> org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:74)
>  [java] at 
> org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:252)
>  [java] at 
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109)
>  [java] at 
> org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:248)
>  [java] at 
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:876)
>  [java] at 
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:80)
>  [java] at 
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109)
>  [java] at 
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:129)
>  [java] at 
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:52)
>  [java] at 
> org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
>  [java] at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:464)
>  [java] at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:348)
>  [java] at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:161)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:272)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:155)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:109)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
>  [java] at 
> supplychain.SupplyChainClient.main(SupplyChainClient.java:33)
>  [java] Java Result: 1

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


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

[jira] Resolved: (TUSCANY-2110) ChangeSummary's getOldContainer() and getOldContainmentProperty() methods are not working correctly.

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson resolved TUSCANY-2110.
-

Resolution: Invalid

If you set the containment of parentProp2 to true the test passes

> ChangeSummary's getOldContainer() and getOldContainmentProperty() methods are 
> not working correctly. 
> -
>
> Key: TUSCANY-2110
> URL: https://issues.apache.org/jira/browse/TUSCANY-2110
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: Test2110.java
>
>
> I am unable to get ChangeSummary to return a value using the 
> getOldContainer() method or the getOldContainmentProperty() method.  I think 
> there may be an issue when using a three-tier model.  What I mean by this is 
> I have created a top level 'root' type that contains two unique 'parent' 
> types.  Each of the parent types has a unique property that can contain a 
> child type.  When I set the child to be contained by parent2, then start 
> logging on the ChangeSummary, then set the containment to parent1, I am not 
> able to retrieve the old parent container nor the old containment property.
> I will attach a test case.

-- 
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: Keeping up with the dev list and the flood of JIRA messages

[ant elder]

On Wed, Mar 19, 2008 at 9:40 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Hi,
>
> Just curious, are people able to keep up with the list discussions in
> the middle of that flood of JIRA messages?
>
> Is everybody routing JIRAs to a separate folder? I'm finding it
> difficult to see through the traffic without doing that.
>
> Thoughts? Can we improve this to make it easier for people to follow?
> --
> Jean-Sebastien
>

I just have them going unfiltered to my inbox and read them all along with
other mail,  I'd do the same if they went somewhere else like the commit
list so it makes little difference to me personally but I completly
understand that less active developers find them a distraction on the dev
list. I agree with what Luciano said, reading the JIRA comments is useful
(essential?) for developers, and that more use of the mail notification
option on the bulk change panels could help.

We discussed this just last month and there wasn't consensus to move them
off the dev list though.

   ...ant

Re: Keeping up with the dev list and the flood of JIRA messages

[Jacek Laskowski]

On Wed, Mar 19, 2008 at 10:40 PM, Jean-Sebastien Delfino
<[EMAIL PROTECTED]> wrote:

>  Just curious, are people able to keep up with the list discussions in
>  the middle of that flood of JIRA messages?

If people filter it out anyway, what about directing the emails to
tuscany-commits with the commit emails?

(I've just noticed Geronimo does this way, but OpenEJB does not - I
personally prefer the later where commit and jira emails go to
commits@ as I can follow the issue itself and its changes in the
source repo)

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

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

Re: Verification Testing

[Vamsavardhana Reddy]

+1

++Vamsi

On Wed, Mar 19, 2008 at 11:10 PM, Kevin Williams <[EMAIL PROTECTED]>
wrote:

> I am thinking of adding a new test bucket specifically for
> verification testing against the specification set.  I believe it
> would add value to the project and may also be a place where
> developers new to Tuscany might contribute.  Does this sound like a
> reasonable idea?
> Thanks,
> --Kevin
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Keeping up with the dev list and the flood of JIRA messages

[kelvin goodson]

I find the RSS feed facility for customised JIRA queries a very helpful way
of keeping up with JIRAs.  It gives much more control than a mail filter
does.  I still get the notifications in my inbox,  but when I want to get a
quick overview of recent activity the RSS feed is preferable.

If you haven't noticed this feature, try following the "issues" or
"comments" link next to "RSS" on for example [1].  This gives you the
opportunity to subscribe to the query in your favourite RSS reader.

Kelvin.

[1]
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=1&status=3&status=4&component=12311542&component=12310660&component=12310973&component=12310802&sorter/field=issuekey&sorter/order=DESC&sorter/field=components&sorter/order=ASC&sorter/field=updated&sorter/order=DESC

On 20/03/2008, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 19, 2008 at 10:14 PM, Raymond Feng <[EMAIL PROTECTED]>
> wrote:
>
> > I have a mail rule/filter set up to route the JIRA messages into a
> > separate
> > folder in my inbox.
> >
> > Thanks,
> > Raymond
> > --
> > From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
> > Sent: Wednesday, March 19, 2008 2:40 PM
> > To: "tuscany-dev" 
> > Subject: Keeping up with the dev list and the flood of JIRA messages
> >
> > > Hi,
> > >
> > > Just curious, are people able to keep up with the list discussions in
> > the
> > > middle of that flood of JIRA messages?
> > >
> > > Is everybody routing JIRAs to a separate folder? I'm finding it
> > difficult
> > > to see through the traffic without doing that.
> > >
> > > Thoughts? Can we improve this to make it easier for people to follow?
> > > --
> > > Jean-Sebastien
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> > I like to see the JIRA coming in on the dev list. I manually filter so
> that I at least get a sense of what's going on.
>
>
> Simon
>

Re: Verification Testing

[Simon Laws]

On Wed, Mar 19, 2008 at 8:26 PM, Dan Becker <[EMAIL PROTECTED]> wrote:

> Simon Nash wrote:
> > Kevin Williams wrote:
> >> I am thinking of adding a new test bucket specifically for
> >> verification testing against the specification set.  I believe it
> >> would add value to the project and may also be a place where
> >> developers new to Tuscany might contribute.  Does this sound like a
> >> reasonable idea?
>
> +1
>
> I think it is very useful and will be a good way to make "piece-of-mind"
> regression tests.
>
> --
> Thanks, Dan Becker
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
+1 excellent idea

Simon

Re: Keeping up with the dev list and the flood of JIRA messages

[Simon Laws]

On Wed, Mar 19, 2008 at 10:14 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> I have a mail rule/filter set up to route the JIRA messages into a
> separate
> folder in my inbox.
>
> Thanks,
> Raymond
> --
> From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 19, 2008 2:40 PM
> To: "tuscany-dev" 
> Subject: Keeping up with the dev list and the flood of JIRA messages
>
> > Hi,
> >
> > Just curious, are people able to keep up with the list discussions in
> the
> > middle of that flood of JIRA messages?
> >
> > Is everybody routing JIRAs to a separate folder? I'm finding it
> difficult
> > to see through the traffic without doing that.
> >
> > Thoughts? Can we improve this to make it easier for people to follow?
> > --
> > Jean-Sebastien
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> I like to see the JIRA coming in on the dev list. I manually filter so
that I at least get a sense of what's going on.

Simon

Re: Build error on java\sca -- Error extracting plugin descriptor: 'No mojo descriptors found in plugin.

[Vamsavardhana Reddy]

Forgot to mention in my earlier post.  I am using Maven 2.0.6, Sun JDK
1.5.0on Windows XP.

++Vamsi

On Thu, Mar 20, 2008 at 2:02 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]>
wrote:

> I am hitting a build error on trunk, i.e. java/sca.  The error message is
> "Error extracting plugin descriptor: 'No mojo descriptors found in plugin."
> Any hints on how to resolve this problem?  Output from command window is
> given below.
>
>
> [INFO]
> -
> ---
> [INFO] Building Apache Tuscany SCA Definitions Shade Transformer for
> Distributio
> n Bundle
> [INFO]task-segment: [install]
> [INFO]
> -
> ---
> [INFO] [plugin:descriptor]
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO] Extractor for language: java found 0 mojo descriptors.
> [INFO] Applying extractor for language: bsh
> [INFO] Extractor for language: bsh found 0 mojo descriptors.
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in
> plugin.
> '
>
> [INFO]
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> 
> [INFO] Total time: 7 minutes 56 seconds
> [INFO] Finished at: Thu Mar 20 13:50:19 IST 2008
> [INFO] Final Memory: 63M/118M
> [INFO]
> 
>

Build error on java\sca -- Error extracting plugin descriptor: 'No mojo descriptors found in plugin.

[Vamsavardhana Reddy]

I am hitting a build error on trunk, i.e. java/sca.  The error message is
"Error extracting plugin descriptor: 'No mojo descriptors found in plugin."
Any hints on how to resolve this problem?  Output from command window is
given below.


[INFO]
-
---
[INFO] Building Apache Tuscany SCA Definitions Shade Transformer for
Distributio
n Bundle
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 0 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error extracting plugin descriptor: 'No mojo descriptors found in
plugin.
'

[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 7 minutes 56 seconds
[INFO] Finished at: Thu Mar 20 13:50:19 IST 2008
[INFO] Final Memory: 63M/118M
[INFO]

[jira] Resolved: (TUSCANY-2107) Multiple exceptions running sample helloworld-ws-service-secure

[Luciano Resende (JIRA)]

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

Luciano Resende resolved TUSCANY-2107.
--

Resolution: Fixed

Fixed.

> Multiple exceptions running sample helloworld-ws-service-secure
> ---
>
> Key: TUSCANY-2107
> URL: https://issues.apache.org/jira/browse/TUSCANY-2107
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-1.2
>Reporter: Luciano Resende
>Priority: Blocker
> Fix For: Java-SCA-1.2
>
>
> run:
>  [java] Mar 18, 2008 10:41:34 PM 
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
>  [java] WARNING: Policy related exception: 
> org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy Intent 
> '{http://www.osoa.org/xmlns/sca/1.0}authentication' is not defined in this 
> domain
>  [java] Mar 18, 2008 10:41:34 PM 
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
>  [java] WARNING: Policy related exception: 
> org.apache.tuscany.sca.policy.util.PolicyValidationException: Policy Intent 
> '{http://www.osoa.org/xmlns/sca/1.0}integrity' is not defined in this domain
>  [java] Exception in thread "main" org.osoa.sca.ServiceRuntimeException: 
> org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.RuntimeException: org.apache.axis2.AxisFault: 
> org/apache/commons/fileupload/FileItemFactory
>  [java] at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
>  [java] at helloworld.HelloWorldServer.main(HelloWorldServer.java:33)
>  [java] Caused by: org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.RuntimeException: org.apache.axis2.AxisFault: 
> org/apache/commons/fileupload/FileItemFactory
>  [java] at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:220)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:109)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
>  [java] ... 2 more
>  [java] Caused by: 
> org.apache.tuscany.sca.core.assembly.ActivationException: 
> java.lang.RuntimeException: org.apache.axis2.AxisFault: 
> org/apache/commons/fileupload/FileItemFactory
>  [java] at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:792)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:218)
>  [java] ... 4 more
>  [java] Caused by: java.lang.RuntimeException: 
> org.apache.axis2.AxisFault: org/apache/commons/fileupload/FileItemFactory
>  [java] at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.(Axis2ServiceProvider.java:159)
>  [java] at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingProvider.(Axis2ServiceBindingProvider.java:90)
>  [java] at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createServiceBindingProvider(Axis2BindingProviderFactory.java:64)
>  [java] at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createServiceBindingProvider(Axis2BindingProviderFactory.java:45)
>  [java] at 
> org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createServiceBindingProvider(DefaultProviderFactoryExtensionPoint.java:227)
>  [java] at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addServiceBindingProvider(CompositeActivatorImpl.java:426)
>  [java] at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:726)
>  [java] at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:784)
>  [java] ... 5 more
>  [java] Caused by: org.apache.axis2.AxisFault: 
> org/apache/commons/fileupload/FileItemFactory
>  [java] at 
> org.apache.tuscany.sca.binding.ws.axis2.TuscanyAxisConfigurator.getAxisConfiguration(TuscanyAxisConfigurator.java:119)
>  [java] at 
> org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:64)
>  [java] at 
> org.apache.tuscany.sca.binding.ws.axis2.TuscanyAxisConfigurator.getConfigurationContext(TuscanyAxisConfigurator.java:71)
>  [java] at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.(Axis2ServiceProvider.java:155)
>  

Re: Can't get build.xml to work with calculator-distributed

[Jean-Sebastien Delfino]

Luciano Resende wrote:

Do you still see issues after revision #639171 ? If so, could you
please give me the names of missing jars ? I have tried to capture the
differences in [1]

[1] 
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Release+-+Java+SCA+1.2#Release-JavaSCA1.2-Modulesincludedinthedistribution

On Wed, Mar 19, 2008 at 11:29 PM, Jean-Sebastien Delfino
<[EMAIL PROTECTED]> wrote:

Simon Laws wrote:
 > On Wed, Mar 19, 2008 at 5:57 PM, Jean-Sebastien Delfino <
 > [EMAIL PROTECTED]> wrote:
 >
 >> Simon Laws wrote:
 >>> I'm trying to run the calculator-distribute sample with the workspace
 >>> changes from an ant build.xml. I'm getting
 >>>
 >>> runDomain:
 >>>  [java] 19-Mar-2008 11:23:38
 >>> org.apache.tuscany.sca.workspace.admin.launcher
 >>> .DomainAdminLauncher main
 >>>  [java] INFO: Apache Tuscany SCA Domain Administration starting...
 >>>  [java] 19-Mar-2008 11:23:39
 >>> org.apache.tuscany.sca.workspace.admin.launcher
 >>> .DomainAdminLauncherUtil collectJARFiles
 >>>  [java] INFO: Runtime classpath: 153 JARs from C:\simon\tuscany\sca-
 >>> java-1.2
 >>> \distribution\target\apache-
 >>> tuscany-sca-1.2-incubating-SNAPSHOT.dir\tuscany-sca-
 >>> 1.2-incubating-SNAPSHOT\lib
 >>>  [java] 19-Mar-2008 11:23:39
 >>> org.apache.tuscany.sca.workspace.admin.launcher
 >>> .DomainAdminLauncher main
 >>>  [java] SEVERE: SCA Domain Administration could not be started
 >>>  [java] java.lang.ClassNotFoundException:
 >>> org.apache.tuscany.sca.workspace.a
 >>> dmin.launcher.DomainAdminLauncherBootstrap
 >>>  [java] at java.lang.Class.forName(Class.java:163)
 >>>  [java] at
 >>> org.apache.tuscany.sca.workspace.admin.launcher.DomainAdminLa
 >>> uncher.main(DomainAdminLauncher.java:53)
 >>>  [java] at node.LaunchDomain.main(LaunchDomain.java:30)
 >>>  [java] Exception in thread "main" java.lang.ClassNotFoundException:
 >>> org.apa
 >>> che.tuscany.sca.workspace.admin.launcher.DomainAdminLauncherBootstrap
 >>>  [java] at java.lang.Class.forName(Class.java:163)
 >>>  [java] at
 >>> org.apache.tuscany.sca.workspace.admin.launcher.DomainAdminLa
 >>> uncher.main(DomainAdminLauncher.java:53)
 >>>  [java] at node.LaunchDomain.main(LaunchDomain.java:30)
 >>>  [java] Java Result: 1
 >>>
 >>> Now the classpath looks ok to me in that it includes the tuscany
 >> manifest
 >>> jar so should have all the dependencies.
 >> Does the manifest reference tuscany-workspace-admin-1.2-incubating.jar?
 >>
 >> The distribution I built yesterday didn't have it, but I saw some
 >> commits from Luciano changing the distro assembly files yesterday...
 >>
 >> --
 >> Jean-Sebastien
 >>
 >> -
 >> To unsubscribe, e-mail: [EMAIL PROTECTED]
 >> For additional commands, e-mail: [EMAIL PROTECTED]
 >>
 >>
 > Yeah, I should have said that I made those changes locally. The manifest
 > references the jars. Should is still work with a reference to the manifest
 > jar or do I need to go and set TUSCANY_HOME which is mentioned in the code.
 > If it should work as is I'll investigate more. I just didn't want to spend
 > the time until I knew that I was going in the right direction.
 >
 > Simon
 >

 I started to fix this issue in revision r639167 (trunk) and r639170 (1.2
 branch) although I'm still having problems with tuscany-sca-manifest as
 it's missing a number of JARs.

 As a result of these changes the domain admin app can now be started as:
 java -jar .../modules/tuscany-node2-launcher-1.2-incubating.jar domain

 --


Jean-Sebastien



The maintenance of manifest/pom.xml and bundle/pom.xml is really error 
prone :(


I fixed the errors I could see in these poms, added some missing JARs 
and removed obsolete references to the old feed binding JARs.


I also fixed incorrect class names in calculator-distributed/build.xml.

I am able to start the domain and nodes from calculator-distributed with 
these fixes (SVN revision r639187) but then I'm seeing a weird NPE in 
the SDO runtime:


 [java] Caused by: java.lang.NullPointerException
 [java] at 
commonj.sdo.impl.HelperProvider.getDefaultContext(HelperProvider.java:379)
 [java] at 
org.apache.tuscany.sca.databinding.sdo.SDODataBinding.introspect(SDODataBinding.java:61)
 [java] at 
org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:191)
 [java] at 
org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:246)

 [java] at
...

It is not specific to calculator-distributed, as I can see the same 
exception in other samples.


Any idea?
--
Jean-Sebastien

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

[jira] Resolved: (TUSCANY-2105) NoClassDefFoundError: org/osgi/framework/BundleException running osgi-supplychain

[Luciano Resende (JIRA)]

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

Luciano Resende resolved TUSCANY-2105.
--

Resolution: Fixed
  Assignee: Luciano Resende

Fixed by porting the Felix dependencies back to 1.0.1 level.

> NoClassDefFoundError: org/osgi/framework/BundleException running 
> osgi-supplychain
> -
>
> Key: TUSCANY-2105
> URL: https://issues.apache.org/jira/browse/TUSCANY-2105
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-1.2
>Reporter: Luciano Resende
>Assignee: Luciano Resende
>Priority: Blocker
> Fix For: Java-SCA-1.2
>
>
> run:
>  [java] Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/osgi/framework/BundleException
>  [java] at 
> org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver.resolveModel(OSGiBundleReferenceModelResolver.java:89)
>  [java] at 
> org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:150)
>  [java] at 
> org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:207)
>  [java] at 
> org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:74)
>  [java] at 
> org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:252)
>  [java] at 
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109)
>  [java] at 
> org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:248)
>  [java] at 
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:876)
>  [java] at 
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:80)
>  [java] at 
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109)
>  [java] at 
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:129)
>  [java] at 
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:52)
>  [java] at 
> org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
>  [java] at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:464)
>  [java] at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:348)
>  [java] at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:161)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:272)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:155)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:109)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
>  [java] at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
>  [java] at 
> supplychain.SupplyChainClient.main(SupplyChainClient.java:33)
>  [java] Java Result: 1

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