Re: IMPORTANT: TLP SVN move tonight

[ant elder]

I hope so yes, but its not yet clear exactly when the DNS changes will
be done. Will let you know as soon as i know anything.

   ...ant

On Mon, Jun 16, 2008 at 11:49 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Thanks for the update. What about our web site? Is it going to be hosted at
> http://tuscany.apache.org soon?
>
> Raymond
> ----------
> From: "ant elder" <[EMAIL PROTECTED]>
> Sent: Monday, June 16, 2008 3:06 PM
> To: "tuscany-dev" 
> Subject: IMPORTANT: TLP SVN move tonight
>
>> The Tuscany SVN should be moving to the TLP location tonight so
>> everyone will need to switch to the new location, which will be
>> https://svn.apache.org/repos/asf/tuscany.
>>
>> You can change your local copy with "svn switch --relocate".
>>
>>  ...ant
>
>

IMPORTANT: TLP SVN move tonight

[ant elder]

The Tuscany SVN should be moving to the TLP location tonight so
everyone will need to switch to the new location, which will be
https://svn.apache.org/repos/asf/tuscany.

You can change your local copy with "svn switch --relocate".

   ...ant

com.example classes included in the databinding extension jars

[ant elder]

I'm having a lot of trouble getting the bundle jar to work in the 1.3 branch
as databinding-jaxb and databinding-jaxb-axiom both include the class
com.example.ipo.jaxb.Address which causes the shade plugiin to fail with a
duplicate class exception. Can anyone see any way to either stop these
classes being included in the databinding jars, or to have the old shade
plugin filter them out (or get the new shade plugin to include all the other
dependencies)? Or if not how about moving the unit tests out into an itest
so the classes don't get included?

   ...ant

Re: [VOTE] Release SDO 1.1.1

[ant elder]

I'm not sure what to do about this. It must be the same building the SDO 1.0
and 1.1 releases right as they use the same EMF releases and no one has
complained about it there, so i wondered about just documenting the issue in
the BUILDING file? Or any other suggestions?

   ...ant

On Thu, Jun 12, 2008 at 1:27 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> Well, after really multiple times (about 5 or 6) I got a sucessful
> build. But how would our users feel by experiencing this issue ?
>
> On Wed, Jun 11, 2008 at 3:35 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > So thats works ok for two, doesn't work for one.
> >
> > Luciano, I had to build a couple of times with -U to get all the emf jars
> > successfully downloaded, have you tried that or can you find any other
> way
> > to get a build through in your environment?
> >
> >...ant
> >
> > On Tue, Jun 10, 2008 at 11:32 AM, Murtaza Goga
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> I built this release last night, built clean.
> >>
> >> -Original Message-
> >> From: ant elder [mailto:[EMAIL PROTECTED]
> >> Sent: Tuesday, June 10, 2008 5:29 AM
> >> To: tuscany-dev@ws.apache.org
> >> Subject: Re: [VOTE] Release SDO 1.1.1
> >>
> >> I'd like to get this voted on and released but nervous to start that
> >> after
> >> Kelvin had trouble getting the emf dependencies, could any one else try
> >> building the tag and seeing if it works or not for them -
> >>
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-R
> >> C2/-
> >> its a small checkout and doesn't take long to build.
> >>
> >>   ...ant
> >>
> >> On Sat, Jun 7, 2008 at 9:15 AM, ant elder <[EMAIL PROTECTED]> wrote:
> >>
> >> > It seems to work fine for me, the binary distribution ends up with a
> >> lib
> >> > folder containing:
> >> >
> >> > backport-util-concurrent-3.0.jar
> >> > codegen-2.2.3.jar
> >> > codegen-ecore-2.2.3.jar
> >> > common-2.2.3.jar
> >> > ecore-2.2.3.jar
> >> > ecore-change-2.2.3.jar
> >> > ecore-xmi-2.2.3.jar
> >> > sample-sdo-1.1.1.jar
> >> > stax-api-1.0.1.jar
> >> > tuscany-sdo-api-r2.1-1.1.1.jar
> >> > tuscany-sdo-impl-1.1.1.jar
> >> > tuscany-sdo-lib-1.1.1.jar
> >> > tuscany-sdo-tools-1.1.1.jar
> >> > wstx-asl-3.2.1.jar
> >> > xsd-2.2.3.jar
> >> >
> >> > I've put the distributions that I get from the 1.1.1-RC2 tag up at
> >> >
> >> http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC2<http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2>
> <http://people.a
> >> pache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2>,
> >> > how do they look?
> >> >
> >> >...ant
> >> >
> >> > On Fri, Jun 6, 2008 at 6:18 PM, kelvin goodson <[EMAIL PROTECTED]
> >
> >> > wrote:
> >> >
> >> >> Hi Luciano,
> >> >>   yes, I added that workaround,  and that satisfied most of the EMF
> >> jars,
> >> >> but not these two. It's odd, the 2 jars we need are there in the
> >> >> repository
> >> >> you suggested,  but maven will not download them.
> >> >>
> >> >> Kelvin.
> >> >>
> >> >> 2008/6/6 Luciano Resende <[EMAIL PROTECTED]>:
> >> >>
> >> >> > Did you try the workaround I mentioned before on this thread [1]
> >> where
> >> >> > I added a new repository ? It was actually for other jars, but
> >> might
> >> >> > help in this case as well...
> >> >> >
> >> >> > [1]
> >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31727.html
> >> >> >
> >> >> > On Fri, Jun 6, 2008 at 4:56 AM, kelvin goodson
> >> <[EMAIL PROTECTED]>
> >> >> > wrote:
> >> >> > > I've made all the changes required in the tag [1] to get rid of
> >> the
> >> >> felix
> >> >> > > jars, find and include the emf jars,  and I've removed the
> >> incubating
> >> >> > tag,
> >> >> > > DISCLAIMER files etc.  However,  I'm currently stumped as to why
> >> two
> >> >> emf
> >> >> > > jars available

Re: Working on the release 1.3 branch

[ant elder]

On Mon, Jun 16, 2008 at 3:22 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Mon, Jun 16, 2008 at 3:17 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
>> On Mon, Jun 16, 2008 at 1:09 PM, Simon Laws <[EMAIL PROTECTED]>
>> wrote:
>>
>> > Hi
>> >
>> > I've changed the version number and got rid of the DISCLAIMER files. I'm
>> > looking at the getting the distribution build working, checking
>> > LICENSE/NOTICE and dependency versions before cutting an RC0 for us to
>> look
>> > at. If people want to help out with this pre-RC0 release prep then feel
>> > free
>> > and just go ahead. If you want to fix functional issues with the
>> release,
>> > e.g. a good indicator is if you are going to make the same change to
>> trunk,
>> > can you also raise a JIRA against 1.3 to cover the change so I can see
>> > what's being fixed.
>> >
>> > Thanks
>> >
>> > Simon
>> >
>>
>> It looks like the binary distribution build is broken in the 1.3 branch, i
>> think related to the change i did back in
>> r663551<http://svn.apache.org/viewvc?view=rev&revision=663551>.
>> I'm still investigating but it maybe best to go back to using the really
>> old
>> shade plugin for now in the branch so it doesn't hold up anything in the
>> 1.3
>> release.
>>
>>   ..ant
>>
>
> How broken is it? It its a day to fix then I suggest we do it. If it's a
> week then I agree lets use the old one.
>
> Simon
>

A lot of dependency jars aren't getting included in the binary distribution
so samples will be broken. Not sure why not yet so i can't say how long it
will take to fix it :) I worried that people might be trying to test things
in 1.3 now so a broken binary distribution would cause some inconvenience.
What about if i revert it in the branch now so as to not hinder testing and
if it can be fixed then put it back in the branch then?

   ...ant

Re: Working on the release 1.3 branch

[ant elder]

On Mon, Jun 16, 2008 at 1:09 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> Hi
>
> I've changed the version number and got rid of the DISCLAIMER files. I'm
> looking at the getting the distribution build working, checking
> LICENSE/NOTICE and dependency versions before cutting an RC0 for us to look
> at. If people want to help out with this pre-RC0 release prep then feel
> free
> and just go ahead. If you want to fix functional issues with the release,
> e.g. a good indicator is if you are going to make the same change to trunk,
> can you also raise a JIRA against 1.3 to cover the change so I can see
> what's being fixed.
>
> Thanks
>
> Simon
>

It looks like the binary distribution build is broken in the 1.3 branch, i
think related to the change i did back in
r663551.
I'm still investigating but it maybe best to go back to using the really old
shade plugin for now in the branch so it doesn't hold up anything in the 1.3
release.

   ..ant

Re: Tuscany Board Report for June

[ant elder]

Last call for any input on what i'll be submitting tomorrow:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/June+2008

   ...ant

On Tue, Jun 10, 2008 at 9:59 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> I need to submit our ASF board report by next Monday. I've created a wiki 
> page -  http://cwiki.apache.org/confluence/display/TUSCANYWIKI/June+2008 - 
> please add anything you want mentioned.
>
>...ant

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

[ant elder]

On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:



b) A variety of functional components, that represent sets of coherent
> functions.
>
>   Each consists of a series of the basic modules, aggregated together.
>   Their function in life is to assist developers of applications that embed
> some level of
>   Tuscany capability (including tools, Tuscany itself and so on)
>
>   These are probably not agreed by folk today - we have work to do here to
> define these.
>   You demonstrate the problem in your example above - you want "Basic Web
> Services" separate from
>   "Web Services Security" - but for an end user, the step from using the
> first to using the
>   second is a trivial addition of @required="integrity" to the SCDL.
>
>   Anyone care to have a go at defining these compoennts?
>
>
Thats taking a different tack to the launcher appraoch but maybe we need
both and this approach would be easier for embedders so ok to move things
long I'll try an initial stab at it:

1) tuscany-scdl4j

An aggregated jar containing _all_ the model and stax processor classes
which can be used by tools etc for for reading/writing scdl without booting
a runtime. It includes all the extension classes as they generally don't
drag in any other dependencies so its not really any problem to incude them.
The only required dependency would be on stax, maybe some optional
dependencies like wsdl4j as the wsdl extension may need that. Not sure if
any of the contribution modules should be included, would have to
investigate that a bit.

2)  tuscany-runtime
An aggregated jar containing the minimum modules to start a runtime able to
run something like the simple calculator sample. Has dependencies on
tuscany-scdl4j and minimal other jars - geronimo-commonj_1.1_spec, cglib,
jaxb etc.

3) tuscany-api
An aggregated jar containing everything tuscany/sca applications might need
to compile - sca-api, SCADomain class from host-embedded, node2-api, jsp
taglib etc. Has no  external dependencies.

4) Single jars for all the binding and implementation type extensions which
add the capability to the minimal tuscany-runtime. We're already starting to
get these with the way extensions are being structured nowadays -
binding-jsonrpc-runtime, binding-ejb-runtime, implementation-widget-runtime
etc.

The above would make life for embedders much easier like the
Tuscany-Geronimo integration code (or JBoss when they come along) less
likely to break over releases as we add remove modules.

   ...ant

Re: Updating the Geronimo Tuscany plugin to work with Geronimo 2.1

[ant elder]

Following the instructions at:
https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/README.TXTwhen
i do step (3) it says:

Installation FAILED: A plugin configuration must include one plugin
artifact, not 0

Looking in the geronimo-plugin.xml at
https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/tuscany-tomcat/src/main/resources/META-INF/geronimo-plugin.xmlit
only mentions Geronimo version 2.0.1, 2.0.2 and 2.0.3-SNAPSHOT so i
guessed that means its not ready for 2.1.1 right? If thats the case is there
any doc anywhere on what might be needed to update it?

   ...ant

On Sat, Jun 14, 2008 at 5:38 PM, David Jencks <[EMAIL PROTECTED]>
wrote:

> Could you give us some idea what problems you are having?  Most likely
> you'll need a 2.1 to 2.1.1 adapter plugin (not yet written or in svn AFAIK)
> and possibly some other modifications.
>
> thanks
> david jencks
>
>
> On Jun 14, 2008, at 6:33 AM, ant elder wrote:
>
>  I've tried the Tuscany-Geronimo integration code [1] with Geronimo 2.1.1
>> releases and it doesn't work anymore. Could anyone help or say what is
>> required to get it working again?
>>
>> This would be useful for a GSoC student whos writing a Gernimo console
>> extension to manage SCA apps -
>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
>>
>> TIA,
>>
>>  ...ant
>>
>> [1] https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/
>>
>
>

Updating the Geronimo Tuscany plugin to work with Geronimo 2.1

[ant elder]

I've tried the Tuscany-Geronimo integration code [1] with Geronimo 2.1.1
releases and it doesn't work anymore. Could anyone help or say what is
required to get it working again?

This would be useful for a GSoC student whos writing a Gernimo console
extension to manage SCA apps -
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console

TIA,

   ...ant

[1] https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/

[jira] Commented: (TUSCANY-2391) Tuscany SCA support in the Geronimo Admin Console

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2391:


Patch applied to your sandbos area at: 
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/thilina/geronimo_ACE/

It tried building and deploying to Geronimo 2.1.1 and it appears in the admin 
console and runs. Cool!



> Tuscany SCA support in the Geronimo Admin Console
> -
>
> Key: TUSCANY-2391
> URL: https://issues.apache.org/jira/browse/TUSCANY-2391
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Tools
>Reporter: Thilina Buddhika
>Assignee: ant elder
> Attachments: geronimo_ACE.zip
>
>
> This is the primary implementation of this Admin Console Extension. It does 
> not contain any functionality related to Tuscany. But it is intended to use 
> this as the basis for developing the ACE.
> The patch contains the source, and provides a maven build file.

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

[jira] Assigned: (TUSCANY-2391) Tuscany SCA support in the Geronimo Admin Console

[ant elder (JIRA)]

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

ant elder reassigned TUSCANY-2391:
--

Assignee: ant elder

> Tuscany SCA support in the Geronimo Admin Console
> -
>
> Key: TUSCANY-2391
> URL: https://issues.apache.org/jira/browse/TUSCANY-2391
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Tools
>Reporter: Thilina Buddhika
>    Assignee: ant elder
> Attachments: geronimo_ACE.zip
>
>
> This is the primary implementation of this Admin Console Extension. It does 
> not contain any functionality related to Tuscany. But it is intended to use 
> this as the basis for developing the ACE.
> The patch contains the source, and provides a maven build file.

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

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

Trunk is now 1.4-SNAPSHOT in r667767 and a fresh build runs ok for me.

Based on all this thread 1.4-SNAPSHOT isn't perfect but seemed what there
was best consensus for right now. Feel free to revisit and I'd be happy to
do the work to change trunk version to something else if anyone can get
consensus on something else.

   ...ant

On Fri, Jun 13, 2008 at 9:45 AM, Rajini Sivaram <
[EMAIL PROTECTED]> wrote:

>
>
> On 6/13/08, ant elder <[EMAIL PROTECTED]> wrote:
>>
>> Are the OSGI "real" versions required to be numeric, which would also mean
>> 1.x wouldn't work so well as a version for OSGi right?
>
>
> Yes, the versions need to be numeric, 1.x wont work.
>
>   ...ant
>>
>> On Fri, Jun 13, 2008 at 9:24 AM, Rajini Sivaram <
>> [EMAIL PROTECTED]> wrote:
>>
>> > Ant,
>> >
>> > I am not sure how relevant this is, but in the context of versioning
>> > Tuscany
>> > for OSGi, Tuscany modules are being built as OSGi bundles with "real"
>> > versions (eg. the current build uses "2.0"). The version used is not
>> > currently derived from the maven version, instead it is specified
>> > independently as a property in modules/pom.xml - so it won't actually
>> break
>> > if you modified 2.0-incubating-SNAPSHOT to SNAPSHOT. But it will become
>> > less
>> > obvious to OSGi users what version a Tuscany build really is. We will
>> need
>> > a
>> > real version for the snapshot builds for building OSGi bundles
>> regardless
>> > of
>> > whether we use that as the version for maven. The question is whether we
>> > need OSGi build versioning to be consistent with maven versions - OSGi
>> > users
>> > building against Tuscany 1.4-SNAPSHOT probably expect to use the 1.4
>> > release, while non-OSGi users as you say may expect to use the latest
>> > SNAPSHOT. Anyway, I just thought I will point this out, I dont actually
>> > mind
>> > either way.
>> >
>> >
>> > On 6/13/08, ant elder <[EMAIL PROTECTED]> wrote:
>> > >
>> > > On Tue, Jun 10, 2008 at 9:41 AM, ant elder <[EMAIL PROTECTED]>
>> wrote:
>> > >
>> > > >
>> > > >
>> > > > On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino <
>> > > > [EMAIL PROTECTED]> wrote:
>> > > > > Luciano Resende wrote:
>> > > > >>
>> > > > >> How about 1.5-SNAPSHOT ? This would probably give us some room to
>> > have
>> > > > >> couple releases without the necessity to keep updating the trunk
>> pom
>> > > > >> version. And this would probably make everybody happy :)
>> > > > >>
>> > > > >> On Fri, Jun 6, 2008 at 1:14 AM, ant elder <[EMAIL PROTECTED]>
>> > > wrote:
>> > > > >>>
>> > > > >>> On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende <
>> > > [EMAIL PROTECTED]>
>> > > > >>> wrote:
>> > > > >>>
>> > > > >>>> I guess part of problem here is because a lot of people assume
>> > that
>> > > > >>>> the maven artifact version represents what is going to be our
>> next
>> > > > >>>> release and then, if it's set as 2.0-SNAPSHOT, it means our
>> next
>> > > > >>>> release would be 2.0.
>> > > > >>>
>> > > > >>> I agree, this is exactly the issue. But I'm not sure its that
>> much
>> > of
>> > > > an
>> > > > >>> unreasonable assumption, it does feel odd to me to have
>> > 2.0-SNAPSHOT
>> > > as
>> > > > >>> the
>> > > > >>> trunk version before there has been any decision to start
>> working
>> > on
>> > > a
>> > > > >>> 2.0
>> > > > >>> in trunk.
>> > > > >>>
>> > > > >>>  ...ant
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >
>> > > > > I'd prefer the next logical number, 1.3 for example.
>> > > > >
>> > > >
>> > > > I still think plain SNAPSHOT would be simplest but as no one else
>> seems
>> &

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

[ant elder]

On Fri, Jun 13, 2008 at 3:50 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> ant elder wrote:
>
>>
>> So just to be clear on what is being suggested this would be like the
>> launcher we used to have back in M2 days right?
>>
>>   ...ant
>>
>>
> No, the M2 launcher mixed too many different aspects:
> a) load the Tuscany JARs
> b) download then from the network as necessary
> b) launch your application code
> c) turn a client into a a 'client component'
>
> I am talking about what's currently demonstrated in:
> samples/calculator-distributed, in LaunchCalculatorNodeA
> or
> tutorial/store-client, in LaunchStoreClient
>
> for example, which only address (a).
> --
> Jean-Sebastien
>

Fair enough, i think we'd all be a bit nervous about trying "b) download
them from the network as necessary" again :)

   ...ant

Re: JMS transport specs/documentation

[ant elder]

On Fri, Jun 13, 2008 at 3:41 PM, Rajith Attapattu <[EMAIL PROTECTED]>
wrote:

> On Fri, Jun 13, 2008 at 8:42 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <[EMAIL PROTECTED]>
> > wrote:
> >
> > >  Hi Andreas
> > >
> > > I was wondering whether there is somewhere a specification or
> > documentation
> > > that gives a clear overview of what types of messages Synapse's JMS
> > > transport is supposed to accept and how it should process these
> messages.
> > > More precisely I'm looking for a document that contains requirements
> such
> > as
> > > "If the incoming message is a BytesMessage and has a 'Content-Type'
> > > property, then the transport ..." etc. Is there already something like
> > that?
> > >
> > >
> > >  Sorry, there isn't much external documentation yet..except in my head
> > :-)
> > > .. however, I have been planning to update the JMS transport to handle
> > JTA
> > > transactions for sometime, and I also wanted to change the design to
> > support
> > > both JMS 1.0 and 1.1 in a better way. Some of the current issues we
> have
> > > came about as we came across a user who wanted JMS 1.0 support, at
> which
> > > point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
> > >
> > > We also have plans to adhere to the proposed binding for SOAP over JMS
> > > specification<
> >
> http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/[EMAIL 
> PROTECTED]
> > >.
> > > At the same time, we need to update our code to not use
> > setMessageListener()
> > > etc. which the newer JEE app servers (such as WebSphere) does not
> allow..
> > >
> > > If not, are there people who are interested in helping to write this
> kind
> > > of specification? Note that I believe that the current behavior of the
> > JMS
> > > transport is not always appropriate. E.g. a BytesMessage with
> > Content-Type
> > > 'text/plain; charset=...' produces a binary wrapper, while I would
> expect
> > a
> > > text wrapper. Therefore the specs to be written would focus on the
> to-be
> > > situation rather than the as-is situation.
> > >
> > > I would certainly be very interested to keep working on the JMS
> transport
> > > and I believe that with your help and that of any others in the
> > community,
> > > we could really improve the current implementation to be much better
> > >
> > > asankha
> > >
> >
> > How about also something like an SCA compatibility mode so Synapse could
> > sit
> > in front of Tuscany/SCA JMS services? It would mainly be just setting
> some
> > header properties. I'm mostly a lurker on the Synapse list these days but
> i
> > could help from the SCA specification and Tuscany interop side of things.
> >
> >...ant
> >
>
> Ant could you explain a bit more?
> Is this for transforming an incomming JMS message into the required SCA
> fromat?
> It's been a while since I read the JMS binding spec and can't remember off
> the top of my head whats actually required to do the transformation.
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>

I just meant things like setting the "scaOperationName" JMS user property,
and there's a Tuscany specific user property to indicate exception messages
as the spec doesn't define those yet. Those would be the main ones for basic
RPC style services but there's more advanced stuff that could be done like
with message formats if Synapse wanted to take account of all the SCA
 options.

   ...ant

Re: JMS transport specs/documentation

[ant elder]

On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <[EMAIL PROTECTED]> wrote:

>  Hi Andreas
>
> I was wondering whether there is somewhere a specification or documentation
> that gives a clear overview of what types of messages Synapse's JMS
> transport is supposed to accept and how it should process these messages.
> More precisely I'm looking for a document that contains requirements such as
> "If the incoming message is a BytesMessage and has a 'Content-Type'
> property, then the transport ..." etc. Is there already something like that?
>
>
>  Sorry, there isn't much external documentation yet..except in my head :-)
> .. however, I have been planning to update the JMS transport to handle JTA
> transactions for sometime, and I also wanted to change the design to support
> both JMS 1.0 and 1.1 in a better way. Some of the current issues we have
> came about as we came across a user who wanted JMS 1.0 support, at which
> point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
>
> We also have plans to adhere to the proposed binding for SOAP over JMS
> specification  PROTECTED]>.
> At the same time, we need to update our code to not use setMessageListener()
> etc. which the newer JEE app servers (such as WebSphere) does not allow..
>
> If not, are there people who are interested in helping to write this kind
> of specification? Note that I believe that the current behavior of the JMS
> transport is not always appropriate. E.g. a BytesMessage with Content-Type
> 'text/plain; charset=...' produces a binary wrapper, while I would expect a
> text wrapper. Therefore the specs to be written would focus on the to-be
> situation rather than the as-is situation.
>
> I would certainly be very interested to keep working on the JMS transport
> and I believe that with your help and that of any others in the community,
> we could really improve the current implementation to be much better
>
> asankha
>

How about also something like an SCA compatibility mode so Synapse could sit
in front of Tuscany/SCA JMS services? It would mainly be just setting some
header properties. I'm mostly a lurker on the Synapse list these days but i
could help from the SCA specification and Tuscany interop side of things.

...ant

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

Are the OSGI "real" versions required to be numeric, which would also mean
1.x wouldn't work so well as a version for OSGi right?

   ...ant

On Fri, Jun 13, 2008 at 9:24 AM, Rajini Sivaram <
[EMAIL PROTECTED]> wrote:

> Ant,
>
> I am not sure how relevant this is, but in the context of versioning
> Tuscany
> for OSGi, Tuscany modules are being built as OSGi bundles with "real"
> versions (eg. the current build uses "2.0"). The version used is not
> currently derived from the maven version, instead it is specified
> independently as a property in modules/pom.xml - so it won't actually break
> if you modified 2.0-incubating-SNAPSHOT to SNAPSHOT. But it will become
> less
> obvious to OSGi users what version a Tuscany build really is. We will need
> a
> real version for the snapshot builds for building OSGi bundles regardless
> of
> whether we use that as the version for maven. The question is whether we
> need OSGi build versioning to be consistent with maven versions - OSGi
> users
> building against Tuscany 1.4-SNAPSHOT probably expect to use the 1.4
> release, while non-OSGi users as you say may expect to use the latest
> SNAPSHOT. Anyway, I just thought I will point this out, I dont actually
> mind
> either way.
>
>
> On 6/13/08, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Jun 10, 2008 at 9:41 AM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > > On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino <
> > > [EMAIL PROTECTED]> wrote:
> > > > Luciano Resende wrote:
> > > >>
> > > >> How about 1.5-SNAPSHOT ? This would probably give us some room to
> have
> > > >> couple releases without the necessity to keep updating the trunk pom
> > > >> version. And this would probably make everybody happy :)
> > > >>
> > > >> On Fri, Jun 6, 2008 at 1:14 AM, ant elder <[EMAIL PROTECTED]>
> > wrote:
> > > >>>
> > > >>> On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende <
> > [EMAIL PROTECTED]>
> > > >>> wrote:
> > > >>>
> > > >>>> I guess part of problem here is because a lot of people assume
> that
> > > >>>> the maven artifact version represents what is going to be our next
> > > >>>> release and then, if it's set as 2.0-SNAPSHOT, it means our next
> > > >>>> release would be 2.0.
> > > >>>
> > > >>> I agree, this is exactly the issue. But I'm not sure its that much
> of
> > > an
> > > >>> unreasonable assumption, it does feel odd to me to have
> 2.0-SNAPSHOT
> > as
> > > >>> the
> > > >>> trunk version before there has been any decision to start working
> on
> > a
> > > >>> 2.0
> > > >>> in trunk.
> > > >>>
> > > >>>  ...ant
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >
> > > > I'd prefer the next logical number, 1.3 for example.
> > > >
> > >
> > > I still think plain SNAPSHOT would be simplest but as no one else seems
> > to
> > > like that I think I agree with this - the next logical number seems
> > better
> > > than things like 1.x or 2.0 etc. So, I plan to change trunk to
> > 1.4-SNAPSHOT
> > > when the 1.3 branch is taken, do say if you really don't like this but
> > its
> > > what we've been doing most of the time in the past so i hope most can
> > live
> > > with it.
> > >
> > >   ...ant
> > >
> > >
> > I've been asked off list to highlight an issue that may not have been
> clear
> > from whats already been said in this thread.
> >
> > If we use 1.4-SNAPSHOT in trunk then external people who want to stay up
> to
> > date with the latest code will use that version in their dependencies.
> They
> > may not pay that close attention to the dev list so when we create the
> > branch for a real 1.4 release and change the trunk to 1.5-SNAPSHOT the
> > users
> > dependencies will still use 1.4-SNAPSHOT but now instead of getting the
> > latest code they're getting the stable branch code. One way this could be
> > avoided is by using a trunk version of simply "SNAPSHOT". Is anyone
> really
> > against SNAPSHOT if we went for that instead of 1.4-SNAPSHOT?
> >
> >   ...ant
> >
>
>
>
> --
> Thank you...
>
> Regards,
>
> Rajini
>

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

On Tue, Jun 10, 2008 at 9:41 AM, ant elder <[EMAIL PROTECTED]> wrote:

>
>
> On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino <
> [EMAIL PROTECTED]> wrote:
> > Luciano Resende wrote:
> >>
> >> How about 1.5-SNAPSHOT ? This would probably give us some room to have
> >> couple releases without the necessity to keep updating the trunk pom
> >> version. And this would probably make everybody happy :)
> >>
> >> On Fri, Jun 6, 2008 at 1:14 AM, ant elder <[EMAIL PROTECTED]> wrote:
> >>>
> >>> On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende <[EMAIL PROTECTED]>
> >>> wrote:
> >>>
> >>>> I guess part of problem here is because a lot of people assume that
> >>>> the maven artifact version represents what is going to be our next
> >>>> release and then, if it's set as 2.0-SNAPSHOT, it means our next
> >>>> release would be 2.0.
> >>>
> >>> I agree, this is exactly the issue. But I'm not sure its that much of
> an
> >>> unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as
> >>> the
> >>> trunk version before there has been any decision to start working on a
> >>> 2.0
> >>> in trunk.
> >>>
> >>>  ...ant
> >>>
> >>
> >>
> >>
> >
> > I'd prefer the next logical number, 1.3 for example.
> >
>
> I still think plain SNAPSHOT would be simplest but as no one else seems to
> like that I think I agree with this - the next logical number seems better
> than things like 1.x or 2.0 etc. So, I plan to change trunk to 1.4-SNAPSHOT
> when the 1.3 branch is taken, do say if you really don't like this but its
> what we've been doing most of the time in the past so i hope most can live
> with it.
>
>   ...ant
>
>
I've been asked off list to highlight an issue that may not have been clear
from whats already been said in this thread.

If we use 1.4-SNAPSHOT in trunk then external people who want to stay up to
date with the latest code will use that version in their dependencies. They
may not pay that close attention to the dev list so when we create the
branch for a real 1.4 release and change the trunk to 1.5-SNAPSHOT the users
dependencies will still use 1.4-SNAPSHOT but now instead of getting the
latest code they're getting the stable branch code. One way this could be
avoided is by using a trunk version of simply "SNAPSHOT". Is anyone really
against SNAPSHOT if we went for that instead of 1.4-SNAPSHOT?

   ...ant

Re: XQuery sample JAXB issue

[ant elder]

On Thu, Jun 12, 2008 at 7:15 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> I'm down to my last problem with the 2347 patch I'm trying to apply and
> it's
> a real good one. If feels awfully familiar. But I can't for the life of me
> work out how a patch which makes changes to do with validation errors can
> cause the attached exception in the XQuery sample. I'm on IBM JDK 5 and,
> rather awkwardly, this only happens for me when I compile from the top
> level. And possibly intermittently. We had something similar back in 1.0
> days and, IIRC, It turned out to be some Saxon version missmatch that
> caused
> these strange intermittent and mvn build location dependent compile
> problems.
>
> So is anyone else seeing this
> Anyone have any ideas
>
> I believe we have moved to a new JAXB version recently so in the mean time
> I'm going to broaden my search from looking at the diff files from the
> patch. I'll start by looking to see if all JAXB versions are the same.
>
> Regards
>
> Simon
>
>
> testQuoteJoin(xquery.quote.XQueryQuoteClientTestCase)  Time elapsed: 39.281
> sec
>  <<< ERROR!
> org.apache.tuscany.sca.databinding.TransformationException:
> com.sun.xml.bind.v2.
> runtime.IllegalAnnotationsException: 2 counts of
> IllegalAnnotationExceptions
> net.sf.saxon.om.NodeInfo is an interface, and JAXB can't handle interfaces.
>this problem is related to the following location:
>at net.sf.saxon.om.NodeInfo
>at protected net.sf.saxon.om.NodeInfo
> xquery.quote.jaxws.Provide
> AvailQuoteResponse._return
>at xquery.quote.jaxws.ProvideAvailQuoteResponse
> net.sf.saxon.om.NodeInfo does not have a no-arg default constructor.
>this problem is related to the following location:
>at net.sf.saxon.om.NodeInfo
>at protected net.sf.saxon.om.NodeInfo
> xquery.quote.jaxws.Provide
> AvailQuoteResponse._return
>at xquery.quote.jaxws.ProvideAvailQuoteResponse
>
>at
> org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transfor
> m(JAXB2OMElement.java:54)
>at
> org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transfor
> m(JAXB2OMElement.java:40)
>at
> org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$L
> azyPullTransformer.transform(DefaultTransformerExtensionPoint.java:199)
>at
> org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(Mediator
> Impl.java:81)
>at
> org.apache.tuscany.sca.core.databinding.transformers.Input2InputTrans
> former.transform(Input2InputTransformer.java:201)
>at
> org.apache.tuscany.sca.core.databinding.transformers.Input2InputTrans
> former.transform(Input2InputTransformer.java:45)
>at
> org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(Mediator
> Impl.java:81)
>at
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterc
> eptor.transform(DataTransformationInterceptor.java:186)
>at
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterc
> eptor.invoke(DataTransformationInterceptor.java:76)
>at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD
> KInvocationHandler.java:287)
>at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD
> KInvocationHandler.java:154)
>at $Proxy8.provideAvailQuote(Unknown Source)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:64)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:615)
>at
> net.sf.saxon.functions.ExtensionFunctionCall.invokeMethod(ExtensionFu
> nctionCall.java:533)
>at
> net.sf.saxon.functions.ExtensionFunctionCall.call(ExtensionFunctionCa
> ll.java:256)
>at
> net.sf.saxon.functions.ExtensionFunctionCall.iterate(ExtensionFunctio
> nCall.java:147)
>at net.sf.saxon.value.MemoClosure.iterate(MemoClosure.java:89)
>at net.sf.saxon.value.Value.getIterator(Value.java:216)
>at
> net.sf.saxon.expr.VariableReference.iterate(VariableReference.java:39
> 7)
>at net.sf.saxon.expr.PathExpression.iterate(PathExpression.java:848)
>at net.sf.saxon.expr.PathExpression.iterate(PathExpression.java:848)
>at net.sf.saxon.sort.DocumentSorter.iterate(DocumentSorter.java:84)
>at net.sf.saxon.expr.LazyExpression.iterate(LazyExpression.java:105)
>at net.sf.saxon.value.MemoClosure.iterate(MemoClosure.java:89)
>at net.sf.saxon.expr.Literal.iterate(Literal.java:202)
>at
> net.sf.saxon.expr.FilterExpression.iterate(FilterExpression.java:1034
> )
>at net.sf.saxon.expr.LetExpression.iterate(LetExpression.java:308)
>at net.sf.saxon.expr.ForExpression.process(ForExpression.java:650)
>at net.sf.saxon.expr.LetExpression.proc

[jira] Closed: (TUSCANY-2243) ServiceRuntimeException due to NPE with ComponentContext.getService()

[ant elder (JIRA)]

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

ant elder closed TUSCANY-2243.
--

Resolution: Fixed

It looks like the problem reported in the subject of this jira is now fixed and 
the remaining ignored test was incorrectly reporting a failure so i've 
corrected that

> ServiceRuntimeException due to NPE with ComponentContext.getService()
> -
>
> Key: TUSCANY-2243
> URL: https://issues.apache.org/jira/browse/TUSCANY-2243
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Reporter: Yee-Kang Chang
>Assignee: ant elder
> Fix For: Java-SCA-Next
>
> Attachments: ComponentContextUpdatesJIRA2243.patch
>
>
> ComponentContext.getService() did not return the expected service when 
> invoked.  It works with a @Reference field is defined for the service in the 
> Impl class but it failed without the annotation.  The reference is defined in 
> the SCDL.
> Section 1.4.1.1 of the specification says, "When a component implementation 
> needs access to a service where the reference to the service is not known at 
> compile time, the reference can be located using the component's 
> ComponentContext."  So, this should work without @Reference defined.
> org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.core.context.ComponentContextImpl.getServiceReference(ComponentContextImpl.java:228)
>   at 
> org.apache.tuscany.sca.core.context.ComponentContextImpl.getServiceReference(ComponentContextImpl.java:110)
>   at 
> org.apache.tuscany.sca.core.context.ComponentContextImpl.getService(ComponentContextImpl.java:102)
>   at 
> org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.impl.AComponentImpl.testServiceLookup(AComponentImpl.java:96)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:618)
>   at 
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
>   at 
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>   at $Proxy7.testServiceLookup(Unknown Source)
>   at 
> org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.ComponentContextTestCase.testServiceLookup(ComponentContextTestCase.java:170)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:618)
>   at 
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
>   at 
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>   at 
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
>   at 
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
>   at 
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
>   at 
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
>   at 
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>   at 
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(Re

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

[ant elder]

On Thu, Jun 12, 2008 at 4:31 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

> ant elder wrote:
>
>> On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash <[EMAIL PROTECTED]> wrote:
>>
>>  Jean-Sebastien Delfino wrote:
>>>
>>>  Raymond Feng wrote:
>>>>
>>>>  Hi,
>>>>>
>>>>> There are a few patterns we use to determine if a maven module is
>>>>> required. Let's take the contribution stuff as an example.
>>>>>
>>>>> 1) contribution contains the interfaces for the contribution model and
>>>>> default implementation classes, SPIs and extension points
>>>>> 2) contribution-xml deals with the reading/writing the xml document for
>>>>> the sca-contribution.xml
>>>>> 3) contribution-java, contribution-namspace, contribution-resource deal
>>>>> with a specific perspective of the contribution, for example,
>>>>> namespace,
>>>>> java, resource
>>>>> 4) contribution-osgi, contribution-groovy support specific packaging
>>>>> schemes of the SCA contributions.
>>>>>
>>>>> Please note there is a tree-like dependency graph. I don't think it
>>>>> makes
>>>>> sense to merge the siblings into one module. Since an ancestor (for
>>>>> example
>>>>> contribution) are shared by mulitple children (-xml, -osgi, etc), it
>>>>> also
>>>>> not desirable to merge the common ancestor with other modules.
>>>>>
>>>>> For databinding related modules, we have a similar strcuture:
>>>>> 1) databinding: The base model, SPIs and transformers for various XML
>>>>> technologies
>>>>> 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The
>>>>> individual databinding technologies
>>>>> 3) core-databinding: A set of hook code that leverage the databinding
>>>>> framework in the invocation chains (data transformation interceptors)
>>>>>
>>>>> We can use 1 as the data transformation utility in
>>>>> binding/implementation
>>>>> or even 3rd party code without 3. We can also pick one or more modules
>>>>> from
>>>>> 2.
>>>>>
>>>>> What I'm trying to point out is that our maven module structure
>>>>> reflects
>>>>> the nature of the feature units and dependencies fairly well. IMO, each
>>>>> module maps well into an OSGi bundle. IMHO, both the maven module and
>>>>> OSGi
>>>>> bundle follow the same principles and the results should be consistent.
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>>
>>>>>  +1 to all that, makes a lot of sense to me!
>>>>
>>>>  Sorry, but it doesn't make sense to me.  If there is no user scenario
>>>>
>>> that can pull in contribution-java but not contribution-resource,
>>> or vice versa, I don't see why we would choose to expose these in
>>> our distro as separate bundles.  For the databindings, there are
>>> user scenarios in which a subset would be needed by different users,
>>> so things like databinding-jaxb and databinding-sdo should be in
>>> separate bundles.  However, core-databinding and databinding would
>>> always be used together, so should be in the same bundle.
>>>
>>> There might be a reason for keeping these modules separate in the
>>> maven build, to reflect an internal functional split.  This internal
>>> structure is not relevant to Tuscany users and should not be exposed
>>> to them.
>>>
>>> I think our distro should have a bundle for a minimal basic core and
>>> bunldes for additional optional components that can be used in
>>> different combinations.  The granularity of these bundles should be
>>> determined by what possible combinations make sense for people using
>>> the binary distro.
>>>
>>>  Simon
>>>
>>>
>>>  I do also agree with this despite what i just posted about how if we use
>> the
>> launcher approach then the actual module jars don't matter to users :)
>>
>> One group of "users" we want for Tuscany are those embedding Tuscany in
>> other products, so having some aggregated jars that group modules by
>> functionality would make it easier for them - eg an aggregated jar that
>

[jira] Assigned: (TUSCANY-2243) ServiceRuntimeException due to NPE with ComponentContext.getService()

[ant elder (JIRA)]

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

ant elder reassigned TUSCANY-2243:
--

Assignee: ant elder

> ServiceRuntimeException due to NPE with ComponentContext.getService()
> -
>
> Key: TUSCANY-2243
> URL: https://issues.apache.org/jira/browse/TUSCANY-2243
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Reporter: Yee-Kang Chang
>    Assignee: ant elder
> Fix For: Java-SCA-Next
>
> Attachments: ComponentContextUpdatesJIRA2243.patch
>
>
> ComponentContext.getService() did not return the expected service when 
> invoked.  It works with a @Reference field is defined for the service in the 
> Impl class but it failed without the annotation.  The reference is defined in 
> the SCDL.
> Section 1.4.1.1 of the specification says, "When a component implementation 
> needs access to a service where the reference to the service is not known at 
> compile time, the reference can be located using the component's 
> ComponentContext."  So, this should work without @Reference defined.
> org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.core.context.ComponentContextImpl.getServiceReference(ComponentContextImpl.java:228)
>   at 
> org.apache.tuscany.sca.core.context.ComponentContextImpl.getServiceReference(ComponentContextImpl.java:110)
>   at 
> org.apache.tuscany.sca.core.context.ComponentContextImpl.getService(ComponentContextImpl.java:102)
>   at 
> org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.impl.AComponentImpl.testServiceLookup(AComponentImpl.java:96)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:618)
>   at 
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
>   at 
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>   at $Proxy7.testServiceLookup(Unknown Source)
>   at 
> org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.ComponentContextTestCase.testServiceLookup(ComponentContextTestCase.java:170)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:618)
>   at 
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
>   at 
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>   at 
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
>   at 
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
>   at 
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
>   at 
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
>   at 
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>   at 
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>

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

[ant elder]

On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash <[EMAIL PROTECTED]> wrote:

> Jean-Sebastien Delfino wrote:
>
>> Raymond Feng wrote:
>>
>>> Hi,
>>>
>>> There are a few patterns we use to determine if a maven module is
>>> required. Let's take the contribution stuff as an example.
>>>
>>> 1) contribution contains the interfaces for the contribution model and
>>> default implementation classes, SPIs and extension points
>>> 2) contribution-xml deals with the reading/writing the xml document for
>>> the sca-contribution.xml
>>> 3) contribution-java, contribution-namspace, contribution-resource deal
>>> with a specific perspective of the contribution, for example, namespace,
>>> java, resource
>>> 4) contribution-osgi, contribution-groovy support specific packaging
>>> schemes of the SCA contributions.
>>>
>>> Please note there is a tree-like dependency graph. I don't think it makes
>>> sense to merge the siblings into one module. Since an ancestor (for example
>>> contribution) are shared by mulitple children (-xml, -osgi, etc), it also
>>> not desirable to merge the common ancestor with other modules.
>>>
>>> For databinding related modules, we have a similar strcuture:
>>> 1) databinding: The base model, SPIs and transformers for various XML
>>> technologies
>>> 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The
>>> individual databinding technologies
>>> 3) core-databinding: A set of hook code that leverage the databinding
>>> framework in the invocation chains (data transformation interceptors)
>>>
>>> We can use 1 as the data transformation utility in binding/implementation
>>> or even 3rd party code without 3. We can also pick one or more modules from
>>> 2.
>>>
>>> What I'm trying to point out is that our maven module structure reflects
>>> the nature of the feature units and dependencies fairly well. IMO, each
>>> module maps well into an OSGi bundle. IMHO, both the maven module and OSGi
>>> bundle follow the same principles and the results should be consistent.
>>>
>>> Thanks,
>>> Raymond
>>>
>>>
>> +1 to all that, makes a lot of sense to me!
>>
>>  Sorry, but it doesn't make sense to me.  If there is no user scenario
> that can pull in contribution-java but not contribution-resource,
> or vice versa, I don't see why we would choose to expose these in
> our distro as separate bundles.  For the databindings, there are
> user scenarios in which a subset would be needed by different users,
> so things like databinding-jaxb and databinding-sdo should be in
> separate bundles.  However, core-databinding and databinding would
> always be used together, so should be in the same bundle.
>
> There might be a reason for keeping these modules separate in the
> maven build, to reflect an internal functional split.  This internal
> structure is not relevant to Tuscany users and should not be exposed
> to them.
>
> I think our distro should have a bundle for a minimal basic core and
> bunldes for additional optional components that can be used in
> different combinations.  The granularity of these bundles should be
> determined by what possible combinations make sense for people using
> the binary distro.
>
>  Simon
>
>
I do also agree with this despite what i just posted about how if we use the
launcher approach then the actual module jars don't matter to users :)

One group of "users" we want for Tuscany are those embedding Tuscany in
other products, so having some aggregated jars that group modules by
functionality would make it easier for them - eg an aggregated jar that
contains the minimal Tuscany core runtime modules, another jar with all the
web services related modules etc. Its really hard for an outsider (or even
insider for that mater) working out what modules are needed for what, look
at the tuscany-geronimo integration code which has never managed to keep up
with Tuscany changes.

I think we could do both, if we go for a new launcher approach and OSGi'ify
everything then it might even make it easier to get the aggregated jars
working well and its not so much overhead for us to maintain both sets of
jars and use which ever are appropriate depending on the circumstances. The
key thing will be to get _consensus_ on it so we're all working together
instead of what we have now which seems to be we each focus on the bits
we're interested in sometimes to the detriment of what other are trying to
do.

   ...ant

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

[ant elder]

On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

I wonder if some of this debate is due to us not all talking about they same
thing so maybe it would help to go back to this proposal:

Here's what I'd like to see as a user:
>
> - a short list of API JARs that I can add to my dev compile/build path
>
> - a single small launcher or bootstrap JAR that takes care of bootstrapping
> the Tuscany runtime
>
> - the launcher should detect the presence of installed extensions in a
> particular Tuscany installation
>
> - as a user / app developer I should not have to know the list of JARs from
> all these extensions.
>
>
This is a fundamentally different approach from what we do today where we
have all the Tuscany jars and dependencies on the application classpath. One
of the main reasons for having jars of aggregated modules is to make it
easier for users but if we change to have a runtime launcher which handles
the all the module jars instead of the user then that reason goes away.

To make this clear, today if a user has an Ant build script for their
application that build script needs to hardcode each Tuscany module jar and
dependency jar name so the build script breaks every time we change things.
The tuscany-all and manifest jars help some but as has been pointed they
have other problems. If we change to use the launcher approach then the Ant
build script just needs to hardcode the Tuscany API and launcher bootstrap
jar names and the location of the Tuscany install, and those few names
should not change much over Tuscany releses so the user application doesn't
get broken when we change Tuscany internal things. It doesn't really matter
to the user if the actual Tuscany install folder has 10 jars or 200 jars all
the they care about is the install location and the launcher handles it all
for them. This is similar to developing webapps for Tomcat, to the user all
they care about is the servlet-api jar and where Tomcat is installed, they
don't care whats in the Tomcat server lib directory.

We did use this launcher approach back in M2 and we changed in 0.90 as a
launcher makes things harder for Tuscany developers, for example when
debugging Tuscany internals, but maybe _now_ it would be better to change
back to a launcher approach as it makes things easier for users.

   ...ant

[jira] Closed: (TUSCANY-2274) @Scope vTest failing intermittently

[ant elder (JIRA)]

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

ant elder closed TUSCANY-2274.
--

Resolution: Fixed

Fixed in r667046 and r667049 but adding some synchronization clauses

> @Scope vTest failing intermittently 
> 
>
> Key: TUSCANY-2274
> URL: https://issues.apache.org/jira/browse/TUSCANY-2274
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
> Fix For: Java-SCA-Next
>
>
> The atScope1 vTest fails intermittently like this:
> ---
>  T E S T S
> ---
> Running 
> org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase
> Setting up
> Apr 26, 2008 5:00:57 PM 
> org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime buildComposite
> WARNING: Can't find monitor extension on the classpath
> GService->initGService
> atScope1
> Exception in thread "Thread-5" java.lang.IllegalArgumentException: Invalid 
> phase name: component.implementation
> at 
> org.apache.tuscany.sca.core.invocation.InvocationChainImpl.addInvoker(InvocationChainImpl.java:106)
> at 
> org.apache.tuscany.sca.core.invocation.InvocationChainImpl.addInvoker(InvocationChainImpl.java:70)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addImplementationInterceptor(RuntimeWireImpl.java:316)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:188)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain(RuntimeWireImpl.java:115)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getInvocationChain(RuntimeComponentServiceImpl.java:120)
> at 
> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.getInvoker(RuntimeSCAReferenceBindingProvider.java:232)
> ThreadB1->BService2
> ThreadB2->BService9
> at 
> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:245)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109)
> at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243)
> at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148)
> at $Proxy17.setCurrentState(Unknown Source)
> at 
> org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase$CThread.run(ScopeAnnotationTestCase.java:359)
> Exception in thread "Thread-4" org.osoa.sca.ServiceUnavailableException: 
> Service not found for component CComponent reference $self$.CService (bi
> ndingURI=/CComponent operation=getName). Ensure that the composite containing 
> the service is loaded and started somewhere in the SCA domain and t
> hat if running in a remote node that the interface of the target service 
> marked as @Remotable
> at 
> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:247)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109)
> at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243)
> at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148)
> at $Proxy17.setCurrentState(Unknown Source)
> at 
> org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase$CThread.run(ScopeAnnotationTestCase.java:359)
> atScope2
> ---
> Still not clear if this is a runtime r test setup issue.  I have added Ignore 
> annotation until this is resolved.

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

Re: Test failure: org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation()

[ant elder]

I can confirm that the test works ok now for me.

   ...ant

On Thu, Jun 12, 2008 at 11:33 AM, Simon Nash <[EMAIL PROTECTED]> wrote:

> Simon Nash wrote:
>
>> Raymond Feng wrote:
>>
>>> Hi,
>>>
>>> Do any of you see this failure too?
>>>
>>>  Yes, I see it.  It appears the test is wrong, and this is now showing
>> up because of my recent check-in r666738 in which I fixed a problem
>> where the conversation object was incorrectly being returned as null
>> even though there is an active conversation.
>>
>> This test appears to be checking for the incorrect behaviour.  The
>> call b.testNullConversation() creates a conversation, since the
>> BComponent interface is @Conversational and BComponentImpl has
>> @Scope("CONVERSATION").  Calling RequestContext.getConversation()
>> while this method is active should return non-null, not null.
>>
>>  I fixed this test case under r667036.
>
>  Simon
>
>   Simon
>>
>>  Thanks,
>>> Raymond
>>>
>>> org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation()
>>>
>>>
>>> java.lang.AssertionError:  at org.junit.Assert.fail(Assert.java:69)
>>>  at org.junit.Assert.assertTrue(Assert.java:32)
>>>  at org.junit.Assert.assertNull(Assert.java:256)
>>>  at org.junit.Assert.assertNull(Assert.java:265)
>>>  at
>>> org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.impl.BComponentImpl.testNullConversation(BComponentImpl.java:67)
>>>
>>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>  at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>
>>>  at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
>>>  at java.lang.reflect.Method.invoke(Method.java:597)
>>>  at
>>> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:133)
>>>
>>>  at
>>> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
>>>
>>>  at
>>> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>>>
>>>  at
>>> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>>>
>>>  at $Proxy14.testNullConversation(Unknown Source)
>>>  at
>>> org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation(CallableReferenceTestCase.java:103)
>>>
>>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>  at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>
>>>  at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
>>>  at java.lang.reflect.Method.invoke(Method.java:597)
>>>  at
>>> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
>>>
>>>  at
>>> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
>>>
>>>  at
>>> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>>>
>>>  at
>>> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
>>>
>>>  at
>>> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
>>>  at
>>> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
>>>
>>>  at
>>> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
>>>
>>>  at
>>> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
>>>
>>>  at
>>> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>>>
>>>  at
>>> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
>>>  at
>>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
>>>
>>>  at
>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>
>>>  at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>>>
>>>  at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>>>
>>>  at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>>>
>>>  at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
>>>
>>>
>>>
>>>
>>
>>
>

Re: SVN build process.

[ant elder]

20 minutes! what sort of super machine do you have, its approaching an hour
on my machine!

I do agree with the principal though. I think one of the problems is its
just getting so big we try to take short cuts by not always building
everything, in the restructuring of future releases thats being talked about
on other threads maybe we should try to break up the build somehow so some
parts can be more independent parts of the build somehow to make it a bit
smaller and faster.

   ...ant

On Thu, Jun 12, 2008 at 10:15 AM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:

> Hi,
> i've a proposal for current svn. We could make most of our effort to
> make the svn compile.
> I suggest to trying a fresh build before committing meaniful things
> and after committing.
> It's matter of 20 minutes but it saves us more times. If doens't
> compile, you might fix or disable
> what it doens't compile. For example yesterday the corba tests module
> didn't work from a fresh build.
>
>
> Ciao,
> Giorgio.
> ---
> "Venceremos adelante, o victoria o muerte!"
>

Re: Tuscany support for Axis 1.4

[ant elder]

On Mon, Jun 9, 2008 at 10:17 AM, ant elder <[EMAIL PROTECTED]> wrote:

>
> On Wed, May 14, 2008 at 1:12 PM, Lou Amodeo <[EMAIL PROTECTED]> wrote:
>
>> Is there a plan for Tuscany to support Axis2 1.4?
>>
>
>
> Axis2 1.4 and the associated wss4j and rampart releases for 1.4 are  all
> out and available in the Maven repositories now. I've still a couple of
> issues to resolve to get everything in the build working with 1.4 but hope
> to have those fixed in the next day or 2 so would like to move up to 1.4
> then
>

This isn't going so well so I'm wondering if it would be better to NOT move
up to Axis2 1.4 for the SCA 1.3 release. The are still some minor issues
that are more of an inconvenience eg the way our soap/jms support is
configured causes a big ugly stacktrace in samples that don't incude the JMS
API now, but the main problem is with ws-security not working yet and when
that is fixed a bug in WSS4J we'll like hit which may need a new release to
fix [1]. How would people feel about staying on Axis2 1.3 for now, i know
there's a dessire to get the latest versions of XmlSchema and AXIOM but will
it break anything in our 1.3 release if we don't do that?

   ...ant

[1] http://apache.markmail.org/message/2t7kdnf2tw33sphg

Re: Unable to download the artifact from any repository

[ant elder]

Looks like you're right and thats missing which does seem like a bug.

   ...ant

On Wed, Jun 11, 2008 at 7:47 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> Hi,
>
> We should have the following maven repo declared in the pom.xml:
>
>   
>   apache.snapshots
>   Apache Snapshot Repository
>   http://people.apache.org/repo/m2-snapshot-repository
>   
>   false
>   
>   
>   true
>   
>   
>
> But I cannot find it anywhere in the pom.xml under the java/sca tree. Is it
> a bug? If we build from "sca" folder, then it works fine. What about
> building modules/... from an empty local maven repo?
>
> Thanks,
> Raymond
>
> --
> From: "Oscar Castaneda" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 11, 2008 11:29 AM
> To: ; <[EMAIL PROTECTED]>
> Subject: Re: Unable to download the artifact from any repository
>
>
>  Thanks ant. I tried it but unfortunately I'm getting the same problem.
>> I'll
>> continue looking at it, any suggestions are welcome.
>>
>>
>> On Wed, Jun 11, 2008 at 8:21 PM, ant elder <[EMAIL PROTECTED]> wrote:
>>
>>  There's a Maven settings.xml we have for Tuscany the might help you at:
>>> https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml
>>>
>>>  ...ant
>>>
>>> On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda <
>>> [EMAIL PROTECTED]> wrote:
>>>
>>> > >
>>> > > It doesn't look right that the first of those URLs is pointing at my
>>> > apache
>>> > > space - > > 
>>> > > http://people.apache.org/~antelder<http://people.apache.org/%7Eantelder>
>>> <http://people.apache.org/%7Eantelder>
>>> <http://people.apache.org/%7Eantelder>
>>> > <http://people.apache.org/%7Eantelder>
>>> > > .
>>> >
>>> >
>>> > Thanks alot ant, you're right! I changed settings.xml following an old
>>> > email
>>> > thread. I deleted the file and executed mvn and its now complaining >
>>> about
>>> > not being able to resolve artifacts (and that's solvable my manually
>>> > installing them I think).
>>> >
>>> > However, I was only testing this because of the problems I was
>>> experiencing
>>> > when building revision 643746. Any ideas here? Maybe modifying the
>>> > settings.xml to get the required files from somewhere else?
>>> >
>>> > Here's the trace:
>>> >
>>> > $ mvn clean install -Dtest=no
>>> > [INFO] Scanning for projects...
>>> > [INFO]
>>> >
>>> 
>>> > [ERROR] FATAL ERROR
>>> > [INFO]
>>> >
>>> 
>>> > [INFO] Failed to resolve artifact.
>>> >
>>> > GroupId: org.apache.tuscany.sca
>>> > ArtifactId: tuscany-sca
>>> > Version: 2.0-incubating-SNAPSHOT
>>> >
>>> > Reason: Unable to download the artifact from any repository
>>> >
>>> >   org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT
>>> >
>>> > from the specified remote repositories:
>>> >  central (http://repo1.maven.org/maven2)
>>> >
>>> >
>>> > [INFO]
>>> >
>>> 
>>> > [INFO] Trace
>>> > org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
>>> > org.apache.tuscany.sca:tuscany-sca for project:
>>> > null:tuscany-modules:pom:null
>>> >at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
>>> >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290)
>>> >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
>>> >at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
>>> >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> >at
>>> >
>>> >
>>>
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> >at
>>> >
>>> >
>>>
>>> sun.reflect.D

Re: Unable to download the artifact from any repository

[ant elder]

It looks like what you're building isn't looking in the Apache incubating
repository, does the pom.xml in the top level of where you're building have

   
  apache.incubator
  http://people.apache.org/repo/m2-incubating-repository
   

in the  section?

   ...ant

On Wed, Jun 11, 2008 at 7:29 PM, Oscar Castaneda <
[EMAIL PROTECTED]> wrote:

> Thanks ant. I tried it but unfortunately I'm getting the same problem. I'll
> continue looking at it, any suggestions are welcome.
>
>
> On Wed, Jun 11, 2008 at 8:21 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > There's a Maven settings.xml we have for Tuscany the might help you at:
> > https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml
> >
> >   ...ant
> >
> > On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda <
> > [EMAIL PROTECTED]> wrote:
> >
> > > >
> > > > It doesn't look right that the first of those URLs is pointing at my
> > > apache
> > > > space - 
> > > > http://people.apache.org/~antelder<http://people.apache.org/%7Eantelder>
> <http://people.apache.org/%7Eantelder>
> > <http://people.apache.org/%7Eantelder>
> > > <http://people.apache.org/%7Eantelder>
> > > > .
> > >
> > >
> > > Thanks alot ant, you're right! I changed settings.xml following an old
> > > email
> > > thread. I deleted the file and executed mvn and its now complaining
> about
> > > not being able to resolve artifacts (and that's solvable my manually
> > > installing them I think).
> > >
> > > However, I was only testing this because of the problems I was
> > experiencing
> > > when building revision 643746. Any ideas here? Maybe modifying the
> > > settings.xml to get the required files from somewhere else?
> > >
> > > Here's the trace:
> > >
> > > $ mvn clean install -Dtest=no
> > > [INFO] Scanning for projects...
> > > [INFO]
> > >
> 
> > > [ERROR] FATAL ERROR
> > > [INFO]
> > >
> 
> > > [INFO] Failed to resolve artifact.
> > >
> > > GroupId: org.apache.tuscany.sca
> > > ArtifactId: tuscany-sca
> > > Version: 2.0-incubating-SNAPSHOT
> > >
> > > Reason: Unable to download the artifact from any repository
> > >
> > >   org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT
> > >
> > > from the specified remote repositories:
> > >  central (http://repo1.maven.org/maven2)
> > >
> > >
> > > [INFO]
> > >
> 
> > > [INFO] Trace
> > > org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
> > > org.apache.tuscany.sca:tuscany-sca for project:
> > > null:tuscany-modules:pom:null
> > >at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
> > >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290)
> > >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> > >at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> > >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >at
> > >
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > >at
> > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > >at java.lang.reflect.Method.invoke(Method.java:585)
> > >at
> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> > >at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> > >at
> > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> > >at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> > > Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
> find
> > > parent: org.apache.tuscany.sca:tuscany-sca for project:
> > > null:tuscany-modules:pom:null
> > >at
> > >
> > >
> >
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1264)
> > >at
> > >
> > >
> >
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Defa

Re: Unable to download the artifact from any repository

[ant elder]

lver.java:197)
>at
>
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73)
>at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:526)
>... 18 more
> Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to
> download the artifact from any repository
> at
>
> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:324)
>at
>
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:185)
>... 20 more
> [INFO]
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Wed Jun 11 20:08:02 CEST 2008
> [INFO] Final Memory: 1M/2M
> [INFO]
> 
>
>
> On Wed, Jun 11, 2008 at 6:11 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > It doesn't look right that the first of those URLs is pointing at my
> apache
> > space - 
> > http://people.apache.org/~antelder<http://people.apache.org/%7Eantelder>
> <http://people.apache.org/%7Eantelder>.
> > Could there be some old config
> > in you maven settings.xml file  (eg at C:\Documents and
> > Settings\Administrator\.m2\settings.xml) from when you reviewing the 1.0
> > RC1a?
> >
> >   ...ant
> >
> > On Wed, Jun 11, 2008 at 5:05 PM, Oscar Castaneda <
> > [EMAIL PROTECTED]> wrote:
> >
> > > I continued looking into this issue and found that the
> > > parent-2-incubating.pom can't be downloaded and thus leads to the
> errors
> > > shown below. I tested this by checking out the most recent version of
> the
> > > java code and building as explained in [1].
> > >
> > > I read that a possible workaround might be to download the pom and do
> > > things
> > > manually but it's not possible to acces the file on any of these URLs.
> > >
> > > Is there anywhere else I can get this file from? Am I missing
> something?
> > (I
> > > feel like I might be doing something terribly wrong...)
> > >
> > > $ mvn clean install -Dtest=no
> > > [INFO] Scanning for projects...
> > > Downloading:
> > >
> > >
> >
> http://people.apache.org/~antelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom<http://people.apache.org/%7Eantelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom>
> <
> http://people.apache.org/%7Eantelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> >
> > <
> >
> http://people.apache.org/%7Eantelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> > >
> > > Downloading:
> > >
> > >
> >
> http://ws.zones.apache.org/repository2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> > > Downloading:
> > >
> > >
> >
> http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> > > Downloading:
> > >
> > >
> >
> http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> > > Downloading:
> > >
> > >
> >
> http://www.ibiblio.net/pub/packages/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> > > [INFO]
> > >
> 
> > > [ERROR] FATAL ERROR
> > > [INFO]
> > >
> 
> > > [INFO] Failed to resolve artifact.
> > >
> > > GroupId: org.apache.tuscany
> > > ArtifactId: parent
> > > Version: 2-incubating
> > >
> > > Reason: Unable to download the artifact from any repository
> > >
> > >  org.apache.tuscany:parent:pom:2-incubating
> > >
> > > [1]
> http://incubator.apache.org/tuscany/sca-java-development-guide.html
> > >
> > > On Wed, Jun 11, 2008 at 10:43 AM, Oscar Castaneda <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm re-doing my SCA installation by following the steps in [1] and
> keep
> > > > running into a problem when doing clean install:
> > > >
> > > > mvn clean install -Dtest=no
> > > >
> > > > After searching the mailing list archives I found some suggestions,
> but
> > > > haven't been able to resolve the problem. I posted the stack trace in
> > > [2].
> > > > What can be going wrong? Any suggestions? Any help is greatly
> > > appreciated.
> > > >
> > > > [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/30may2008
> > > > [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/10Jun2008
> > > > --
> > > > best,
> > > > -oscar
> > > >
> > > > Oscar Castañeda
> > >
> > >
> > >
> > >
> > > --
> > > best,
> > > -oscar
> > >
> > > Oscar Castañeda
> > >
> >
>
>
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>

OSGi presentation

[ant elder]

Timely post of a presentation on server side OSGi:
http://www.infoq.com/presentations/colyer-server-side-osgi

   ...ant

Re: Unable to download the artifact from any repository

[ant elder]

It doesn't look right that the first of those URLs is pointing at my apache
space - http://people.apache.org/~antelder. Could there be some old config
in you maven settings.xml file  (eg at C:\Documents and
Settings\Administrator\.m2\settings.xml) from when you reviewing the 1.0
RC1a?

   ...ant

On Wed, Jun 11, 2008 at 5:05 PM, Oscar Castaneda <
[EMAIL PROTECTED]> wrote:

> I continued looking into this issue and found that the
> parent-2-incubating.pom can't be downloaded and thus leads to the errors
> shown below. I tested this by checking out the most recent version of the
> java code and building as explained in [1].
>
> I read that a possible workaround might be to download the pom and do
> things
> manually but it's not possible to acces the file on any of these URLs.
>
> Is there anywhere else I can get this file from? Am I missing something? (I
> feel like I might be doing something terribly wrong...)
>
> $ mvn clean install -Dtest=no
> [INFO] Scanning for projects...
> Downloading:
>
> http://people.apache.org/~antelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> Downloading:
>
> http://ws.zones.apache.org/repository2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> Downloading:
>
> http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> Downloading:
>
> http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> Downloading:
>
> http://www.ibiblio.net/pub/packages/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom
> [INFO]
> 
> [ERROR] FATAL ERROR
> [INFO]
> 
> [INFO] Failed to resolve artifact.
>
> GroupId: org.apache.tuscany
> ArtifactId: parent
> Version: 2-incubating
>
> Reason: Unable to download the artifact from any repository
>
>  org.apache.tuscany:parent:pom:2-incubating
>
> [1] http://incubator.apache.org/tuscany/sca-java-development-guide.html
>
> On Wed, Jun 11, 2008 at 10:43 AM, Oscar Castaneda <
> [EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I'm re-doing my SCA installation by following the steps in [1] and keep
> > running into a problem when doing clean install:
> >
> > mvn clean install -Dtest=no
> >
> > After searching the mailing list archives I found some suggestions, but
> > haven't been able to resolve the problem. I posted the stack trace in
> [2].
> > What can be going wrong? Any suggestions? Any help is greatly
> appreciated.
> >
> > [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/30may2008
> > [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/10Jun2008
> > --
> > best,
> > -oscar
> >
> > Oscar Castañeda
>
>
>
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>

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

[ant elder]

On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram <
[EMAIL PROTECTED]> wrote:

,snip>


>
> You have probably read this already, but others may find Neil Bartlett's
> discussion useful:
> http://www.eclipsezone.com/articles/extensions-vs-services/
>

Great article, thanks for the link. Thats over a year old now so has much
changed eg in relation to comments like "The "delayed" services feature
requires some small tweaks to the basic Equinox runtime, and these tweaks
have not been implemented yet in the released version 3.2. They do not
appear at all yet (at the time of writing) in the other open source OSGi
runtimes, Apache Felix and Knopflerfish."?

   ...ant

Re: [VOTE] Release SDO 1.1.1

[ant elder]

So thats works ok for two, doesn't work for one.

Luciano, I had to build a couple of times with -U to get all the emf jars
successfully downloaded, have you tried that or can you find any other way
to get a build through in your environment?

   ...ant

On Tue, Jun 10, 2008 at 11:32 AM, Murtaza Goga <[EMAIL PROTECTED]>
wrote:

> I built this release last night, built clean.
>
> -Original Message-----
> From: ant elder [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 10, 2008 5:29 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [VOTE] Release SDO 1.1.1
>
> I'd like to get this voted on and released but nervous to start that
> after
> Kelvin had trouble getting the emf dependencies, could any one else try
> building the tag and seeing if it works or not for them -
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-R
> C2/-<https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/->
> its a small checkout and doesn't take long to build.
>
>   ...ant
>
> On Sat, Jun 7, 2008 at 9:15 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > It seems to work fine for me, the binary distribution ends up with a
> lib
> > folder containing:
> >
> > backport-util-concurrent-3.0.jar
> > codegen-2.2.3.jar
> > codegen-ecore-2.2.3.jar
> > common-2.2.3.jar
> > ecore-2.2.3.jar
> > ecore-change-2.2.3.jar
> > ecore-xmi-2.2.3.jar
> > sample-sdo-1.1.1.jar
> > stax-api-1.0.1.jar
> > tuscany-sdo-api-r2.1-1.1.1.jar
> > tuscany-sdo-impl-1.1.1.jar
> > tuscany-sdo-lib-1.1.1.jar
> > tuscany-sdo-tools-1.1.1.jar
> > wstx-asl-3.2.1.jar
> > xsd-2.2.3.jar
> >
> > I've put the distributions that I get from the 1.1.1-RC2 tag up at
> >
> http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC2<http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2>
> <http://people.a
> pache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2>,
> > how do they look?
> >
> >...ant
> >
> > On Fri, Jun 6, 2008 at 6:18 PM, kelvin goodson <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi Luciano,
> >>   yes, I added that workaround,  and that satisfied most of the EMF
> jars,
> >> but not these two. It's odd, the 2 jars we need are there in the
> >> repository
> >> you suggested,  but maven will not download them.
> >>
> >> Kelvin.
> >>
> >> 2008/6/6 Luciano Resende <[EMAIL PROTECTED]>:
> >>
> >> > Did you try the workaround I mentioned before on this thread [1]
> where
> >> > I added a new repository ? It was actually for other jars, but
> might
> >> > help in this case as well...
> >> >
> >> > [1]
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31727.html
> >> >
> >> > On Fri, Jun 6, 2008 at 4:56 AM, kelvin goodson
> <[EMAIL PROTECTED]>
> >> > wrote:
> >> > > I've made all the changes required in the tag [1] to get rid of
> the
> >> felix
> >> > > jars, find and include the emf jars,  and I've removed the
> incubating
> >> > tag,
> >> > > DISCLAIMER files etc.  However,  I'm currently stumped as to why
> two
> >> emf
> >> > > jars available [2] and [3] don't get downloaded by the build.
> The
> >> build
> >> > > output complains about URLs that, if cut and pasted into a
> browser,
> >> work
> >> > > fine.  Any clues to explain this odd maven behaviour are welcome.
> >> > >
> >> > > Kelvin
> >> > >
> >> > >
> >> > > [1]
> >> > >
> >> >
> >>
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-R
> C2/<https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/>
> >> > > [2]
> >> > >
> >> >
> >>
> http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/c
> odegen/2.2.3/<http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen/2.2.3/>
> >> > > [3]
> >> > >
> >> >
> >>
> http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/c
> odegen-ecore/2.2.3/<http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen-ecore/2.2.3/>
> >> > >
> >> > > 2008/6/3 Rajini Sivaram <[EMAIL PROTECTED]>:
> >> > >
> >> > >> Kelvin,
> >> > >>
&

Re: Running vtests with security on

[ant elder]

On Thu, May 15, 2008 at 8:32 PM, Dan Becker <[EMAIL PROTECTED]> wrote:

> Since I am not much of a Maven expert, I thought I would run this by the
> Tuscany community to see if I am going down the right path or to see if
> there are better ideas.
>
> Normally when I test with any Tuscany sample or test with Java 2
> security enabled, I use the JVM options -Djava.security.manager
> -Djava.security.policy=tuscany.policy -Djava.security.debug=policy. The
> tuscany.policy file enables certain parts of Tuscany code to access
> sensitive API calls, such as reading system properties or writing to the
> file system. When I run Tuscany JUnit tests in Eclipse, I add these
> options to the JUnit "Run As" dialog settings.
>
> The Tuscany vtests run when you execute Maven on the vtest pom with the
> test goal. I was thinking of adding a profile that specifies the
> additional properties above. Also, I would provide an example
> tuscany.policy file that provides the proper permissions for the Tuscany
> code base. This when you wanted to run vtests with security on, you
> would invoke this profile along with the test goal.
>
> Any additional suggestions or comments?
>
> --
> Thanks, Dan Becker
>
>
In preparation for the 1.3 branch I've just had a try building trunk with
security on and get a few failures:

[INFO] Error for project: Apache Tuscany SCA Databinding Integration Tests -
JAXB Bottom Up (during test)
[INFO]

[INFO] There are test failures.

Please refer to
C:\Tuscany\SVN\trunk\itest\databindings\jaxb-bottom-up\target\surefire-reports
for the individual test results.
[INFO]

[INFO] Error for project: Apache Tuscany SCA Late Reference Resolution
Integration Test (during test)
[INFO]

[INFO] There are test failures.

Please refer to
C:\Tuscany\SVN\trunk\itest\late-reference-resolution\target\surefire-reports
for the individual test results.
[INFO]

[INFO] Error for project: Apache Tuscany SCA OSGi-SCA Integration Tests
(during test)
[INFO]

[INFO] There are test failures.

Please refer to
C:\Tuscany\SVN\trunk\itest\osgi-implementation\target\surefire-reports for
the individual test results.

(the itests jaxb-bottom-up and late-reference-resolution fail as well but
they're also failing for me in trunk right now without security on)

Thats using the command:

mvn test -P security
"-Dtuscany.policy.file=file:///c:\Tuscany\tuscany.policy"  -o

and with a the tuscany.policy file containing:

grant codeBase "file:/C:/Tuscany/SVN/trunk/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:/C:/Documents and
Settings/Administrator/.m2/repository/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:/e:/temp/eclipse/eclipse/-" {
  // permission java.security.AllPermission;
  permission java.net.SocketPermission "127.0.0.1:*",
"connect,accept,resolve";
  permission java.io.FilePermission "<>", "read";
  permission java.lang.RuntimePermission "accessDeclaredMembers";
  permission java.lang.RuntimePermission "getClassLoader";
  permission java.lang.RuntimePermission "createClassLoader";
  permission java.util.PropertyPermission "*", "read";
};

   ...ant

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

[ant elder]

On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram <
[EMAIL PROTECTED]> wrote:



If we are anyway going to require a "launcher" of some form,
> wouldn't it be just as easy to maintain one-bundle-per-module?
>

I agree, if we go back to requiring a launcher that changes a lot how we'd
could put this together. I'm not at all against requiring a launcher as that
does make things easier in some respects, but lets remember why we did used
to do this and then chucked it out in the 0.90 rewrite ;)

   ...ant

Re: NPE in JMS itests was: Re: JMS Client

[ant elder]

On Wed, Jun 11, 2008 at 8:29 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> On Wed, Jun 11, 2008 at 8:23 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Jun 11, 2008 at 6:42 AM, Nishant Joshi <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Hi All,
> > > I can now run JMS client successfully with latest binding.jms, but you
> > need
> > > to confirm following with WAS 6 before testing it.. this was done with
> > the
> > > help of Ant...
> > > This investigation done on sample sample-helloworld-jms-webapp
> > > 1)  see the link
> > >
> > >
> >
> http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=13949798&tstart=0
> > > 2) You need to add
> > >
> > >
> >
> localhost::BootstrapBasicMessaging,localhost:7276:BootstrapBasicMessaging
> > > in the property Provider endpoints of Connection Factory, You can find
> it
> > > in
> > > the websphere admin console, under resourses - JMS click on your
> > connection
> > > factory
> > > Here  is the port defined under websphere admin
> > > console and look in servers-application server, click on server1, and
> > then
> > > in the server1 panel there are two things under Communications in ports
> > it
> > > should list SIB_ENDPOINT_ADDRESS
> > > here second entry of port 7276 is defaul to provide...
> > > 3) In this sample there is a property to set in the web.xml to say
> start
> > > when the server starts up not on the first web request this was not
> come
> > > with standard sample otherwise you need to call your service throgh
> > > hello.jsp and then you client would work woth it (jsp is come in the
> > sample
> > > sample-helloworld-jms-webapp)
> > >
> > > by using above steps i can now run my client successfully.
> > >
> > > Thanks Ant for all your help..
> > > Please Ant correct me in this explanation.
> > >
> > > please let us know if anybody have any questions... :)
> > >
> > > --
> > > Thanks
> > > Nishant Joshi
> > >
> >
> > That all sounds about right, the only thing I'd add is that there is some
> > doc on the connection factory "provider endpoints" field at
> >
> >
> http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.express.doc/sibjmsresources/SIBJMSConnectionFactory_DetailForm.html
> >
> > I've added a short section on using this WebSphere client for JMS to the
> > binding.jms doc on the website, its very brief right now and just refers
> to
> > this email thread, Nishant or anyone else - interested in adding more
> > detail
> > or expanding it out into a separate more detaailed how-to wiki page?
> >
> >   ...ant
> >
> >   ...ant
> >
>
> I'm seeing an NPE in the JMS itests on the line
>
> if
>
> (props.get(Context.INITIAL_CONTEXT_FACTORY).equals("com.ibm.websphere.naming.WsnInitialContextFactory"))
> {
>
> Seems to be related to the changes here and could do with an "if null"
> check
> I guess. Is there a fix in hand for this or shall I make the change?
>
> Simon


I've just committed a fix.

   ...ant

Re: JMS Client

[ant elder]

On Wed, Jun 11, 2008 at 6:42 AM, Nishant Joshi <[EMAIL PROTECTED]>
wrote:

> Hi All,
> I can now run JMS client successfully with latest binding.jms, but you need
> to confirm following with WAS 6 before testing it.. this was done with the
> help of Ant...
> This investigation done on sample sample-helloworld-jms-webapp
> 1)  see the link
>
> http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=13949798&tstart=0
> 2) You need to add
>
> localhost::BootstrapBasicMessaging,localhost:7276:BootstrapBasicMessaging
> in the property Provider endpoints of Connection Factory, You can find it
> in
> the websphere admin console, under resourses - JMS click on your connection
> factory
> Here  is the port defined under websphere admin
> console and look in servers-application server, click on server1, and then
> in the server1 panel there are two things under Communications in ports it
> should list SIB_ENDPOINT_ADDRESS
> here second entry of port 7276 is defaul to provide...
> 3) In this sample there is a property to set in the web.xml to say start
> when the server starts up not on the first web request this was not come
> with standard sample otherwise you need to call your service throgh
> hello.jsp and then you client would work woth it (jsp is come in the sample
> sample-helloworld-jms-webapp)
>
> by using above steps i can now run my client successfully.
>
> Thanks Ant for all your help..
> Please Ant correct me in this explanation.
>
> please let us know if anybody have any questions... :)
>
> --
> Thanks
> Nishant Joshi
>

That all sounds about right, the only thing I'd add is that there is some
doc on the connection factory "provider endpoints" field at
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.express.doc/sibjmsresources/SIBJMSConnectionFactory_DetailForm.html

I've added a short section on using this WebSphere client for JMS to the
binding.jms doc on the website, its very brief right now and just refers to
this email thread, Nishant or anyone else - interested in adding more detail
or expanding it out into a separate more detaailed how-to wiki page?

   ...ant

   ...ant

Re: Release 1.3?

[ant elder]

On Tue, Jun 10, 2008 at 11:53 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> On Tue, Jun 10, 2008 at 10:14 AM, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> > Mike Edwards wrote:
> >
> >> Simon Laws wrote:
> >>
> >>> It's been a little while now since we did our 1.2 release. Since then
> >>> there
> >>> has been lots of activity and of course we have graduated. It feels
> like
> >>> the
> >>> right time to do a 1.3 release. Looking back at the mail list over the
> >>> last
> >>> couple of months there are quite a few candidates for inclusion that I
> >>> can
> >>> see;
> >>>
> >>> Better BPEL support
> >>> Improvements to the domain manager app
> >>> Improved runtime Java2WSDL processing
> >>> Support for validation monitoring
> >>> Databinding improvements
> >>> Performance improvements
> >>> JSR250 annotation support
> >>> OSGi support improvements and a simple OSGi runtime test
> >>> Java 2 security enablement
> >>> Quite a few more tests for various parts of the runtime
> >>> Lots of JIRA fixes.
> >>> and of course we can remove the "incubating" assignment and drum up a
> bit
> >>> of
> >>> publicity for our TLP graduation
> >>>
> >>> I'd also like to have a bit of a tidy up for this release and remove
> the
> >>> old
> >>> domain modules we are no longer using (I'll post on this separately)
> >>>
> >>> What else has been added or changed?
> >>>
> >>> I think the things I would like to get done can be closed off next week
> >>> ready to cut a branch.
> >>>
> >>> Thoughts?
> >>>
> >>> Simon
> >>>
> >>>  Yes, I give a +1.
> >>
> >> BPEL is looking a lot better now.  I'd like to add a couple of more
> >> sophisticated itests/samples as well and the release will be a good
> spur.
> >>
> >>
> >> Yours,  Mike.
> >>
> >>  I think this is a good time to do a 1.3 release.  This would make
> > the new runtime Java2WSDL generation available to Tuscany users,
> > and resolve a number of issues with the previous code generation
> > that used Axis2.  The other improvements listed are valuable as well.
> >
> >  Simon
> >
> >
> OK, so it looks like people want to do this
>
> Re. Luciano's question about RM. I'll volunteer to be RM this time round
> and
> all help is greatly appreciated. If though Luciano (or anyone else for that
> matter) you are keen to RM this time then I won't fight you for it;-) Would
> seem a little unfair though as you did the last one.
>
> Anyone have things they are working one that would stop us moving forward
> with this and cutting the R1.3 branch at the end of this week?
>
> Regards
>
> Simon
>

+1 to Simon as RM and taking the branch at the end of this week.

   ...ant

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

[ant elder]

On Tue, Jun 10, 2008 at 10:59 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:




> Good debate here, but let's be clear about the big picture before the
> details swamp the debate.
>

Big +1 to that, i really hope we can some consensus on what the
distributions and runtimes should look like before we decide what registries
etc we need to use to implement them.

   ...ant

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

[ant elder]

On Tue, Jun 10, 2008 at 7:03 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> ant elder wrote:
>
>> On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
>> [EMAIL PROTECTED]> wrote:
>>
>>  Simon Nash wrote:
>>>
>>>  ant elder wrote:
>>>>
>>>>  On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>>>> [EMAIL PROTECTED]> wrote:
>>>>>
>>>>>  Jean-Sebastien Delfino wrote:
>>>>>>
>>>>>>  I'd like to discuss the following: "What distro Zips are we building
>>>>>>> and
>>>>>>> what do they contain?"
>>>>>>>
>>>>>>> I think we could improve our distro scheme to provide:
>>>>>>> - smaller packages
>>>>>>> - easier for people to find what they need
>>>>>>>
>>>>>>> I was thinking about the following binary distro zips:
>>>>>>>
>>>>>>> - tuscany-core.zip - The base that everybody needs.
>>>>>>>  core assembly model and runtime
>>>>>>>  Java APIs, Java components
>>>>>>>
>>>>>>> - tuscany-web.zip - For WS and Web developers
>>>>>>>  WS binding, Web 2.0 bindings, Scripting components, Widget
>>>>>>> components
>>>>>>>
>>>>>>> - tuscany-jee.zip - For JEE app integration
>>>>>>>  EJB, RMI and JMS bindings, Spring components
>>>>>>>
>>>>>>> - tuscany-process.zip - For process development
>>>>>>>  BPEL and XQuery components
>>>>>>>
>>>>>>> - tuscany-all.zip - all of the above
>>>>>>>
>>>>>>> Note that I'm not trying to tackle release cycles and the potential
>>>>>>> for
>>>>>>> releasing the above zips independently in this discussion and I'm
>>>>>>>
>>>>>>>  assuming
>>>>>> that we release all of the above together.
>>>>>>
>>>>>>> I'm also assuming that the relevant samples are included in each zip.
>>>>>>>
>>>>>>>  This email was from 1/22/08, generated a lot of discussion for about
>>>>>>> 3
>>>>>>>
>>>>>> weeks, lots of opinions, no conclusion, no commits :)
>>>>>>
>>>>>>
>>>>>>  No commits as we haven't found much consensus yet.
>>>>>
>>>>>  I still think the same as what I had posted then, plus additional
>>>>> ideas:
>>>>>
>>>>>> - Use OSGi exports/imports to export clean SPIs, hide internals, and
>>>>>>
>>>>>>  refine
>>>>>
>>>>>  the contents of the distros and their dependencies.
>>>>>>
>>>>>> Disclaimer - Please don't get me wrong I'm not saying that one distro
>>>>>> ==
>>>>>>
>>>>>>  one
>>>>>
>>>>>  OSGi bundle, as I've already said several times on the list that the
>>>>>> big-OSGi-bundle approach didn't make sense to me :) I just think that
>>>>>> declaring and enforcing clean dependencies using OSGi will help us
>>>>>> refine
>>>>>> the contents of each distro.
>>>>>>
>>>>>>  The term "enforcing" seems to suggest that there might be an OSGi
>>>>>>
>>>>> dependency for the Tuscany runtime.  I don't know if this was
>>>> intended.  I think the right approach is to have a Tuscany+OSGi
>>>> runtime (as we are building in itest\osgi-tuscany) which would
>>>> actually do enforcement, and a non-OSGi Tuscany runtime in which
>>>> the exports/imports are present in the jars but not enforced.
>>>>
>>>>  Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
>>> environment...
>>>
>>>
>>>  What would be the granularity of these OSGi bundles?  If the bundles
>>>> are the current maven modules, I think we will find a number of
>>>> classes that need to be exported even though these classes are not
>>>> considered part of the SPI or API that the module provides.
>>>> To reso

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

[ant elder]

On Tue, Jun 10, 2008 at 6:52 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Please see my comments inline.
>
> Thanks,
> Raymond
>
> [snip]
>
>> Good requirement, but I don't think that the current manifest +
>> tuscany-all JAR solution is a good one (for example it mixes APIs and
>> internals in the same JAR, doesn't work well with IDEs, works only for one
>> big distro, requires different settings in J2SE and webapps)
>>
>>
> IMHO, the all-in-one package pretty much defeats our modularity. For
> example, all module activators will be called even the extension won't be
> used at all.


Calling a module activator is pretty minimal initialization overhead
especially if it just fails right away with something like a
ClassNotFoundException and the runtime carries on, and this is what happens
with the our bundle jar - you can just use it without the extension
dependencies you don't need and it works fine.  Note I'm not necessarily
saying we should be keeping the single one big bundle jar, i'm just trying
to avoid the impression that the _only_ option we have is everything in
individual separate jars.



> Two extension cannot have different versions of a 3rd party jar.
>
>  Here's what I'd like to see as a user:
>>
>> - a short list of API JARs that I can add to my dev compile/build path
>>
>> - a single small launcher or bootstrap JAR that takes care of
>> bootstrapping the Tuscany runtime
>>
>>
> This is similar to JEE launchClient. If I can invoke the Launcher directly
> in java, I would be happy.
>

So just to be clear on what is being suggested this would be like the
launcher we used to have back in M2 days right?

   ...ant

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

[ant elder]

On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Simon Nash wrote:
>
>> ant elder wrote:
>>
>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>> [EMAIL PROTECTED]> wrote:
>>>
>>>> Jean-Sebastien Delfino wrote:
>>>>
>>>>> I'd like to discuss the following: "What distro Zips are we building
>>>>> and
>>>>> what do they contain?"
>>>>>
>>>>> I think we could improve our distro scheme to provide:
>>>>> - smaller packages
>>>>> - easier for people to find what they need
>>>>>
>>>>> I was thinking about the following binary distro zips:
>>>>>
>>>>> - tuscany-core.zip - The base that everybody needs.
>>>>>  core assembly model and runtime
>>>>>  Java APIs, Java components
>>>>>
>>>>> - tuscany-web.zip - For WS and Web developers
>>>>>  WS binding, Web 2.0 bindings, Scripting components, Widget components
>>>>>
>>>>> - tuscany-jee.zip - For JEE app integration
>>>>>  EJB, RMI and JMS bindings, Spring components
>>>>>
>>>>> - tuscany-process.zip - For process development
>>>>>  BPEL and XQuery components
>>>>>
>>>>> - tuscany-all.zip - all of the above
>>>>>
>>>>> Note that I'm not trying to tackle release cycles and the potential for
>>>>> releasing the above zips independently in this discussion and I'm
>>>>>
>>>> assuming
>>>
>>>> that we release all of the above together.
>>>>>
>>>>> I'm also assuming that the relevant samples are included in each zip.
>>>>>
>>>>>  This email was from 1/22/08, generated a lot of discussion for about 3
>>>> weeks, lots of opinions, no conclusion, no commits :)
>>>>
>>>>
>>> No commits as we haven't found much consensus yet.
>>>
>>>  I still think the same as what I had posted then, plus additional ideas:
>>>>
>>>> - Use OSGi exports/imports to export clean SPIs, hide internals, and
>>>>
>>> refine
>>>
>>>> the contents of the distros and their dependencies.
>>>>
>>>> Disclaimer - Please don't get me wrong I'm not saying that one distro ==
>>>>
>>> one
>>>
>>>> OSGi bundle, as I've already said several times on the list that the
>>>> big-OSGi-bundle approach didn't make sense to me :) I just think that
>>>> declaring and enforcing clean dependencies using OSGi will help us
>>>> refine
>>>> the contents of each distro.
>>>>
>>>>  The term "enforcing" seems to suggest that there might be an OSGi
>> dependency for the Tuscany runtime.  I don't know if this was
>> intended.  I think the right approach is to have a Tuscany+OSGi
>> runtime (as we are building in itest\osgi-tuscany) which would
>> actually do enforcement, and a non-OSGi Tuscany runtime in which
>> the exports/imports are present in the jars but not enforced.
>>
>
> Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
> environment...
>
>
>> What would be the granularity of these OSGi bundles?  If the bundles
>> are the current maven modules, I think we will find a number of
>> classes that need to be exported even though these classes are not
>> considered part of the SPI or API that the module provides.
>> To resolve this I see the following options:
>>  a) Export more than we really believe is correct.  This
>>leaves us in the current unsatisfactory position of exposing
>>unwanted implementation internals.
>>  b) Combine multiple maven modules with a close implementation
>>affinity into a single OSGi bundle, and only expose true
>>APIs or SPIs from these bundles.
>>  c) Refactor the code to remove dependencies on internals of other
>>modules, and create new SPIs or APIs when this isn't possible.
>>
>> I believe a combination of b) and c) is the best approach.
>>
>
> We've already rehashed this (and disagreed on this) in several other
> threads, where I've already given my opinion:
> - 1 bundle per module
> - clean API/SPI imports/exports


By "1 bundle per module" do you mean any sort bundled jar combining multiple
of our tuscany/java/sca/module jars is not worth pursuing?

   ...ant

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

[ant elder]

On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Simon Nash wrote:
>
>> ant elder wrote:
>>
>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>> [EMAIL PROTECTED]> wrote:
>>>
>>>> Jean-Sebastien Delfino wrote:
>>>>
>>>>> I'd like to discuss the following: "What distro Zips are we building
>>>>> and
>>>>> what do they contain?"
>>>>>
>>>>> I think we could improve our distro scheme to provide:
>>>>> - smaller packages
>>>>> - easier for people to find what they need
>>>>>
>>>>> I was thinking about the following binary distro zips:
>>>>>
>>>>> - tuscany-core.zip - The base that everybody needs.
>>>>>  core assembly model and runtime
>>>>>  Java APIs, Java components
>>>>>
>>>>> - tuscany-web.zip - For WS and Web developers
>>>>>  WS binding, Web 2.0 bindings, Scripting components, Widget components
>>>>>
>>>>> - tuscany-jee.zip - For JEE app integration
>>>>>  EJB, RMI and JMS bindings, Spring components
>>>>>
>>>>> - tuscany-process.zip - For process development
>>>>>  BPEL and XQuery components
>>>>>
>>>>> - tuscany-all.zip - all of the above
>>>>>
>>>>> Note that I'm not trying to tackle release cycles and the potential for
>>>>> releasing the above zips independently in this discussion and I'm
>>>>>
>>>> assuming
>>>
>>>> that we release all of the above together.
>>>>>
>>>>> I'm also assuming that the relevant samples are included in each zip.
>>>>>
>>>>>  This email was from 1/22/08, generated a lot of discussion for about 3
>>>> weeks, lots of opinions, no conclusion, no commits :)
>>>>
>>>>
>>> No commits as we haven't found much consensus yet.
>>>
>>>  I still think the same as what I had posted then, plus additional ideas:
>>>>
>>>> - Use OSGi exports/imports to export clean SPIs, hide internals, and
>>>>
>>> refine
>>>
>>>> the contents of the distros and their dependencies.
>>>>
>>>> Disclaimer - Please don't get me wrong I'm not saying that one distro ==
>>>>
>>> one
>>>
>>>> OSGi bundle, as I've already said several times on the list that the
>>>> big-OSGi-bundle approach didn't make sense to me :) I just think that
>>>> declaring and enforcing clean dependencies using OSGi will help us
>>>> refine
>>>> the contents of each distro.
>>>>
>>>>  The term "enforcing" seems to suggest that there might be an OSGi
>> dependency for the Tuscany runtime.  I don't know if this was
>> intended.  I think the right approach is to have a Tuscany+OSGi
>> runtime (as we are building in itest\osgi-tuscany) which would
>> actually do enforcement, and a non-OSGi Tuscany runtime in which
>> the exports/imports are present in the jars but not enforced.
>>
>
> Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
> environment...
>
>
>> What would be the granularity of these OSGi bundles?  If the bundles
>> are the current maven modules, I think we will find a number of
>> classes that need to be exported even though these classes are not
>> considered part of the SPI or API that the module provides.
>> To resolve this I see the following options:
>>  a) Export more than we really believe is correct.  This
>>leaves us in the current unsatisfactory position of exposing
>>unwanted implementation internals.
>>  b) Combine multiple maven modules with a close implementation
>>affinity into a single OSGi bundle, and only expose true
>>APIs or SPIs from these bundles.
>>  c) Refactor the code to remove dependencies on internals of other
>>modules, and create new SPIs or APIs when this isn't possible.
>>
>> I believe a combination of b) and c) is the best approach.
>>
>
> We've already rehashed this (and disagreed on this) in several other
> threads, where I've already given my opinion:
> - 1 bundle per module
> - clean API/SPI imports/exports
>
>
>>  - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension
>>>> 

Re: [VOTE] Release SDO 1.1.1

[ant elder]

I'd like to get this voted on and released but nervous to start that after
Kelvin had trouble getting the emf dependencies, could any one else try
building the tag and seeing if it works or not for them -
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/-
its a small checkout and doesn't take long to build.

   ...ant

On Sat, Jun 7, 2008 at 9:15 AM, ant elder <[EMAIL PROTECTED]> wrote:

> It seems to work fine for me, the binary distribution ends up with a lib
> folder containing:
>
> backport-util-concurrent-3.0.jar
> codegen-2.2.3.jar
> codegen-ecore-2.2.3.jar
> common-2.2.3.jar
> ecore-2.2.3.jar
> ecore-change-2.2.3.jar
> ecore-xmi-2.2.3.jar
> sample-sdo-1.1.1.jar
> stax-api-1.0.1.jar
> tuscany-sdo-api-r2.1-1.1.1.jar
> tuscany-sdo-impl-1.1.1.jar
> tuscany-sdo-lib-1.1.1.jar
> tuscany-sdo-tools-1.1.1.jar
> wstx-asl-3.2.1.jar
> xsd-2.2.3.jar
>
> I've put the distributions that I get from the 1.1.1-RC2 tag up at
> http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC2<http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2>,
> how do they look?
>
>...ant
>
> On Fri, Jun 6, 2008 at 6:18 PM, kelvin goodson <[EMAIL PROTECTED]>
> wrote:
>
>> Hi Luciano,
>>   yes, I added that workaround,  and that satisfied most of the EMF jars,
>> but not these two. It's odd, the 2 jars we need are there in the
>> repository
>> you suggested,  but maven will not download them.
>>
>> Kelvin.
>>
>> 2008/6/6 Luciano Resende <[EMAIL PROTECTED]>:
>>
>> > Did you try the workaround I mentioned before on this thread [1] where
>> > I added a new repository ? It was actually for other jars, but might
>> > help in this case as well...
>> >
>> > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31727.html
>> >
>> > On Fri, Jun 6, 2008 at 4:56 AM, kelvin goodson <[EMAIL PROTECTED]>
>> > wrote:
>> > > I've made all the changes required in the tag [1] to get rid of the
>> felix
>> > > jars, find and include the emf jars,  and I've removed the incubating
>> > tag,
>> > > DISCLAIMER files etc.  However,  I'm currently stumped as to why two
>> emf
>> > > jars available [2] and [3] don't get downloaded by the build.  The
>> build
>> > > output complains about URLs that, if cut and pasted into a browser,
>> work
>> > > fine.  Any clues to explain this odd maven behaviour are welcome.
>> > >
>> > > Kelvin
>> > >
>> > >
>> > > [1]
>> > >
>> >
>> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/
>> > > [2]
>> > >
>> >
>> http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen/2.2.3/
>> > > [3]
>> > >
>> >
>> http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen-ecore/2.2.3/
>> > >
>> > > 2008/6/3 Rajini Sivaram <[EMAIL PROTECTED]>:
>> > >
>> > >> Kelvin,
>> > >>
>> > >> Sorry about the delay in getting back to you - I can see that you
>> have
>> > >> found
>> > >> a solution. Yes, you are absolutely right, the felix framework should
>> > use
>> > >> scope "provided" since SdoBundleActivator is only used when SDO is
>> > running
>> > >> inside an OSGi container, and the framework classes are provided by
>> the
>> > >> container.
>> > >>
>> > >>
>> > >> On 6/3/08, kelvin goodson <[EMAIL PROTECTED]> wrote:
>> > >> >
>> > >> > Just a thought,  would I be right in guessing that if ever our
>> > >> > SdoBundleActivator is touched in the runtime,  then the environment
>> > would
>> > >> > be
>> > >> > expected to provide the classes to satisfy
>> > >> >
>> > >> > import org.osgi.framework.BundleActivator;
>> > >> > import org.osgi.framework.BundleContext;
>> > >> >
>> > >> > ?
>> > >> >
>> > >> > in which case I think declaring a "provided" scope for the felix
>> > >> dependency
>> > >> > would be the right way to do things
>> > >> >
>> > >> >

Tuscany Board Report for June

[ant elder]

I need to submit our ASF board report by next Monday. I've created a wiki
page -  http://cwiki.apache.org/confluence/display/TUSCANYWIKI/June+2008 -
please add anything you want mentioned.

   ...ant

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
> Luciano Resende wrote:
>>
>> How about 1.5-SNAPSHOT ? This would probably give us some room to have
>> couple releases without the necessity to keep updating the trunk pom
>> version. And this would probably make everybody happy :)
>>
>> On Fri, Jun 6, 2008 at 1:14 AM, ant elder <[EMAIL PROTECTED]> wrote:
>>>
>>> On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> I guess part of problem here is because a lot of people assume that
>>>> the maven artifact version represents what is going to be our next
>>>> release and then, if it's set as 2.0-SNAPSHOT, it means our next
>>>> release would be 2.0.
>>>
>>> I agree, this is exactly the issue. But I'm not sure its that much of an
>>> unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as
>>> the
>>> trunk version before there has been any decision to start working on a
>>> 2.0
>>> in trunk.
>>>
>>>  ...ant
>>>
>>
>>
>>
>
> I'd prefer the next logical number, 1.3 for example.
>

I still think plain SNAPSHOT would be simplest but as no one else seems to
like that I think I agree with this - the next logical number seems better
than things like 1.x or 2.0 etc. So, I plan to change trunk to 1.4-SNAPSHOT
when the 1.3 branch is taken, do say if you really don't like this but its
what we've been doing most of the time in the past so i hope most can live
with it.

  ...ant

Re: JMS Client

[ant elder]

I've been able to recreate this problem by using a non-IBM JRE with the
WebSphere JMS client. Turns out the Tuscany JMS binding needs to a special
property added to the JNDI initial context environment when NOT running on
an IBM JRE. I've updated the binding-jms code to do this and it works ok now
for me could you give it a try?

   ...ant

On Tue, Jun 10, 2008 at 8:34 AM, Nishant Joshi <[EMAIL PROTECTED]>
wrote:

> Hi Ant,
> Thanks for your investigation on this.
> I m getting exception with WebSphere JMS client with a Sun JDK...
> below is the stacktrace for it...
>
> javax.naming.NamingException: Failed to initialize the ORB [Root exception
> is java.lang.ClassCastException: com.sun.corba.se.impl.orb.ORBImpl]
> at com.ibm.ws.naming.util.Helpers.getOrb(Helpers.java:314)
> at
> com.ibm.ws.naming.util.WsnInitCtxFactory.getInitialContextInternal(WsnInitCtxFactory.java:383)
> at
> com.ibm.ws.naming.util.WsnInitCtx.getContext(WsnInitCtx.java:113)
> at
> com.ibm.ws.naming.util.WsnInitCtx.getContextIfNull(WsnInitCtx.java:428)
> at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:144)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)
> at
> org.apache.tuscany.sca.binding.jms.provider.JMSResourceFactory.jndiLookUp(JMSResourceFactory.java:149)
> at
> org.apache.tuscany.sca.binding.jms.provider.JMSResourceFactory.lookupDestination(JMSResourceFactory.java:129)
> at
> org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.lookupDestinationQueue(JMSBindingInvoker.java:134)
> at
> org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.lookupDestination(JMSBindingInvoker.java:83)
> at
> org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.(JMSBindingInvoker.java:66)
> at
> org.apache.tuscany.sca.binding.jms.provider.JMSBindingReferenceBindingProvider.createInvoker(JMSBindingReferenceBindingProvider.java:117)
> at
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228)
> at
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167)
> at
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148)
> at $Proxy15.sayHello(Unknown Source)
> at
> helloworld.HelloWorldClientImpl.sayHello(HelloWorldClientImpl.java:25)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
> at
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
> at
> org.apache.tuscany.sca.core.invocation.CglibProxyFactory$CglibMethodInterceptor.intercept(CglibProxyFactory.java:149)
> at
> helloworld.HelloWorldClientImpl$$EnhancerByCGLIB$$e8cbf9a4.sayHello()
>
> at helloworld.JMSClient.main(JMSClient.java:20)
> at helloworld.ClientTest.testServiceCall(ClientTest.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
> at
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
> at
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
> at
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
> at
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
> at
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
> at
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
> at
> org.j

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

[ant elder]

On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:
> Jean-Sebastien Delfino wrote:
>>
>> I'd like to discuss the following: "What distro Zips are we building and
>> what do they contain?"
>>
>> I think we could improve our distro scheme to provide:
>> - smaller packages
>> - easier for people to find what they need
>>
>> I was thinking about the following binary distro zips:
>>
>> - tuscany-core.zip - The base that everybody needs.
>>  core assembly model and runtime
>>  Java APIs, Java components
>>
>> - tuscany-web.zip - For WS and Web developers
>>  WS binding, Web 2.0 bindings, Scripting components, Widget components
>>
>> - tuscany-jee.zip - For JEE app integration
>>  EJB, RMI and JMS bindings, Spring components
>>
>> - tuscany-process.zip - For process development
>>  BPEL and XQuery components
>>
>> - tuscany-all.zip - all of the above
>>
>> Note that I'm not trying to tackle release cycles and the potential for
>> releasing the above zips independently in this discussion and I'm
assuming
>> that we release all of the above together.
>>
>> I'm also assuming that the relevant samples are included in each zip.
>>
>
> This email was from 1/22/08, generated a lot of discussion for about 3
> weeks, lots of opinions, no conclusion, no commits :)
>

No commits as we haven't found much consensus yet.

> I still think the same as what I had posted then, plus additional ideas:
>
> - Use OSGi exports/imports to export clean SPIs, hide internals, and
refine
> the contents of the distros and their dependencies.
>
> Disclaimer - Please don't get me wrong I'm not saying that one distro ==
one
> OSGi bundle, as I've already said several times on the list that the
> big-OSGi-bundle approach didn't make sense to me :) I just think that
> declaring and enforcing clean dependencies using OSGi will help us refine
> the contents of each distro.
>
> - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension
> registry mechanism (what we have now in Tuscany or better a combination of
> what we have now and the Eclipse Equinox registry for example) to detect
> which pieces are installed and activate their capabilities.
>

Can you say a bit more about what an "extension registry mechanism" would
look like?

What the tuscany-all/manifest jar are trying to do is to have users not need
to know about the internal makeup of Tuscany. So they can simply use
tuscany-all and avoid needing to know about all the dozens of different
Tuscany modules and their dependencies, and that should keep working over
many Tuscany releases whereas as we keep adding/deleting/changing the
modules we keep breaking user builds for each Tuscany release if they refer
to the individual modules. Maybe the granularity isn't quite right yet and
we need something in between the all jar and all the individual modules.

Is there much agreement that avoiding users needing to know about the
internal Tuscany modules is a Good Thing?

  ...ant

Account Request - Scott Kurz - Tuscany

[ant elder]

Dear root,

Please create an id for Scott Kurz on the Tuscany project

Preferred userid:scottkurz
Full name:   Scott Kurz
Forwarding email address:[EMAIL PROTECTED]
Requested Karma for: ws-tuscany

ICLA is on file.

Votes:

tuscany-private, June 9, Message-ID:
<[EMAIL PROTECTED]>

Many thanks,

  ...ant

Re: Tuscany support for Axis 1.4

[ant elder]

On Wed, May 14, 2008 at 1:12 PM, Lou Amodeo <[EMAIL PROTECTED]> wrote:

> Is there a plan for Tuscany to support Axis2 1.4?
>


Axis2 1.4 and the associated wss4j and rampart releases for 1.4 are  all out
and available in the Maven repositories now. I've still a couple of issues
to resolve to get everything in the build working with 1.4 but hope to have
those fixed in the next day or 2 so would like to move up to 1.4 then

   ...ant

Re: [PROPOSAL] Disable unused domain modules

[ant elder]

On Mon, Jun 9, 2008 at 9:56 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> Hi All
>
> Now that the new domain manager app is starting to settle down a bit I'd
> like to disable the unused domain modules from the main build. They are...
>
> modules/domain
> modules/domain-api
> modules/domain-xml
> modules/node
> modules/node-api
> modules/node-xml
>
> I have removed these from most of the places they were previously
> referenced
> with the exception of a couple of samples/itests. I propose that we break
> these final dependencies and remove these modules from the main build and
> from the distribution builds. The module themselves can remain in place for
> a little while longer until we are happy the builds are stable and then I
> think we can move them out to sandbox/old.
>
> These modules are now replaced by a range of domain and node features
> spread
> across various modules. These are the ones I am aware of:
>
> modules/domain-manager - represents the configured domain and provides a
> web
> interface to users
> modules/endpoint - a plug point for late reference resolution (we don't
> actually support late reference resolution yet in our runtimes.The domain
> assumes that wires are known and static)
> modules/implementation-node - the model that represents a configured node
> in
> the domain. Used to provide default binding configuration and relate
> composites to nodes
> modules/implementation-node-runtime
> modules/implementation-node-xml
> modules/node2-api - the new node implementation that reads its
> configuration
> from the command line or directly from the domain-manager
> modules/node2-impl
> modules/node2-launcher
> modules/node2-launcher-webbapp
> modules/runtime
> modules/runtime-tomcat - deep integration with tomcat that allows composite
> application wars to be deployed which don't contain Tuscany jars (under
> development)
> modules/workspace - the code behind the domain-manager contribution
> processing.
> modules/workspace-impl
> modules/workspace-xml
>
> Regards
>
> Simon
>

+1 to removing the old modules.

I'd prefer they are deleted from the modules folder than left there just not
part of the build. They'll always be there in SVN history if they are ever
needed again for something.

   ...ant

[ANNOUNCE] Apache Tuscany SCA Java 1.2.1 released

[ant elder]

The Apache Tuscany team are pleased to announce the 1.2.1 release of
the Java SCA project.

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

This 1.2.1 release is a maintenance release over the 1.2 release, see the
RELEASE_NOTES and CHANGES file for details, and to download the
distributions please go to:

http://incubator.apache.org/tuscany/sca-java-releases.html

To find out more about OASIS Open CSA go to:

http://www.oasis-opencsa.org

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

http://incubator.apache.org/tuscany

Thank you for your interest in Apache Tuscany!

The Apache Tuscany Team.

[NOTICE] Scott Kurz voted as Tuscany committer

[ant elder]

The Tuscany PMC has voted for Scott Kurz to become a Tuscany committer.

Welcome Scott!

   ...ant

Re: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin

[ant elder]

On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:



I've created an itest (late-reference-resolution) to show how late
> resolution could be done using endpoint resolvers.
>
>
In the itest BindingScaEndpointResolverImpl it says "I can cheat here
because..." could you say a little about how a "real" use of this could
work? And what do you think about having some code somewhere - in an itest
or module somwhere - which demonstrates that? I'd be happy to help write
that, I'm asking as in runtime-tomcat i need to do the same thing but
haven't been able to figure out how its intended to be done for real.

   ...ant

Re: JMS Client

[ant elder]

On Fri, Jun 6, 2008 at 4:14 PM, Nishant Joshi <[EMAIL PROTECTED]>
wrote:

> Hi All,
> Here is the more detail regarding error...
> I have trace the error and found that exceptino source is from method
> "getInitialContext()" of
> "org.apache.tuscany.sca.binding.jms.provider.JMSResourceFactory"
> Here is the complete stack trace
>
> org.apache.tuscany.sca.binding.jms.impl.JMSBindingException: JMS
> Destination HelloWorldService not found with create mode of "ifnotexist"
> while registering binding serviceA invoker
>  at
> org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.lookupDestinationQueue(JMSBindingInvoker.java:169)
>  at
> org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.lookupDestination(JMSBindingInvoker.java:83)
>  at
> org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.(JMSBindingInvoker.java:66)
>  at
> org.apache.tuscany.sca.binding.jms.provider.JMSBindingReferenceBindingProvider.createInvoker(JMSBindingReferenceBindingProvider.java:117)
>  at
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228)
>  at
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167)
>  at
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109)
>  at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243)
>  at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148)
>  at $Proxy15.sayHello(Unknown Source)
>  at helloworld.HelloWorldClientImpl.sayHello(HelloWorldClientImpl.java:25)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:585)
>  at
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
>  at
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
>  at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>  at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>  at
> org.apache.tuscany.sca.core.invocation.CglibProxyFactory$CglibMethodInterceptor.intercept(CglibProxyFactory.java:149)
>  at
> helloworld.HelloWorldClientImpl$$EnhancerByCGLIB$$2ae21c1f.sayHello()
>  at helloworld.JMSClient.main(JMSClient.java:20)
>  at helloworld.ClientTest.testServiceCall(ClientTest.java:20)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:585)
>  at
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
>  at
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
>  at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>  at
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
>  at
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
>  at
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
>  at
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
>  at
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
>  at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>  at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
>  at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>  at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>  at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
>  at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:585)
>  at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
>  at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
>
>
> Has anybody idea why should i m not able to connect to a Queue of WAS ?
>
> --
> Thanks
> Nishant Joshi
>

The easiest way to get this to work is using the

Re: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin

[ant elder]

On Sat, Jun 7, 2008 at 12:48 PM, ant elder <[EMAIL PROTECTED]> wrote:

>
>
> On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> 
>
> I've updated all the code that used EndpointProviders. This includes
>> runtime-tomcat but I was unable to get this running following Ant's
>> instruction on this thread. It maybe that I did something wrong so I'll
>> give
>> it another go a little later.
>>
>>
> What is the problem you get?
>
>
I've just tried this, there was a problem with the runtime-tomcat
META-INF/services file being out of date with the package moves, i've
updated this and it now all works ok for me following the instructions in
that earlier email in this thread.

   ...ant

Re: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin

[ant elder]

On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:



I've updated all the code that used EndpointProviders. This includes
> runtime-tomcat but I was unable to get this running following Ant's
> instruction on this thread. It maybe that I did something wrong so I'll
> give
> it another go a little later.
>
>
What is the problem you get?

...ant

Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console

[ant elder]

I've created you a folder in our sandbox area
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/thilina, thats
yours to use for whatever you like. Ideally most of the code you do will go
in trunk as part of our regular build but you can use the sandbox area as a
staging area where you can experiment or store stuff without having to worry
about correctness, beauty or breaking any builds.

   ...ant

On Sat, Jun 7, 2008 at 8:13 AM, Thilina Buddhika <[EMAIL PROTECTED]>
wrote:

> Hi,
> Yes, these modules are available. But earlier there was a web app under
> this package which made use of these modules to provide with SCA domain
> admin functionality. This was only working with a local SCA domain. So as I
> feel, it would be good, if we can get this web app to run with an ACE as the
> first phase, and then extend its functionality.
>
> This web app was available under org.apache.tuscany.sca.workspace.admin.* .
>
>  If this has been removed, then we can start it from the scratch by using
> the available workspace modules.  As an alternative to this, Ant has
> suggested to bring the available tuscany-geronimo intergration code to work
> with latest geronimo versions.
>
> In the mean time as Ant has suggested, it is better if we can set up an svn
> location to place my workings, so that everyone can see it.
>
> Any thoughts ?
>
> Thank You.
>
> regards,
> / thilina
>
>
>
> On Wed, May 28, 2008 at 7:49 PM, Luciano Resende <[EMAIL PROTECTED]>
> wrote:
>
>> The tuscany-workspace-xxx modules are still available :
>>
>>  Directory of .\java\sca\modules
>>
>> 05/27/2008  09:12 PM  workspace
>> 05/27/2008  09:13 PM  workspace-impl
>> 05/27/2008  09:12 PM  workspace-xml
>>
>> On Wed, May 28, 2008 at 1:08 AM, Thilina Buddhika <[EMAIL PROTECTED]>
>> wrote:
>> > Hi,
>> >
>> > I started coding phase on Monday. As the first step, I took a svn update
>> and
>> > successfully built it. As discussed earlier in the mailing list (when
>> > preparing the proposal), it  was  decided to bring up the
>> tuscany-workspace-
>> > admin as a regular web application and run it inside Geronimo as the
>> first
>> > step.
>> >
>> >
>> > But I could not find this class and other related classes in my copy of
>> the
>> > Tuscany SCA  source.
>> >
>> >org.apache.tuscany.sca.workspace.admin.main.DomainAdminMain
>> >
>> > Has the workspace-admin been moved to a different package ?
>> >
>> > Thank You.
>> >
>> > regs,
>> > / thilina
>> >
>> >
>> >
>> > On Tue, May 6, 2008 at 11:21 AM, Thilina Buddhika <[EMAIL PROTECTED]>
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> I thought of briefing my work within last few days to Tuscany-dev, so
>> that
>> >> community can give feedback on it. The wiki page[1] will also be
>> updated
>> >> along with this.
>> >>
>> >> Nowadays I am reading about ACEs and Portlets. I was able to implement
>> a
>> >> simple ACE and deploy it in Geronimo.  Also it  was  possible to call
>> some
>> >> JSPs and Servlets within that ACE. I am digging more into this and
>> planning
>> >> to look at available web based SCA domain admin tool in Tuscany.
>> >>
>> >> thanks!
>> >>
>> >> best regards,
>> >> / thilina
>> >>
>> >> [1] -
>> >>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
>> >>
>> >> On Wed, Apr 30, 2008 at 7:03 PM, Thilina Buddhika <[EMAIL PROTECTED]
>> >
>> >> wrote:
>> >>
>> >>> Hi,
>> >>> Thanks Luciano for creating that wiki page. It is really easy to work
>> with
>> >>> confluence wiki. I created a child page[1] and moved my content to it,
>> from
>> >>> my earlier wiki page. I'll be use this new wiki page from now onwards.
>> >>>
>> >>> thanks!
>> >>>
>> >>> best regards,
>> >>> / thilina
>> >>>
>> >>> [1] -
>> >>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
>> >>>
>> >>>
>> >>> On Tue, Apr 29, 2008 at 9:05 PM, Luciano Resende <
>> [EMAIL PROTECTED]>
>> >>> wrote:
>> >>>
>>  Hi Thilina
>> 
>>    Thanks for taking the initiative and creating the wiki page. I just
>>  created a wiki page/section to be used for GSoC 2008 [1], at the
>>  Tuscany Wiki, maybe you and all other students create child pages and
>>  use that one.
>> 
>>  [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/GSoC+2008
>> 
>>  On Tue, Apr 29, 2008 at 6:08 AM, Thilina Buddhika <
>> [EMAIL PROTECTED]>
>>  wrote:
>>  > Hi,
>>  >  I started working on my project. According to the Google time
>> line[1],
>>  now
>>  >  it is the community bonding period. These days I am going through
>> the
>>  >  documentations again, and getting more familiar with the project.
>> I
>>  started
>>  >  a wiki page[2] to  display the current status of the project. I
>> will
>>  be
>>  >  frequently updating that wiki page. I will be using this thread to
>> for
>>  the
>>  >  discussions with th

Re: [VOTE] Release SDO 1.1.1

[ant elder]

It seems to work fine for me, the binary distribution ends up with a lib
folder containing:

backport-util-concurrent-3.0.jar
codegen-2.2.3.jar
codegen-ecore-2.2.3.jar
common-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
sample-sdo-1.1.1.jar
stax-api-1.0.1.jar
tuscany-sdo-api-r2.1-1.1.1.jar
tuscany-sdo-impl-1.1.1.jar
tuscany-sdo-lib-1.1.1.jar
tuscany-sdo-tools-1.1.1.jar
wstx-asl-3.2.1.jar
xsd-2.2.3.jar

I've put the distributions that I get from the 1.1.1-RC2 tag up at
http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC2, how do they look?

   ...ant

On Fri, Jun 6, 2008 at 6:18 PM, kelvin goodson <[EMAIL PROTECTED]>
wrote:

> Hi Luciano,
>   yes, I added that workaround,  and that satisfied most of the EMF jars,
> but not these two. It's odd, the 2 jars we need are there in the repository
> you suggested,  but maven will not download them.
>
> Kelvin.
>
> 2008/6/6 Luciano Resende <[EMAIL PROTECTED]>:
>
> > Did you try the workaround I mentioned before on this thread [1] where
> > I added a new repository ? It was actually for other jars, but might
> > help in this case as well...
> >
> > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31727.html
> >
> > On Fri, Jun 6, 2008 at 4:56 AM, kelvin goodson <[EMAIL PROTECTED]>
> > wrote:
> > > I've made all the changes required in the tag [1] to get rid of the
> felix
> > > jars, find and include the emf jars,  and I've removed the incubating
> > tag,
> > > DISCLAIMER files etc.  However,  I'm currently stumped as to why two
> emf
> > > jars available [2] and [3] don't get downloaded by the build.  The
> build
> > > output complains about URLs that, if cut and pasted into a browser,
> work
> > > fine.  Any clues to explain this odd maven behaviour are welcome.
> > >
> > > Kelvin
> > >
> > >
> > > [1]
> > >
> >
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/
> > > [2]
> > >
> >
> http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen/2.2.3/
> > > [3]
> > >
> >
> http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen-ecore/2.2.3/
> > >
> > > 2008/6/3 Rajini Sivaram <[EMAIL PROTECTED]>:
> > >
> > >> Kelvin,
> > >>
> > >> Sorry about the delay in getting back to you - I can see that you have
> > >> found
> > >> a solution. Yes, you are absolutely right, the felix framework should
> > use
> > >> scope "provided" since SdoBundleActivator is only used when SDO is
> > running
> > >> inside an OSGi container, and the framework classes are provided by
> the
> > >> container.
> > >>
> > >>
> > >> On 6/3/08, kelvin goodson <[EMAIL PROTECTED]> wrote:
> > >> >
> > >> > Just a thought,  would I be right in guessing that if ever our
> > >> > SdoBundleActivator is touched in the runtime,  then the environment
> > would
> > >> > be
> > >> > expected to provide the classes to satisfy
> > >> >
> > >> > import org.osgi.framework.BundleActivator;
> > >> > import org.osgi.framework.BundleContext;
> > >> >
> > >> > ?
> > >> >
> > >> > in which case I think declaring a "provided" scope for the felix
> > >> dependency
> > >> > would be the right way to do things
> > >> >
> > >> > Kelvin.
> > >> >
> > >> > 2008/6/3 kelvin goodson <[EMAIL PROTECTED]>:
> > >> >
> > >> > > Thanks Ant,  that looks like progress,  but the felix framework
> jar
> > is
> > >> > now
> > >> > > not in the list of distributed jars.
> > >> > >
> > >> > > Kelvin.
> > >> > >
> > >> > > 2008/6/3 ant elder <[EMAIL PROTECTED]>:
> > >> > >
> > >> > > Adding an exclude for felix to the distribution pom can fix that,
> eg
> > >> > here's
> > >> > >> local changes i have just tried:
> > >> > >>
> > >> > >> Index: src/main/assembly/bin.xml
> > >> > >>
> ===
> > >> > >> --- src/main/assembly/bin.xml   (revision 662488)
&

Re: TLP migration

[ant elder]

On Thu, May 22, 2008 at 11:55 AM, ant elder <[EMAIL PROTECTED]> wrote:




> We can also look at doing an official ASF press release, a couple of
> examples are the Synapse ones at [1] and [2]. We probably want to wait till
> we have the website migrated to the TLP before sending that out but I'll
> setup a wiki page for a press release that we can work on in the mean time.
>
>
See: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Graduation+PR

One of the emails about graduation PR suggests:

"Timing a release to happen just after the graduation is complete is
probably the best - saying "hey look we're a TLP" seems a bit weak news
wise, especially if it's before the bits are moved to TLP"
 - http://apache.markmail.org/message/s2qecqsd2d7o77cs

We've the 1.3 release being talked about now, i've (slowly) started on some
of the TLP migration tasks and hope to do that a bit more actively next week
so we should have http://tuscany.apache.org going soon, and there also the
Red Hat/JBoss news so we're starting to get some good content for a press
release. It would be good to get some quotes from high profile people or
customers using Tuscany, and another thing that would be good is to get some
stats - "Tuscany has had over one hundred thousand downloads" type of thing,
does anyone have some download numbers to hand?

   ...ant

Re: Build failure in helloworld-bpel sample

[ant elder]

On Fri, Jun 6, 2008 at 2:49 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

> Simon Nash wrote:
>
>> I did a recent svn update and rebuild and I'm seeing the following test
>> error from the helloworld-bpel sample.  Are other people seeing this?
>> Any ideas?
>>
>>  Simon
>>
>>  I have committed a fix (or at least a workaround) for this build
> break problem.  The revision number is r663938.
>
>
Just to confirm, this has fixed the problem for me and the sample now builds
ok.

   ...ant

[jira] Commented: (TUSCANY-2274) @Scope vTest failing intermittently

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2274:


One interesting part of this is it rarely happens to me when I build just the 
individual module but often happens when I'm building everything from the top 
sca folder. Doesn't make it easy to debug :-( 

> @Scope vTest failing intermittently 
> 
>
> Key: TUSCANY-2274
> URL: https://issues.apache.org/jira/browse/TUSCANY-2274
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
> Fix For: Java-SCA-Next
>
>
> The atScope1 vTest fails intermittently like this:
> ---
>  T E S T S
> ---
> Running 
> org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase
> Setting up
> Apr 26, 2008 5:00:57 PM 
> org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime buildComposite
> WARNING: Can't find monitor extension on the classpath
> GService->initGService
> atScope1
> Exception in thread "Thread-5" java.lang.IllegalArgumentException: Invalid 
> phase name: component.implementation
> at 
> org.apache.tuscany.sca.core.invocation.InvocationChainImpl.addInvoker(InvocationChainImpl.java:106)
> at 
> org.apache.tuscany.sca.core.invocation.InvocationChainImpl.addInvoker(InvocationChainImpl.java:70)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addImplementationInterceptor(RuntimeWireImpl.java:316)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:188)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain(RuntimeWireImpl.java:115)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getInvocationChain(RuntimeComponentServiceImpl.java:120)
> at 
> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.getInvoker(RuntimeSCAReferenceBindingProvider.java:232)
> ThreadB1->BService2
> ThreadB2->BService9
> at 
> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:245)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109)
> at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243)
> at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148)
> at $Proxy17.setCurrentState(Unknown Source)
> at 
> org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase$CThread.run(ScopeAnnotationTestCase.java:359)
> Exception in thread "Thread-4" org.osoa.sca.ServiceUnavailableException: 
> Service not found for component CComponent reference $self$.CService (bi
> ndingURI=/CComponent operation=getName). Ensure that the composite containing 
> the service is loaded and started somewhere in the SCA domain and t
> hat if running in a remote node that the interface of the target service 
> marked as @Remotable
> at 
> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:247)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109)
> at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243)
> at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148)
> at $Proxy17.setCurrentState(Unknown Source)
> at 
> org.apache.tuscany.sca.vtest.javaapi.annotations.

Re: Red Hat/JBoss involvement with Tuscany

[ant elder]

On Fri, Jun 6, 2008 at 11:12 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> On Fri, Jun 6, 2008 at 10:57 AM, Mark Little <[EMAIL PROTECTED]> wrote:
>
> > Hi, I just wanted to let people know officially that people from Red
> > Hat/JBoss will be getting involved with Tuscany over the coming months as
> we
> > look at the best way in which to provide SCA support for our SOA Platform
> > users. We're very excited about helping on Tuscany and complimenting the
> > work we're doing at OASIS.
> >
> > Mark.
> >
> > 
> > Mark Little
> > [EMAIL PROTECTED]
> >
> > JBoss, a Division of Red Hat
> > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> Street,
> > Windsor, Berkshire, SI4 1TE, United Kingdom.
> > Registered in UK and Wales under Company Registration No. 3798903
> > Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> > (USA) and Brendan Lane (Ireland).
> >
> >
> Hi Mark
>
> That's exciting news indeed. Welcome to you all!
>
> Regards
>
> SimonL
>

Echoing that sentiment, this is really great news. I look forward to working
with you all.

   ...ant

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

That seems a little odd to me, i'd prefer just "snapshot", 1.x, or the
actual next number over 1.5.

   ...ant

On Fri, Jun 6, 2008 at 9:17 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> How about 1.5-SNAPSHOT ? This would probably give us some room to have
> couple releases without the necessity to keep updating the trunk pom
> version. And this would probably make everybody happy :)
>
> On Fri, Jun 6, 2008 at 1:14 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende <[EMAIL PROTECTED]>
> > wrote:
> >
> >> I guess part of problem here is because a lot of people assume that
> >> the maven artifact version represents what is going to be our next
> >> release and then, if it's set as 2.0-SNAPSHOT, it means our next
> >> release would be 2.0.
> >
> >
> > I agree, this is exactly the issue. But I'm not sure its that much of an
> > unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as
> the
> > trunk version before there has been any decision to start working on a
> 2.0
> > in trunk.
> >
> >   ...ant
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>

Re: Release 1.3?

[ant elder]

+1 from me. Incidentally I've spent a bit of time over the last couple of
days trying all the various samples and demos etc with the latest trunk code
and its all looking in quite good shape so it does seem like a fine time to
be taking a release branch.

   ...ant

On Fri, Jun 6, 2008 at 9:21 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> It's been a little while now since we did our 1.2 release. Since then there
> has been lots of activity and of course we have graduated. It feels like
> the
> right time to do a 1.3 release. Looking back at the mail list over the last
> couple of months there are quite a few candidates for inclusion that I can
> see;
>
> Better BPEL support
> Improvements to the domain manager app
> Improved runtime Java2WSDL processing
> Support for validation monitoring
> Databinding improvements
> Performance improvements
> JSR250 annotation support
> OSGi support improvements and a simple OSGi runtime test
> Java 2 security enablement
> Quite a few more tests for various parts of the runtime
> Lots of JIRA fixes.
> and of course we can remove the "incubating" assignment and drum up a bit
> of
> publicity for our TLP graduation
>
> I'd also like to have a bit of a tidy up for this release and remove the
> old
> domain modules we are no longer using (I'll post on this separately)
>
> What else has been added or changed?
>
> I think the things I would like to get done can be closed off next week
> ready to cut a branch.
>
> Thoughts?
>
> Simon
>

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> I guess part of problem here is because a lot of people assume that
> the maven artifact version represents what is going to be our next
> release and then, if it's set as 2.0-SNAPSHOT, it means our next
> release would be 2.0.


I agree, this is exactly the issue. But I'm not sure its that much of an
unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as the
trunk version before there has been any decision to start working on a 2.0
in trunk.

   ...ant

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

Which number?

If we pick the next number - we've just done a 1.2 release so the trunk
version could now be "1.3-SNAPSHOT" which is the way we've done in the past
-  then every time we branch for the next release we also have to update the
trunk. Thats a bit more work but also it means that *everyone* who has a
dependency on Tuscany which specifies the trunk snapshot version now also
has to notice we've changed and make a corresponding change to their
dependency version.

Personally I like the simple "SNAPSHOT" as it lets you get the latest
development code without having to pay close attention to whats going on in
trunk or ever touch the trunk version again. But using "1.x-SNAPSHOT" would
also mostly avoid both of those problems mentioned above.


   ...ant

On Fri, Jun 6, 2008 at 8:44 AM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Ant,
>
> +1 in general - by why not simply choose a number, rather than "x"?
> - the problem with "x" is "what comes next?"
>
> Yours,  Mike.
>
>
> ant elder wrote:
>
>>
>> Lots of different views so far on this thread, better than no one replying
>> :) I'm tempted to go with "1.x-SNAPSHOT" as I think from whats been said
>> most would be ok with that, please say if you would _not_ be unhappy with
>> it. Note that all other projects I've looked at use either a specific
>> numeric number followed by the "-SNAPSHOT" suffix, or else just the string
>> "SNAPSHOT" for the trunk version, so having the letter "x" as part of our
>> version number makes for an "unusual" version name. Don't see why it
>> shouldn't work though.
>>
>>  ...ant
>>
>>
>

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

On Thu, Jun 5, 2008 at 8:43 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> Simon Laws wrote:
>>
>> On Wed, Jun 4, 2008 at 1:34 PM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:
>>
>>> 2008/6/4 ant elder <[EMAIL PROTECTED]>:
>>>>
>>>> Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need
to
>>>> remove "incubating" at some point and as its not clear if the next
>>>
>>> release
>>>>
>>>> would be 2.0 or something else so i wondered if we should also remove
>>>> the
>>>> 2.0 giving a trunk version of simply "SNAPSHOT"? Any comments on that
or
>>>
>>> the
>>>>
>>>> timeframe for doing the change? I'd like to do it nowish so we have
some
>>>> time to discover any problems before the next release.
>>>>
>>>>  ...ant
>>>>
>>> Hi ant,
>>> could you try a fresh build from svn?
>>> I've some problems with and I 'd go on with my work before we're
>>> arriving to 2.0.
>>>
>>>
>>> Ciao,
>>> Giorgio.
>>> ---
>>> "Venceremos adelante, o victoria o muerte!"
>>>
>>
>> I agree that it doesn't feel like the next release will be 2.0
>> I would prefer that we keep the trunk compatible with our 1.X level APIs
>> for
>> the time being as it feels like there is still a more 1.X releases to do
>> If people are going to start making breaking changes in a branch (we
>> discussed this under the 2.0 thread but it's not happening yet) then it
>> would be useful to me to have the trunk poms marked with 1.X SNAPSHOT so
>> that I know by looking on my disc what I'm working with
>> When (if?) the time comes down the line to break from our 1.X APIs we
>> could
>> then go to SNAPSHOT  or 2.0 SNAPSHOT
>>
> I think it's useful to have some version number.  "1.x" seems to clearly
> describe what we are currently developing in trunk, so my preference
> is for "1.x-SNAPSHOT".
>
>  Simon
>

Lots of different views so far on this thread, better than no one replying
:) I'm tempted to go with "1.x-SNAPSHOT" as I think from whats been said
most would be ok with that, please say if you would _not_ be unhappy with
it. Note that all other projects I've looked at use either a specific
numeric number followed by the "-SNAPSHOT" suffix, or else just the string
"SNAPSHOT" for the trunk version, so having the letter "x" as part of our
version number makes for an "unusual" version name. Don't see why it
shouldn't work though.

  ...ant

Re: SCA 1.2.1 release

[ant elder]

The vote for the 1.2.1 release has now passed -
http://apache.markmail.org/message/s23xtktwohpfaacq. I'm a bit busy so will
take a little while to get the website etc updated (unless anyone wants to
help sooner?) but I've copied the artifacts to the maven repository so they
are now publicly available to use.

   ...ant

On Mon, Jun 2, 2008 at 10:47 AM, Dave Sowerby <[EMAIL PROTECTED]>
wrote:

> Hey Ant,
>
> Thanks for offering to perform this task!
>
> Have you managed to make any progress with this?
>
> Cheers,
>
> Dave.
>
> On Thu, May 29, 2008 at 10:15 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > Yes, now that it looks like everyone wants this to go ahead I'll go do
> this,
> > not sure if I'll have time to finish it today and I'm out tomorrow but
> I'll
> > try to make sure the artifacts are built and available by the end of the
> > weekend.
> >
> >   ...ant
> >
> > On Thu, May 29, 2008 at 10:07 AM, Dave Sowerby <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi All,
> >>
> >> Could anyone give me any time scales for the 1.2.1 release?
> >>
> >> The release I'm preparing is due to be released within the next week
> >> and is unfortunately blocked awaiting this update.
> >>
> >> I'm available to assist in any way necessary.
> >>
> >> Cheers,
> >>
> >> Dave.
> >>
> >> On Wed, May 28, 2008 at 7:13 AM, haleh mahbod <[EMAIL PROTECTED]>
> wrote:
> >> > I can help with validating the samples and demos for 1.2.1.
> >> >
> >> > On 5/27/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> On Tue, May 27, 2008 at 6:26 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> > Dave Sowerby wrote:
> >> >> >
> >> >> >> Hi Simon,
> >> >> >>
> >> >> >> With regards to the 1.2.1 release you are correct that we have a
> >> >> >> patched version of tuscany-sca-all which would work, but this
> however
> >> >> >> leaves us in an awkward configuration position.
> >> >> >>
> >> >> >> We're currently preparing a software release based around Tuscany
> >> >> >> which is completely open to customers of our use of Tuscany, such
> >> that
> >> >> >> we document fully how to construct services independent of our
> >> >> >> software.  As such, we do not ship any Tuscany artifacts and
> instead
> >> >> >> encourage our customers to utilise the published maven repository.
> >> >> >> Whilst requiring a patch version of one of the jars is possible; I
> >> >> >> don't feel that this is a good representation of Tuscany - either
> >> >> >> documenting a variant version or expecting a non-standard version
> of
> >> >> >> 1.2-incubating.  These potential solutions are more likely to
> cause
> >> >> >> issues for customers that would undermine the image of Tuscany
> that
> >> we
> >> >> >> try to project.
> >> >> >>
> >> >> >> Is anyone adamantly opposed to this release?  Do you feel Tuscany
> >> >> >> 1.2.1 is still an option?  I'd hope that given the potential to
> >> damage
> >> >> >> our customer's perception of Tuscany would be enough to justify
> this
> >> >> >> minor release.
> >> >> >>
> >> >> >>  Thanks for the clarifaction and explanation.  It seems to me that
> >> >> > because we distribute Tuscany via Maven repos, which can't be
> patched,
> >> >> > this kind of situation will arise whenever a serious bug is found.
> >> >> > We can use patches to isolate a problem and confirm the fix, but we
> >> >> > generally won't be able to use them as an alternative to a release.
> >> >> >
> >> >> > In a situation like this, unless a new release is imminent, the
> best
> >> >> > solution seems to be to produce a quick "bug fix" release without
> >> >> > incurring the overhead of a full release and testing cycle.  Ant
> has
> >> >> > suggested that we could do this by applying a small set of
> carefully
> >> >> > controlled changes to the previous 1.2 release tag

[jira] Closed: (TUSCANY-2369) sample-calculator-ws-webapp fails to deploy

[ant elder (JIRA)]

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

ant elder closed TUSCANY-2369.
--

Resolution: Fixed

Works fine today now when i try to debug it with a fresh build

> sample-calculator-ws-webapp fails to deploy
> ---
>
> Key: TUSCANY-2369
> URL: https://issues.apache.org/jira/browse/TUSCANY-2369
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-Next
>Reporter: ant elder
> Fix For: Java-SCA-Next
>
>
> sample-calculator-ws-webapp fails to deploy on Tomcat with the following:
> org.osoa.sca.ServiceRuntimeException: 
> java.lang.reflect.InvocationTargetException
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:83)
>   at 
> org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:218)
>   at 
> org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:52)
>   at 
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
>   at 
> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
>   at 
> org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108)
>   at 
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3709)
>   at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4356)
>   at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
>   at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
>   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
>   at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:829)
>   at 
> org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:718)
>   at 
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
>   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1147)
>   at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
>   at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
>   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
>   at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
>   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
>   at 
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
>   at 
> org.apache.catalina.core.StandardService.start(StandardService.java:516)
>   at 
> org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
>   at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
>   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:258)
>   ... 30 more
> Caused by: java.lang.NoSuchMethodError: 
> org.apache.tuscany.sca.databinding.DataBinding.getXMLTypeHelperClass()Ljava/lang/Class;
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:515)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:487)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:383)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.interface2ws

Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console

[ant elder]

How are you doing with this, is there anything we can help with? How about
we create some place in SVN so you have somewhere to work on you code within
Tuscany?

   ...ant

On Wed, May 28, 2008 at 9:08 AM, Thilina Buddhika <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> I started coding phase on Monday. As the first step, I took a svn update
> and
> successfully built it. As discussed earlier in the mailing list (when
> preparing the proposal), it  was  decided to bring up the
> tuscany-workspace-
> admin as a regular web application and run it inside Geronimo as the first
> step.
>
>
> But I could not find this class and other related classes in my copy of the
> Tuscany SCA  source.
>
>org.apache.tuscany.sca.workspace.admin.main.DomainAdminMain
>
> Has the workspace-admin been moved to a different package ?
>
> Thank You.
>
> regs,
> / thilina
>
>
>
> On Tue, May 6, 2008 at 11:21 AM, Thilina Buddhika <[EMAIL PROTECTED]>
> wrote:
>
> > Hi,
> >
> > I thought of briefing my work within last few days to Tuscany-dev, so
> that
> > community can give feedback on it. The wiki page[1] will also be updated
> > along with this.
> >
> > Nowadays I am reading about ACEs and Portlets. I was able to implement a
> > simple ACE and deploy it in Geronimo.  Also it  was  possible to call
> some
> > JSPs and Servlets within that ACE. I am digging more into this and
> planning
> > to look at available web based SCA domain admin tool in Tuscany.
> >
> > thanks!
> >
> > best regards,
> > / thilina
> >
> > [1] -
> >
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
> >
> > On Wed, Apr 30, 2008 at 7:03 PM, Thilina Buddhika <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi,
> >> Thanks Luciano for creating that wiki page. It is really easy to work
> with
> >> confluence wiki. I created a child page[1] and moved my content to it,
> from
> >> my earlier wiki page. I'll be use this new wiki page from now onwards.
> >>
> >> thanks!
> >>
> >> best regards,
> >> / thilina
> >>
> >> [1] -
> >>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
> >>
> >>
> >> On Tue, Apr 29, 2008 at 9:05 PM, Luciano Resende <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> Hi Thilina
> >>>
> >>>   Thanks for taking the initiative and creating the wiki page. I just
> >>> created a wiki page/section to be used for GSoC 2008 [1], at the
> >>> Tuscany Wiki, maybe you and all other students create child pages and
> >>> use that one.
> >>>
> >>> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/GSoC+2008
> >>>
> >>> On Tue, Apr 29, 2008 at 6:08 AM, Thilina Buddhika <[EMAIL PROTECTED]
> >
> >>> wrote:
> >>> > Hi,
> >>> >  I started working on my project. According to the Google time
> line[1],
> >>> now
> >>> >  it is the community bonding period. These days I am going through
> the
> >>> >  documentations again, and getting more familiar with the project. I
> >>> started
> >>> >  a wiki page[2] to  display the current status of the project. I will
> >>> be
> >>> >  frequently updating that wiki page. I will be using this thread to
> for
> >>> the
> >>> >  discussions with the community.
> >>> >
> >>> >  thanks!
> >>> >
> >>> >  best regards,
> >>> >  / thilina
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >  [1] -
> >>> http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> >>> >  [2] -
> >>> http://wiki.apache.org/incubator/ThilinaBuddhika/GSoC2008_status
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Luciano Resende
> >>> Apache Tuscany Committer
> >>> http://people.apache.org/~lresende
> 
> >>> http://lresende.blogspot.com/
> >>>
> >>
> >>
> >
> >
> > --
> > E-Mail : [EMAIL PROTECTED]
> > I blog here : http://thilinamb.blogspot.com
>
>
>
>
> --
> E-Mail : [EMAIL PROTECTED]
> I blog here : http://thilinamb.blogspot.com
>

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

On Wed, Jun 4, 2008 at 5:59 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> The good thing about having a version on the pom is that you can have
> multiple SNAPSHOTs available in a maven repo (e.g 1.2-SNAPSHOT,
> 1.2.1-SNAPSHOT, TRUNK x-SNAPSHOT and TRUNK y-SNAPSHOT), this also
> allows for multiple active development streams.
>
> If you have SNAPSHOT only, I guess you are restricted to only latest
> SNAPSHOT, and I also don't see how you would be able to have multiple
> active development streams in this case.
>
>
Well I don't think we should be having "multiple active development streams"
:) Fine to have historic 1.x, 2.x, 3.x etc branches which are kept alive for
maintenance, and that will work fine with trunk being just SNAPSHOT. But
we're a small group of active committers still learning how to get consensus
on things and i worry it could easily end quite badly if we have multiple
trunks all being developed in parralel competing to be the next new version.

   ...ant

[RESULT] [Vote] Release Tuscany Java SCA 1.2.1 (RC1)

[ant elder]

Passed with +1s from me, Luciano Resende, Dave Sowerby, Vamsavardhana Reddy
, Dan Becker, Simon Laws, Davanum Srinivas, and affirmative comments from
Mike Edwards  and haleh mahbod.

Thanks everyone for participating.

   ...ant

On Sun, Jun 1, 2008 at 10:10 PM, ant elder <[EMAIL PROTECTED]> wrote:

> Please review and vote on the release artifacts for the Tuscany SCA for
> Java 1.2.1 maintenance release.
>
> The artifacts are available for review at:
> http://people.apache.org/~antelder/tuscany/1.2.1-RC1/<http://people.apache.org/%7Eantelder/tuscany/1.2.1-RC1/>
>
> This includes the signed binary and source distributions, Maven staging
> repository, and eclipse update site.
>
> The SVN tag for the release is:
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2.1
>
> The _only_ code change in this over the 1.2 release is in r657526 [1], all
> other changes are just version updates and doc changes for the release.
>
> +1 to release from me.
>
>...ant
>
> [1]
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200805.mbox/[EMAIL
>  PROTECTED]
>
>
>

Re: JMS Client

[ant elder]

On Wed, Jun 4, 2008 at 11:21 AM, Nishant Joshi <[EMAIL PROTECTED]>
wrote:

> Thanks Ant,
> I have composed client for WS Here is the snippet of the client
>
>
> -
>
> public class HelloWorldClientImpl {
>
>@Reference
>protected HelloWorldService serviceA;
>
>public String sayHello(String name) {
> System.out.println("HelloWorldClientImpl.serviceA = "+serviceA);
>return serviceA.sayHello(name);
>}
>
> }
>
> -
> @Remotable
> public interface HelloWorldService {
>String sayHello(String name);
> }
>
>
> -
> public class JMSClient {
>  public static void main(String[] args) throws NodeException  {
>  SCANode node = SCANodeFactory.createNodeWithComposite("client.composite");
>  HelloWorldClientImpl client =
> node.getDomain().getService(HelloWorldClientImpl.class,
> "HelloWorldClient");
>
>  System.out.println(client.sayHello("World"));
>  }
>
> }
>
>
> -
>
> http://www.osoa.org/xmlns/sca/1.0";
>   name="RPCComposite">
>
>
>
>
>
>
>
>
> initialContextFactory="com.ibm.websphere.naming.WsnInitialContextFactory"
> jndiURL="iiop://localhost:2809">
>
>
>   
>
>
>
> 
>
> -
> jndi.properties
>
> # START SNIPPET: jndi
>
> java.naming.factory.initial =
> com.ibm.websphere.naming.WsnInitialContextFactory
>
> # use the following property to configure the default connector
> java.naming.provider.url = vm://localhost?broker.persistent=false
>
> # use the following property to specify the JNDI name the connection
> factory
> # should appear as.
> #connectionFactoryNames = connectionFactory, queueConnectionFactory,
> topicConnectionFactry
> connectionFactoryNames = ConnectionFactory
>
> # register some queues in JNDI using the form
> # queue.[jndiName] = [physicalName]
> # queue.RequestQueue = RequestQueue
> # queue.ResponseQueue = ResponseQueue
> queue.HelloWorldService = HelloWorldService
>
> # register some topics in JNDI using the form
> # topic.[jndiName] = [physicalName]
> #topic.MyTopic = example.MyTopic
>
> # END SNIPPET: jndi
>
>
> Here Service is deployed successfuly, i can test with hello.jspIt was
> working fine in WS.
> Now when i run above code I m getting "HelloWorldClientImpl.serviceA =
> null"
> and gettign NPE
> I m using "HelloWorldService" for both Request and Response queue...
>
> any idea ?
>
> Thanks
> Nishant Joshi


I'll give it a try but it will take a while as I'm still recovering from a
harddrive crash last week so will need to find and reinstall WebSphere.
Anyone else with WAS installed able to give this a try in the meantime with
the helloworld-jms-webapp sample?

   ...ant

[jira] Commented: (TUSCANY-2357) CORBA objects invocation mechanism

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2357:


Applied license header patch in r663066, thanks for the patch!

> CORBA objects invocation mechanism
> --
>
> Key: TUSCANY-2357
> URL: https://issues.apache.org/jira/browse/TUSCANY-2357
> Project: Tuscany
>  Issue Type: New Feature
>Reporter: Wojtek Janiszewski
> Attachments: add-license-headers.patch.tar.gz, 
> corba-operation-invoker.patch.tar.gz
>
>
> Implementation of generic mechanism for remote operation invocation: passing 
> CORBA structures, sequences, primitives as arguments, retrieving return 
> values (also structs, seq, prims.). There is no exception handling yet. 
> It's not connected to CORBA binding extension yet - it won't be hard, and I 
> think it's now more important  to complete this generic mechanism.
> Some tests are provided - you need to have tnameserv in your PATH to run 
> tests correctly!

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

Re: [jira] Updated: (TUSCANY-2357) CORBA objects invocation mechanism

[ant elder]

Thanks for reminding, i'm applying it now.

   ...ant

On Wed, Jun 4, 2008 at 12:17 PM, Wojtek Janiszewski <
[EMAIL PROTECTED]> wrote:

> Hi,
> I'm starting to worry that following patch will be orphaned :). Could
> anyone take a look?
> Thanks,
> Wojtek
>
>
> Wojtek Janiszewski (JIRA) wrote:
>
>> [
>> https://issues.apache.org/jira/browse/TUSCANY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>
>> Wojtek Janiszewski updated TUSCANY-2357:
>> 
>>
>>Attachment: add-license-headers.patch.tar.gz
>>
>> Thanks for reminding. Here's a patch which adds headers to all java and
>> idl files.
>> Wojtek
>>
>>  CORBA objects invocation mechanism
>>> --
>>>
>>>Key: TUSCANY-2357
>>>URL: https://issues.apache.org/jira/browse/TUSCANY-2357
>>>Project: Tuscany
>>> Issue Type: New Feature
>>>   Reporter: Wojtek Janiszewski
>>>Attachments: add-license-headers.patch.tar.gz,
>>> corba-operation-invoker.patch.tar.gz
>>>
>>>
>>> Implementation of generic mechanism for remote operation invocation:
>>> passing CORBA structures, sequences, primitives as arguments, retrieving
>>> return values (also structs, seq, prims.). There is no exception handling
>>> yet. It's not connected to CORBA binding extension yet - it won't be hard,
>>> and I think it's now more important  to complete this generic mechanism.
>>> Some tests are provided - you need to have tnameserv in your PATH to run
>>> tests correctly!
>>>
>>
>>
>

Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need to
remove "incubating" at some point and as its not clear if the next release
would be 2.0 or something else so i wondered if we should also remove the
2.0 giving a trunk version of simply "SNAPSHOT"? Any comments on that or the
timeframe for doing the change? I'd like to do it nowish so we have some
time to discover any problems before the next release.

   ...ant

[jira] Created: (TUSCANY-2370) sample-feed-aggregator-webapp gets 404 error on the feed urls

[ant elder (JIRA)]

sample-feed-aggregator-webapp gets 404 error on the feed urls
-

 Key: TUSCANY-2370
 URL: https://issues.apache.org/jira/browse/TUSCANY-2370
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-Next
Reporter: ant elder
 Fix For: Java-SCA-Next


The sample-feed-aggregator-webapp says: To read the aggregated feeds, point 
your Web browser to the following addresses:

http://localhost:8080/sample-feed-aggregator-webapp/atomAggregator
http://localhost:8080/sample-feed-aggregator-webapp/atomAggregator/atomsvc (for 
the Atom service document)
http://localhost:8080/sample-feed-aggregator-webapp/rssAggregator

but all three URLs give a 404 

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

[jira] Created: (TUSCANY-2369) sample-calculator-ws-webapp fails to deploy

[ant elder (JIRA)]

sample-calculator-ws-webapp fails to deploy
---

 Key: TUSCANY-2369
 URL: https://issues.apache.org/jira/browse/TUSCANY-2369
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-Next
Reporter: ant elder
 Fix For: Java-SCA-Next


sample-calculator-ws-webapp fails to deploy on Tomcat with the following:

org.osoa.sca.ServiceRuntimeException: 
java.lang.reflect.InvocationTargetException
at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:83)
at 
org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:218)
at 
org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:52)
at 
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
at 
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
at 
org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108)
at 
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3709)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4356)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:829)
at 
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:718)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1147)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:258)
... 30 more
Caused by: java.lang.NoSuchMethodError: 
org.apache.tuscany.sca.databinding.DataBinding.getXMLTypeHelperClass()Ljava/lang/Class;
at 
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:515)
at 
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:487)
at 
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:383)
at 
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:159)
at 
org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:193)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.(Axis2ReferenceBindingProvider.java:68)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:70)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:47)
at

itest/validation problem

[ant elder]

I'm getting a test fail in itest/validation with the failed test:
testCalculator(impl.resource.CouldNotResolveLocationTestCase). Does this
work or fail for anyone else?

   ...ant

Re: svn commit: r663002 - in /incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources: tuscany-sca-data-helper.xsd tuscany-sca-implementation-das.xsd tuscany-sca-implementation-data-xml.xsd

[ant elder]

I'm getting a build failure in modules/assembly-xml after this with the
error below, does anyone else see that? Commenting out the includes for
implementation-das and data-xml gets it going again.

testReadBinding(org.apache.tuscany.sca.assembly.xml.ReadDocumentTestCase)
Time elapsed: 0.032 sec  <<< ERROR!
java.lang.IllegalStateException: org.xml.sax.SAXParseException:
cos-nonambig: WC["http://tuscany.apache.org/xmlns/sca/1.
0"] and "http://tuscany.apache.org/xmlns/sca/1.0":ConnectionInfo (or
elements from their substitution group) violate "Un
ique Particle Attribution". During validation against this schema, ambiguity
would be created for those two particles.
at
org.apache.tuscany.sca.contribution.processor.DefaultValidatingXMLInputFactory.initializeSchemas(DefaultValid
atingXMLInputFactory.java:135)

   ...ant

On Wed, Jun 4, 2008 at 7:27 AM, <[EMAIL PROTECTED]> wrote:

> Author: lresende
> Date: Tue Jun  3 23:27:11 2008
> New Revision: 663002
>
> URL: http://svn.apache.org/viewvc?rev=663002&view=rev
> Log:
> Schema for implementation.das and implementation.data
>
> Added:
>
>  
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>   (with props)
>
>  
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
>   (with props)
>
>  
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-data-xml.xsd
>   (with props)
> Modified:
>
>  
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca.xsd
>
> Added:
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd?rev=663002&view=auto
>
> ==
> ---
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
> (added)
> +++
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
> Tue Jun  3 23:27:11 2008
> @@ -0,0 +1,44 @@
> +
> +
> +http://www.w3.org/2001/XMLSchema";
> +targetNamespace="http://data.tuscany.apache.org/xmlns/sca/1.0";
> +xmlns:sca="http://www.osoa.org/xmlns/sca/1.0";
> +xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
> +xmlns:data="http://data.tuscany.apache.org/xmlns/sca/1.0";
> +elementFormDefault="qualified">
> +
> +
> +   
> +   
> +   
> +   
> +   
> +
> +
> +
> +   
> ++   name="ConnectionProperties"
> type="data:ConnectionProperties" />
> +   
> +   
> ++   default="true" />
> +
> +
>
> Propchange:
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>
> --
>svn:eol-style = native
>
> Propchange:
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>
> --
>svn:keywords = Rev Date
>
> Propchange:
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>
> --
>svn:mime-type = text/xml
>
> Added:
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd?rev=663002&view=auto
>
> ==
> ---
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
> (added)
> +++
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
> Tue Jun  3 23:27:11 2008
> @@ -0,0 +1,46 @@
> +
> +
> +http://www.w3.org/2001/XMLSchema";
> +targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0";
> +xmlns:sca="http://www.osoa.org/xmlns/sca/1.0";
> +xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
> +xmlns:data="http://data.tuscany.apache.org/xmlns/sca/1.0";
> +elementFormDefault="qualified">
> +
> +http://www.osoa.org/xmlns/sca/1.0";
> schemaLocation="sca-core.xsd"/>
> +http://data.tuscany.apache.org/xmlns/sca/1.0";
> schemaLocation="tuscany-sca-data-helper.xsd"/>
> +
> +
> +
> +
> +
> +
> +
> + processContents="lax"
> +   minOccurs="0" maxOccurs="unbounded"/>
> + name="ConnectionInfo"
> +type="data:ConnectionInfo"/>
> +
> +
> + use="required"/>
> +   

Re: JMS Client

[ant elder]

On Wed, Jun 4, 2008 at 6:08 AM, Nishant Joshi <[EMAIL PROTECTED]>
wrote:

>  Hi All,
> I m new to JMS, I have a question regarding a JMS client means How can i
> access Tuscnay JMS service remotely.
> I have refered sample from
>
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-jms-webapp/
> and
> deployed it on WS with instruction given on README file. It was working
> fine
> and i can access a client jsp given with the sample.
> so in binding.ws i can pass a service url and access the service from my
> client which was remote means on diff machine.
> So how can it be possible with binding.jms ?
> Ex. I have one Sample service which was deployed on machine X and port 8080
> so my service address is like
> http://X:8080/MyService/MyComponent 
> so this is the url where wsdl was generating.
>
> now from client side (which was on machine Y) scdl i have following kinda
> structure...
>
> 
>  
>  
>  
>
>  
>  
>  http://X:8080/MyService/MyComponent<
> http://x:8080/MyService/MyComponent>"
> />
>  
>
>
> so I want same kinda sample for binding.jms
> has anybody try this ?
>
>
> --
> Thanks
> Nishant Joshi
>

Yes you can do this by telling the client where the remote JMS broker is.
You do that with the jndiURL and initialContextFactory attributes of the JMS
binding. There's an example of this in an testcase at
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/jms/src/main/resources/external/client.composite.
That test uses ActiveMQ, I've not actually tried this on WebShpere but I
think by default the JNDI port is 2809 and the initialContextFactory class
is com.ibm.websphere.naming.WsnInitialContextFactory.


   ...ant

Re: parent pom and incubator references

[ant elder]

On Tue, Jun 3, 2008 at 2:24 PM, kelvin goodson <[EMAIL PROTECTED]>
wrote:

> As mentioned elsewhere on this list in the discussion about respinning the
> SDO 1.1.1 RC, I'm hoping to drop the "incubating" tag in the release name.
>
> This has led me to look at the parent pom,  and I guess we need a new
> version of parent pom that doesn't reference the incubator repo,  and then
> open a vote on that.  I may be opening a whole new kettle of Pandora's
> worms
> that would have been best left unopened for a point release. On the other
> hand I guess it needs doing some time soon.  Digging around a few other top
> level projects, and seeing the comments in our own parent pom,  it would
> appear I might be able to just drop the "apache.incubator" repository
> stanza
> in a new revision of the parent pom.  Is that true?  any guidance would be
> very welcome.
>
> Kelvin.
>

How about removing the reference to the Tuscany parent pom and just defining
whatever is required in the top level SDO pom.xml. We talked about doing
this once before - http://apache.markmail.org/message/2woxtw7lfalm3rtx. The
only concern was if it caused trouble if building all the subprojects under
tuscany/java together, but does anyone ever do that these days?

   ...ant

Re: [VOTE] Release SDO 1.1.1

[ant elder]

Sounds good to me.

   ...ant

On Tue, Jun 3, 2008 at 1:03 PM, kelvin goodson <[EMAIL PROTECTED]>
wrote:

> OK,  I think I have everything I need now to respin this RC.  I'm inclined
> to take the opportunity to remove the "incubating" tag on this release
> whilst I'm fixing up the poms.
>
> Kelvin.
>
> 2008/6/3 ant elder <[EMAIL PROTECTED]>:
>
> That sounds right to me.
>>
>>   ...ant
>>
>> On Tue, Jun 3, 2008 at 11:57 AM, kelvin goodson <[EMAIL PROTECTED]>
>> wrote:
>>
>> > Just a thought,  would I be right in guessing that if ever our
>> > SdoBundleActivator is touched in the runtime,  then the environment
>> would
>> > be
>> > expected to provide the classes to satisfy
>> >
>> > import org.osgi.framework.BundleActivator;
>> > import org.osgi.framework.BundleContext;
>> >
>> > ?
>> >
>> > in which case I think declaring a "provided" scope for the felix
>> dependency
>> > would be the right way to do things
>> >
>> > Kelvin.
>> >
>> > 2008/6/3 kelvin goodson <[EMAIL PROTECTED]>:
>> >
>> > > Thanks Ant,  that looks like progress,  but the felix framework jar is
>> > now
>> > > not in the list of distributed jars.
>> > >
>> > > Kelvin.
>> > >
>> > > 2008/6/3 ant elder <[EMAIL PROTECTED]>:
>> > >
>> > > Adding an exclude for felix to the distribution pom can fix that, eg
>> > here's
>> > >> local changes i have just tried:
>> > >>
>> > >> Index: src/main/assembly/bin.xml
>> > >> ===
>> > >> --- src/main/assembly/bin.xml   (revision 662488)
>> > >> +++ src/main/assembly/bin.xml   (working copy)
>> > >> @@ -120,13 +120,13 @@
>> > >> 
>> > >> 
>> > >>
>> > >> tuscany-sdo-${sdo.version}/lib
>> > >> -
>> > >> -
>> > >> org.apache.tuscany.sdo:tuscany-sdo-api-r2.1
>> > >> +
>> > >> 0644
>> > >> 
>> > >>
>> > >> Index: pom.xml
>> > >> ===
>> > >> --- pom.xml (revision 662488)
>> > >> +++ pom.xml (working copy)
>> > >> @@ -56,6 +56,12 @@
>> > >> org.apache.tuscany.sdo
>> > >> tuscany-sdo-impl
>> > >> ${pom.version}
>> > >> +
>> > >> +
>> > >> +org.apache.felix
>> > >> +org.apache.felix.main
>> > >> +
>> > >> +
>> > >> 
>> > >> 
>> > >> org.apache.tuscany.sdo
>> > >> @@ -67,6 +73,7 @@
>> > >> sample-sdo
>> > >> ${pom.version}
>> > >> 
>> > >> +
>> > >> 
>> > >>
>> > >> 
>> > >>
>> > >> Which results in a lib directory containing:
>> > >>
>> > >> backport-util-concurrent-3.0.jar
>> > >> codegen-2.2.3.jar
>> > >> codegen-ecore-2.2.3.jar
>> > >> common-2.2.3.jar
>> > >> ecore-2.2.3.jar
>> > >> ecore-change-2.2.3.jar
>> > >> ecore-xmi-2.2.3.jar
>> > >> sample-sdo-1.1.1-incubating-SNAPSHOT.jar
>> > >> stax-api-1.0.1.jar
>> > >> tuscany-sdo-api-r2.1-1.1.1-incubating-SNAPSHOT.jar
>> > >> tuscany-sdo-impl-1.1.1-incubating-SNAPSHOT.jar
>> > >> tuscany-sdo-lib-1.1.1-incubating-SNAPSHOT.jar
>> > >> tuscany-sdo-tools-1.1.1-incubating-SNAPSHOT.jar
>> > >> wstx-asl-3.2.1.jar
>> > >> xsd-2.2.3.jar
>> > >>
>> > >>...ant
>> > >>
>> > >> On Tue, Jun 3, 2008 at 11:31 AM, kelvin goodson <
>> [EMAIL PROTECTED]>
>> > >> wrote:
>> > >>
>> > >> > I had an offline chat with Rajini.  It seems we need just the
>> > framework
>> > >> jar
>> > >> > of felix in the distro,  but if the dependency 

Re: [VOTE] Release SDO 1.1.1

[ant elder]

That sounds right to me.

   ...ant

On Tue, Jun 3, 2008 at 11:57 AM, kelvin goodson <[EMAIL PROTECTED]>
wrote:

> Just a thought,  would I be right in guessing that if ever our
> SdoBundleActivator is touched in the runtime,  then the environment would
> be
> expected to provide the classes to satisfy
>
> import org.osgi.framework.BundleActivator;
> import org.osgi.framework.BundleContext;
>
> ?
>
> in which case I think declaring a "provided" scope for the felix dependency
> would be the right way to do things
>
> Kelvin.
>
> 2008/6/3 kelvin goodson <[EMAIL PROTECTED]>:
>
> > Thanks Ant,  that looks like progress,  but the felix framework jar is
> now
> > not in the list of distributed jars.
> >
> > Kelvin.
> >
> > 2008/6/3 ant elder <[EMAIL PROTECTED]>:
> >
> > Adding an exclude for felix to the distribution pom can fix that, eg
> here's
> >> local changes i have just tried:
> >>
> >> Index: src/main/assembly/bin.xml
> >> ===
> >> --- src/main/assembly/bin.xml   (revision 662488)
> >> +++ src/main/assembly/bin.xml   (working copy)
> >> @@ -120,13 +120,13 @@
> >> 
> >> 
> >>
> >> tuscany-sdo-${sdo.version}/lib
> >> -
> >> -
> >> org.apache.tuscany.sdo:tuscany-sdo-api-r2.1
> >> +
> >> 0644
> >> 
> >>
> >> Index: pom.xml
> >> ===
> >> --- pom.xml (revision 662488)
> >> +++ pom.xml (working copy)
> >> @@ -56,6 +56,12 @@
> >> org.apache.tuscany.sdo
> >> tuscany-sdo-impl
> >> ${pom.version}
> >> +
> >> +
> >> +org.apache.felix
> >> +org.apache.felix.main
> >> +
> >> +
> >> 
> >> 
> >> org.apache.tuscany.sdo
> >> @@ -67,6 +73,7 @@
> >> sample-sdo
> >> ${pom.version}
> >> 
> >> +
> >> 
> >>
> >> 
> >>
> >> Which results in a lib directory containing:
> >>
> >> backport-util-concurrent-3.0.jar
> >> codegen-2.2.3.jar
> >> codegen-ecore-2.2.3.jar
> >> common-2.2.3.jar
> >> ecore-2.2.3.jar
> >> ecore-change-2.2.3.jar
> >> ecore-xmi-2.2.3.jar
> >> sample-sdo-1.1.1-incubating-SNAPSHOT.jar
> >> stax-api-1.0.1.jar
> >> tuscany-sdo-api-r2.1-1.1.1-incubating-SNAPSHOT.jar
> >> tuscany-sdo-impl-1.1.1-incubating-SNAPSHOT.jar
> >> tuscany-sdo-lib-1.1.1-incubating-SNAPSHOT.jar
> >> tuscany-sdo-tools-1.1.1-incubating-SNAPSHOT.jar
> >> wstx-asl-3.2.1.jar
> >> xsd-2.2.3.jar
> >>
> >>...ant
> >>
> >> On Tue, Jun 3, 2008 at 11:31 AM, kelvin goodson <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >> > I had an offline chat with Rajini.  It seems we need just the
> framework
> >> jar
> >> > of felix in the distro,  but if the dependency on felix is declared as
> >> test
> >> > scope in the pom,  then that jar is not available to main phase of the
> >> > build.  If its not declared as test scope then we get 5 felix jars in
> >> the
> >> > binary distro.  Rajini's going to take a look when she gets some time.
> >> >
> >> > Kelvin.
> >> >
> >> >
> >> > 2008/6/3 kelvin goodson <[EMAIL PROTECTED]>:
> >> >
> >> >> The felix jars were introduced in the fix for  "SDO does not work
> with
> >> >> OSGi" [1] in commit 620763 [2].  I don't know if this is expected
> >> >> behaviour,  not being an OSGI expert.  Comments anyone?
> >> >>
> >> >> Kelvin.
> >> >>
> >> >> [1] https://issues.apache.org/jira/browse/TUSCANY-1293
> >> >> [2] http://svn.apache.org/viewcvs?view=rev&rev=620763
> >> >>
> >> >> 2008/6/3 kelvin goodson <[EMAIL PROTECTED]>:
> >> >>
> >> >> The required libraries are
> >> >>>
> >> >>> sample-sdo-%RELEASE%.jar
> >> >>> sdo-api-r2.1-%RELEASE%.jar
> >> >>> tuscany-s

Re: [VOTE] Release SDO 1.1.1

[ant elder]

Adding an exclude for felix to the distribution pom can fix that, eg here's
local changes i have just tried:

Index: src/main/assembly/bin.xml
===
--- src/main/assembly/bin.xml   (revision 662488)
+++ src/main/assembly/bin.xml   (working copy)
@@ -120,13 +120,13 @@
 
 

tuscany-sdo-${sdo.version}/lib
-
-
org.apache.tuscany.sdo:tuscany-sdo-api-r2.1
+
 0644
 

Index: pom.xml
===
--- pom.xml (revision 662488)
+++ pom.xml (working copy)
@@ -56,6 +56,12 @@
 org.apache.tuscany.sdo
 tuscany-sdo-impl
 ${pom.version}
+
+
+org.apache.felix
+org.apache.felix.main
+
+
 
 
 org.apache.tuscany.sdo
@@ -67,6 +73,7 @@
 sample-sdo
 ${pom.version}
 
+
 

 

Which results in a lib directory containing:

backport-util-concurrent-3.0.jar
codegen-2.2.3.jar
codegen-ecore-2.2.3.jar
common-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
sample-sdo-1.1.1-incubating-SNAPSHOT.jar
stax-api-1.0.1.jar
tuscany-sdo-api-r2.1-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-impl-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-lib-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-tools-1.1.1-incubating-SNAPSHOT.jar
wstx-asl-3.2.1.jar
xsd-2.2.3.jar

   ...ant

On Tue, Jun 3, 2008 at 11:31 AM, kelvin goodson <[EMAIL PROTECTED]>
wrote:

> I had an offline chat with Rajini.  It seems we need just the framework jar
> of felix in the distro,  but if the dependency on felix is declared as test
> scope in the pom,  then that jar is not available to main phase of the
> build.  If its not declared as test scope then we get 5 felix jars in the
> binary distro.  Rajini's going to take a look when she gets some time.
>
> Kelvin.
>
>
> 2008/6/3 kelvin goodson <[EMAIL PROTECTED]>:
>
>> The felix jars were introduced in the fix for  "SDO does not work with
>> OSGi" [1] in commit 620763 [2].  I don't know if this is expected
>> behaviour,  not being an OSGI expert.  Comments anyone?
>>
>> Kelvin.
>>
>> [1] https://issues.apache.org/jira/browse/TUSCANY-1293
>> [2] http://svn.apache.org/viewcvs?view=rev&rev=620763
>>
>> 2008/6/3 kelvin goodson <[EMAIL PROTECTED]>:
>>
>> The required libraries are
>>>
>>> sample-sdo-%RELEASE%.jar
>>> sdo-api-r2.1-%RELEASE%.jar
>>> tuscany-sdo-lib-%RELEASE%.jar
>>> tuscany-sdo-impl-%RELEASE%.jar
>>> tuscany-sdo-tools-%RELEASE%.jar
>>> codegen-ecore-2.2.3.jar
>>> codegen-2.2.3.jar
>>> ecore-2.2.3.jar
>>> ecore-change-2.2.3.jar
>>> ecore-xmi-2.2.3.jar
>>> common-2.2.3.jar
>>> xsd-2.2.3.jar
>>> stax-api-1.0.1.jar
>>> wstx-asl-3.2.0.jar
>>>
>>> with
>>> backport-util-concurrent being optional if you want threadsafe
>>> collections with Java 1.4 IIRC
>>>
>>> The felix jar inclusions were introduced some time between commit level
>>> 600913 and 627754;  I'm working on narrowing this down at the moment.
>>>
>>> Kelvin.
>>>
>>>
>>> 2008/6/2 ant elder <[EMAIL PROTECTED]>:
>>>
>>> It is strange.
>>>>
>>>> Removing the  at the bottom of the assembly bin.xml changes it
>>>> so
>>>> that the dependencies do get included again, but several felix
>>>> dependencies
>>>> also get dragged in. What is the complete list of jars that should be
>>>> included?
>>>>
>>>>   ...ant
>>>>
>>>> On Mon, Jun 2, 2008 at 6:02 PM, kelvin goodson <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>> > This failure also occurs with the 2.1 version and the 2.2-beta-1
>>>> version.
>>>> > The current trunk version is 2.2-beta-3-SNAPSHOT,  which I haven't
>>>> found in
>>>> > a repository yet,  so the only version that seems ever to have worked
>>>> is
>>>> > the
>>>> > 2.2-SNAPSHOT version. I have taken a look at the assembly plugin
>>>> JIRAs,
>>>> >  but
>>>> > it's hard to trawl that since so many JIRAs reference the word
>>>> dependency.
>>>> > It's not clear to me whether we benefited from a freak bug that was to
>>>> our
>>>> > advantage in the 2.2-SNAPSHOT version or whether all the other
>

Re: [Vote] Release Tuscany Java SCA 1.2.1 (RC1)

[ant elder]

Thanks for the vote. It seemed safer for this maintenance release to keep
"incubating" in the artifact names just to minimize changes. It probably is
as easy as the change to the release number but who know where problems may
hide. I thought we could use the up coming SDO 1.1.1 release as a test of
removing the suffix to see if the are any places that we need to be careful
with.

   ...ant

On Tue, Jun 3, 2008 at 8:10 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> My only minor comment is whether we are still going to use
> "incubating" on the release name/artifacts.
>
> Other then that, all looks ok, and here is my +1.
>
>
> On Sun, Jun 1, 2008 at 2:10 PM, ant elder <[EMAIL PROTECTED]> wrote:
> > Please review and vote on the release artifacts for the Tuscany SCA for
> Java
> > 1.2.1 maintenance release.
> >
> > The artifacts are available for review at:
> > http://people.apache.org/~antelder/tuscany/1.2.1-RC1/<http://people.apache.org/%7Eantelder/tuscany/1.2.1-RC1/>
> <http://people.apache.org/%7Eantelder/tuscany/1.2.1-RC1/>
> >
> > This includes the signed binary and source distributions, Maven staging
> > repository, and eclipse update site.
> >
> > The SVN tag for the release is:
> > http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2.1
> >
> > The _only_ code change in this over the 1.2 release is in r657526 [1],
> all
> > other changes are just version updates and doc changes for the release.
> >
> > +1 to release from me.
> >
> >   ...ant
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200805.mbox/[EMAIL
>  PROTECTED]
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>

Re: [VOTE] Release SDO 1.1.1

[ant elder]

It is strange.

Removing the  at the bottom of the assembly bin.xml changes it so
that the dependencies do get included again, but several felix dependencies
also get dragged in. What is the complete list of jars that should be
included?

   ...ant

On Mon, Jun 2, 2008 at 6:02 PM, kelvin goodson <[EMAIL PROTECTED]>
wrote:

> This failure also occurs with the 2.1 version and the 2.2-beta-1 version.
> The current trunk version is 2.2-beta-3-SNAPSHOT,  which I haven't found in
> a repository yet,  so the only version that seems ever to have worked is
> the
> 2.2-SNAPSHOT version. I have taken a look at the assembly plugin JIRAs,
>  but
> it's hard to trawl that since so many JIRAs reference the word dependency.
> It's not clear to me whether we benefited from a freak bug that was to our
> advantage in the 2.2-SNAPSHOT version or whether all the other versions
> have
> a bug/bugs.
>
> Kelvin.
>
> 2008/6/2 kelvin goodson <[EMAIL PROTECTED]>:
>
> > I have pinned down the change that caused the absence of EMF jars in the
> > distribution zip to be the switch from the maven assembly plugin version
> > 2.2-SNAPSHOT to the 2.2-beta-2 as altered here [1].I hope to look at
> > this again soon,  but have to stop for now.  If anyone has any views on
> what
> > version we should be using please pipe up.
> >
> > Kelvin.
> >
> > [1]
> >
> http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/pom.xml?r1=628691&r2=642349&pathrev=642349&diff_format=h
> >
> > Kelvin.
> >
> > 2008/5/19 kelvin goodson <[EMAIL PROTECTED]>:
> >
> > I'm looking at fixing a problem wrt running the samples at the moment.
> >>
> >> Also, I found that with a combination of using IBM JDK 1.5 and maven
> 2.0.7
> >> I got hit by http://jira.codehaus.org/browse/MJAVADOC-135 when trying
> to
> >> build from the top.  We say in our BUILDING doc that 2.0.7 is OK,
>  perhaps
> >> if we need to respin we should raise that in order to avoid IBM JDK
> users
> >> hitting this issue.  It's fine with 2.0.9
> >>
> >> Kelvin.
> >>
> >>
> >> 2008/5/18 ant elder <[EMAIL PROTECTED]>:
> >>
> >> Please review and vote on the SDO 1.1.1 release.
> >>>
> >>> The artifacts including binary and source distributions, staging maven
> >>> repo
> >>> and release notes are available at
> >>> http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC1/<http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/>
> <http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/>
> >>> <http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/>.
> >>> The only difference between this and the 1.1 release is the fix for
> >>> http://issues.apache.org/jira/browse/TUSCANY-2240.
> >>>
> >>> +1 from me.
> >>>
> >>>   ...ant
> >>>
> >>
> >>
> >
>

Re: JAXWSJavaInterfaceProcessorTestCase fail?

[ant elder]

Works for me now, thanks.

   ...ant

On Mon, Jun 2, 2008 at 6:56 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> Now it should be fixed under r662499. There was a typo in the code that led
> to JDK dependent behaviors (ordering in the Class.getMethods()).
>
> Thanks,
> Raymond
> ------
> From: "ant elder" <[EMAIL PROTECTED]>
> Sent: Monday, June 02, 2008 2:37 AM
> To: 
> Subject: Re: JAXWSJavaInterfaceProcessorTestCase fail?
>
>  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
>>
>>  ...ant
>>
>> On Mon, Jun 2, 2008 at 10:30 AM, Mike Edwards <
>> [EMAIL PROTECTED]> wrote:
>>
>>  ant elder wrote:
>>>
>>>  Looks like this is a jdk issue, works ok with IBM JDK5 but always fails
>>>> for
>>>> me with the Sun JDK.
>>>>
>>>>  ...ant
>>>>
>>>> On Mon, Jun 2, 2008 at 8:50 AM, Simon Laws <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>>
>>>>  On Mon, Jun 2, 2008 at 8:32 AM, ant elder <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>  On a fresh check out I'm getting a failure in
>>>>>
>>>>>> JAXWSJavaInterfaceProcessorTestCase, anyone else seeing that or is it
>>>>>> just
>>>>>> me?
>>>>>>
>>>>>>  ...ant
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> testProcessor(org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase)
>>>>>> Time elapsed: 0.046 s
>>>>>> ec  <<< FAILURE!
>>>>>> junit.framework.AssertionFailedError: null
>>>>>>  at junit.framework.Assert.fail(Assert.java:47)
>>>>>>  at junit.framework.Assert.assertTrue(Assert.java:20)
>>>>>>  at junit.framework.Assert.assertTrue(Assert.java:27)
>>>>>>  at
>>>>>>
>>>>>>
>>>>>>
>>>>>> org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase.testProcessor(JAXWSJavaInt
>>>>>> erfaceProcessorTestCase.java:80)
>>>>>>
>>>>>>  Failed for me also first time through with mvn -o. Just tried
>>>>>> building
>>>>>>
>>>>> that
>>>>> module independently with mvn clean and then mvn and it appears to
>>>>> work.So
>>>>> I'll try another build and see what happens.
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>   Ant,
>>>>
>>>
>>> Which level of the Sun JDK are you using?
>>>
>>> Is this a JAXB level issue?  Sun changed horses on JAXB during the 6.0
>>> releases
>>>
>>>
>>> Yours,  Mike.
>>>
>>>
>>

[NOTICE] Vamsavardhana Reddy voted as Tuscany committer

[ant elder]

The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany
committer.

Congratulations and welcome!

   ...ant

Re: what should happen if service and binding.ws require different soap version?

[ant elder]

I think right now our binding.ws services (or Axis2 services) will work with
either SOAP 1.1 or 1.2, and the response from the service will use the same
soap version as the request. Thats the default Axis2 behaviour, not sure if
its possible to change to restrict that. So right now the Tuscany code only
uses the soap intent for references. So those two marked as "Error" below
will actually just work with the current Tuscany code.

   ...ant

On Mon, Jun 2, 2008 at 5:01 PM, Gilbert Kwan <[EMAIL PROTECTED]> wrote:

> The following table shows all combinations:
>
> Service Require vs Reference Require:
> 
> None vs None:  OK
> None vs soap: OK
> None vs soap.1_1: OK
> None vs soap.1_2: OK
> soap vs None: OK
> soap vs soap: OK
> soap vs soap.1_1: OK
> soap vs soap.1_2: OK
> soap.1_1 vs None: OK
> soap.1_1 vs soap: OK
> soap.1_1 vs soap.1_1: OK
> soap.1_1 vs soap.1_2: Error
> soap.1_2 vs None: OK
> soap.1_2 vs soap: OK
> soap.1_2 vs soap.1_1: Error
> soap.1_2 vs soap.1_2: OK
>
> I guess there are only 2 scenarios should generate error. Right?
>
> Thanks
> Gilbert
>
>
>
>
> On Mon, Jun 2, 2008 at 6:17 AM, Mike Edwards
> <[EMAIL PROTECTED]> wrote:
> > Gilbert Kwan wrote:
> >>
> >> I defined a service requires soap.1_2
> >>
> >> 
> >>  
> >>
> >>  
> >>  
> >>
> >> 
> >>
> >> and a reference by ws binding which requires soap.1_1
> >>
> >> 
> >>  
> >>
> >>  
> >>   >> uri="http://localhost:8080/BComponentSOAP12"/>
> >>
> >> 
> >>
> >> I got no warning, error message, or exception. Is it fine?
> >> What is the proper behaviour of this scenario?
> >>
> >> Thanks
> >> Gilbert
> >>
> > Gilbert,
> >
> > That looks like an error to me.  Both sides need to be using the same
> SOAP
> > level.
> >
> > Looks like a failure of the policy matching between the two ends - I
> suggest
> > raising a JIRA for this one.
> >
> >
> > Yours, Mike.
> >
>

[jira] Commented: (TUSCANY-2357) CORBA objects invocation mechanism

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2357:


Thanks Wojtek, patch applied.

One comment, where possible the files in SVN should have the ASF license header 
you can see the format from existing files, eg its the following for Java files:

/*
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 * 
 *   http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 */


> CORBA objects invocation mechanism
> --
>
> Key: TUSCANY-2357
> URL: https://issues.apache.org/jira/browse/TUSCANY-2357
> Project: Tuscany
>  Issue Type: New Feature
>Reporter: Wojtek Janiszewski
> Attachments: corba-operation-invoker.patch.tar.gz
>
>
> Implementation of generic mechanism for remote operation invocation: passing 
> CORBA structures, sequences, primitives as arguments, retrieving return 
> values (also structs, seq, prims.). There is no exception handling yet. 
> It's not connected to CORBA binding extension yet - it won't be hard, and I 
> think it's now more important  to complete this generic mechanism.
> Some tests are provided - you need to have tnameserv in your PATH to run 
> tests correctly!

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

Re: SCA 1.2.1 release

[ant elder]

Yes! See - http://apache.markmail.org/message/bd7dw4ixeauvyznk.

   ...ant

On Mon, Jun 2, 2008 at 10:47 AM, Dave Sowerby <[EMAIL PROTECTED]>
wrote:

> Hey Ant,
>
> Thanks for offering to perform this task!
>
> Have you managed to make any progress with this?
>
> Cheers,
>
> Dave.
>
> On Thu, May 29, 2008 at 10:15 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > Yes, now that it looks like everyone wants this to go ahead I'll go do
> this,
> > not sure if I'll have time to finish it today and I'm out tomorrow but
> I'll
> > try to make sure the artifacts are built and available by the end of the
> > weekend.
> >
> >   ...ant
> >
> > On Thu, May 29, 2008 at 10:07 AM, Dave Sowerby <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi All,
> >>
> >> Could anyone give me any time scales for the 1.2.1 release?
> >>
> >> The release I'm preparing is due to be released within the next week
> >> and is unfortunately blocked awaiting this update.
> >>
> >> I'm available to assist in any way necessary.
> >>
> >> Cheers,
> >>
> >> Dave.
> >>
> >> On Wed, May 28, 2008 at 7:13 AM, haleh mahbod <[EMAIL PROTECTED]>
> wrote:
> >> > I can help with validating the samples and demos for 1.2.1.
> >> >
> >> > On 5/27/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> On Tue, May 27, 2008 at 6:26 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> > Dave Sowerby wrote:
> >> >> >
> >> >> >> Hi Simon,
> >> >> >>
> >> >> >> With regards to the 1.2.1 release you are correct that we have a
> >> >> >> patched version of tuscany-sca-all which would work, but this
> however
> >> >> >> leaves us in an awkward configuration position.
> >> >> >>
> >> >> >> We're currently preparing a software release based around Tuscany
> >> >> >> which is completely open to customers of our use of Tuscany, such
> >> that
> >> >> >> we document fully how to construct services independent of our
> >> >> >> software.  As such, we do not ship any Tuscany artifacts and
> instead
> >> >> >> encourage our customers to utilise the published maven repository.
> >> >> >> Whilst requiring a patch version of one of the jars is possible; I
> >> >> >> don't feel that this is a good representation of Tuscany - either
> >> >> >> documenting a variant version or expecting a non-standard version
> of
> >> >> >> 1.2-incubating.  These potential solutions are more likely to
> cause
> >> >> >> issues for customers that would undermine the image of Tuscany
> that
> >> we
> >> >> >> try to project.
> >> >> >>
> >> >> >> Is anyone adamantly opposed to this release?  Do you feel Tuscany
> >> >> >> 1.2.1 is still an option?  I'd hope that given the potential to
> >> damage
> >> >> >> our customer's perception of Tuscany would be enough to justify
> this
> >> >> >> minor release.
> >> >> >>
> >> >> >>  Thanks for the clarifaction and explanation.  It seems to me that
> >> >> > because we distribute Tuscany via Maven repos, which can't be
> patched,
> >> >> > this kind of situation will arise whenever a serious bug is found.
> >> >> > We can use patches to isolate a problem and confirm the fix, but we
> >> >> > generally won't be able to use them as an alternative to a release.
> >> >> >
> >> >> > In a situation like this, unless a new release is imminent, the
> best
> >> >> > solution seems to be to produce a quick "bug fix" release without
> >> >> > incurring the overhead of a full release and testing cycle.  Ant
> has
> >> >> > suggested that we could do this by applying a small set of
> carefully
> >> >> > controlled changes to the previous 1.2 release tag.  I think we
> need
> >> >> > to be very strict about what changes go in, to avoid another
> >> experience
> >> >> > like 1.0.1.  Specifically, I would suggest only including the fix
> >> >

Re: JAXWSJavaInterfaceProcessorTestCase fail?

[ant elder]

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)

   ...ant

On Mon, Jun 2, 2008 at 10:30 AM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> ant elder wrote:
>
>> Looks like this is a jdk issue, works ok with IBM JDK5 but always fails
>> for
>> me with the Sun JDK.
>>
>>   ...ant
>>
>> On Mon, Jun 2, 2008 at 8:50 AM, Simon Laws <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>> On Mon, Jun 2, 2008 at 8:32 AM, ant elder <[EMAIL PROTECTED]> wrote:
>>>
>>>  On a fresh check out I'm getting a failure in
>>>> JAXWSJavaInterfaceProcessorTestCase, anyone else seeing that or is it
>>>> just
>>>> me?
>>>>
>>>>  ...ant
>>>>
>>>>
>>>>
>>>> testProcessor(org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase)
>>>> Time elapsed: 0.046 s
>>>> ec  <<< FAILURE!
>>>> junit.framework.AssertionFailedError: null
>>>>   at junit.framework.Assert.fail(Assert.java:47)
>>>>   at junit.framework.Assert.assertTrue(Assert.java:20)
>>>>   at junit.framework.Assert.assertTrue(Assert.java:27)
>>>>   at
>>>>
>>>>
>>>> org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase.testProcessor(JAXWSJavaInt
>>>> erfaceProcessorTestCase.java:80)
>>>>
>>>>  Failed for me also first time through with mvn -o. Just tried building
>>> that
>>> module independently with mvn clean and then mvn and it appears to
>>> work.So
>>> I'll try another build and see what happens.
>>>
>>> Simon
>>>
>>>
>>  Ant,
>
> Which level of the Sun JDK are you using?
>
> Is this a JAXB level issue?  Sun changed horses on JAXB during the 6.0
> releases
>
>
> Yours,  Mike.
>

[jira] Commented: (TUSCANY-2291) Runtime does not detect illegal mix of local and remoteable on bidirectional interface

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2291:


Fixed in r662367 but the vtest is still commented out because as an exception 
is thrown when this problem is detected that breaks all the other tests in this 
vtest module. The vtest could be changed to work like 
vtest-java-api-annotations-destroy to use SCANode2Factory to start individual 
composites but  there's also work on going to use monitors and trapping 
exceptions so a validation error doesn't stop the domain startup so maybe thats 
the better fix

> Runtime does not detect illegal mix of local and remoteable on bidirectional 
> interface
> --
>
> Key: TUSCANY-2291
> URL: https://issues.apache.org/jira/browse/TUSCANY-2291
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Priority: Minor
> Fix For: Java-SCA-Next
>
>
>  From Lines 534, 535 of the Java API/Annotaitons spec:
> Callbacks may be used for both remotable and local services. Either both 
> interfaces of a bidirectional service must be remotable, or both must be 
> local. It is illegal to mix the two.
> The test 
> org.apache.tuscany.sca.vtest.javaapi.conversation.callback.statefulCallback3 
> demonstrates this error and is currently @Ignore(d)

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

Re: JAXWSJavaInterfaceProcessorTestCase fail?

[ant elder]

Looks like this is a jdk issue, works ok with IBM JDK5 but always fails for
me with the Sun JDK.

   ...ant

On Mon, Jun 2, 2008 at 8:50 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Mon, Jun 2, 2008 at 8:32 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
>> On a fresh check out I'm getting a failure in
>> JAXWSJavaInterfaceProcessorTestCase, anyone else seeing that or is it just
>> me?
>>
>>   ...ant
>>
>>
>> testProcessor(org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase)
>> Time elapsed: 0.046 s
>> ec  <<< FAILURE!
>> junit.framework.AssertionFailedError: null
>>at junit.framework.Assert.fail(Assert.java:47)
>>at junit.framework.Assert.assertTrue(Assert.java:20)
>>at junit.framework.Assert.assertTrue(Assert.java:27)
>>at
>>
>> org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase.testProcessor(JAXWSJavaInt
>> erfaceProcessorTestCase.java:80)
>>
>
> Failed for me also first time through with mvn -o. Just tried building that
> module independently with mvn clean and then mvn and it appears to work.So
> I'll try another build and see what happens.
>
> Simon
>

JAXWSJavaInterfaceProcessorTestCase fail?

[ant elder]

On a fresh check out I'm getting a failure in
JAXWSJavaInterfaceProcessorTestCase, anyone else seeing that or is it just
me?

   ...ant

testProcessor(org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase)
Time elapsed: 0.046 s
ec  <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase.testProcessor(JAXWSJavaInt
erfaceProcessorTestCase.java:80)

[jira] Created: (TUSCANY-2359) Rationalize the SCA runtime use of cglib and asm dependencies

[ant elder (JIRA)]

Rationalize the SCA runtime use of cglib and asm dependencies
-

 Key: TUSCANY-2359
 URL: https://issues.apache.org/jira/browse/TUSCANY-2359
 Project: Tuscany
  Issue Type: Improvement
Affects Versions: Java-SCA-Next
Reporter: ant elder
 Fix For: Java-SCA-Next


The Tuscany runtime now has dependencies on both asm-all and cglib-nodep, these 
both do the same type of thing, and the "-nodep" version of cglib includes asm, 
so it would be nice to rationalize the use of these to just one dependency.

Asm is used by interface-java-jaxws, cglib-nodep is used by 
CglibProxyFactory.java in the core module.  

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