Re: [SCA Native] Test suite is stale and hasn't been maintained for ages

[Pete Robbins]

I've deleted this. It has been proposed several times to remove this
and I've never seen any objections.

It's gone!

Cheers,

On 13/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I wrote a JIRA about this:
>https://issues.apache.org/jira/browse/TUSCANY-1533
>
> Why don't we just delete it to avoid people wasting time wondering why
> it doesn't even compile for them (like I did).
> We'll be making a new one for the M4 release anyways.
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>


-- 
Pete

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

Re: [SCA Native] java implementation and interface schema files loaded but not used

[Pete Robbins]

On 13/08/07, David Haney <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
> > Sent: Friday, August 10, 2007 8:33 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] java implementation and interface schema
> files
> > loaded but not used
> >
> > Brady Johnson wrote:
> > > Does anyone have any insight into why these files are loaded but
> never
> > > used in TuscanySCA Native:
> > >
> > >  /xsd/
> > > sca-implementation-java.xsd
> > > sca-interface-java.xsd
> > >
> > > I created a JIRA for this:
> > > https://issues.apache.org/jira/browse/TUSCANY-1513
> > >
> > > Their existence in the project is misleading and implies that
> TuscanySCA
> > > Native supports Java services.
> > > Perhaps these should be removed in M4.
> > >
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > > 
> > >
> > >
> > >
> > >
> >
> > Will you be able to load (and ignore without breaking) a composite
> > containing implementation.java and interface.java elements? I'm
> thinking
> > about scenarios where people share a composite between the two
> runtimes,
> > with part of it running on the Native runtime and part running on the
> > Java runtime.
> >
> > I guess I'll have the same question for the Java project, we should be
> > able to ignore (or just handle with a warning) implementation.cpp and
> > interface.cpp in the Java runtime.
> >
> > --
> > Jean-Sebastien
> >
>
> Won't this still be a problem for other extensions that are provided by
> Tuscany Java?  For example, implementation.script?  Does this imply that
> we should copy all of the extension xsd files from Tuscany Java into
> Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)?
>
> Is it possible we could have the composite loader ignore (or warn about)
> extension types that it doesn't recognize?  This would allow it to parse
> the composite files, but wouldn't require that our runtime explicitly
> recognize every extension type that isn't supported.

I think this is the way to go.

>
> -- David Haney
> -- Chief Architect, Hydra Products
> -- Rogue Wave Software
> -- http://www.roguewave.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Pete

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

Re: [SCA Native] java implementation and interface schema files loaded but not used

[Pete Robbins]

On 14/08/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The SCA Java runtime doesn't use the XSD for the assembly or extensions at
> runtime to parse the composite file. A StAX-based artifact processor is
> plugged into the runtime to handle the extensions such as
> implementation.java, implementation.script and binidng.rmi.
>
> Does SCA Native use the generated SDO from the XSDs to load the composite
> file?
>

No. SDO C++ does not have a generated SDO feature yet. We load the
schema to define types then load the XML to create dynamic SDOs. It
was simple. convenient and initially we were using it to test out the
SDO code.

> Thanks,
> Raymond
>
> - Original Message -
> From: "David Haney" <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, August 13, 2007 2:35 PM
> Subject: RE: [SCA Native] java implementation and interface schema files
> loaded but not used
>
>
>
>
> > -Original Message-
> > From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
> > Sent: Friday, August 10, 2007 8:33 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] java implementation and interface schema
> files
> > loaded but not used
> >
> > Brady Johnson wrote:
> > > Does anyone have any insight into why these files are loaded but
> never
> > > used in TuscanySCA Native:
> > >
> > >  /xsd/
> > > sca-implementation-java.xsd
> > > sca-interface-java.xsd
> > >
> > > I created a JIRA for this:
> > > https://issues.apache.org/jira/browse/TUSCANY-1513
> > >
> > > Their existence in the project is misleading and implies that
> TuscanySCA
> > > Native supports Java services.
> > > Perhaps these should be removed in M4.
> > >
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > > 
> > >
> > >
> > >
> > >
> >
> > Will you be able to load (and ignore without breaking) a composite
> > containing implementation.java and interface.java elements? I'm
> thinking
> > about scenarios where people share a composite between the two
> runtimes,
> > with part of it running on the Native runtime and part running on the
> > Java runtime.
> >
> > I guess I'll have the same question for the Java project, we should be
> > able to ignore (or just handle with a warning) implementation.cpp and
> > interface.cpp in the Java runtime.
> >
> > --
> > Jean-Sebastien
> >
>
> Won't this still be a problem for other extensions that are provided by
> Tuscany Java?  For example, implementation.script?  Does this imply that
> we should copy all of the extension xsd files from Tuscany Java into
> Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)?
>
> Is it possible we could have the composite loader ignore (or warn about)
> extension types that it doesn't recognize?  This would allow it to parse
> the composite files, but wouldn't require that our runtime explicitly
> recognize every extension type that isn't supported.
>
> -- David Haney
> -- Chief Architect, Hydra Products
> -- Rogue Wave Software
> -- http://www.roguewave.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Pete

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

Updating SCA Distributions

[Luciano Resende]

Is there any documentation on how to update the SCA Distributions ?
Maybe a quick readme on java/sca/distribution describing how to add
dependencies... should new dependencies always go in both bundle and
manifest ? what about webapp ?

BTW, I have added sdo-tools dependencies under revision #565631, it
would be great if someone could review it and let me know if I didn't
forget any other place.

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

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

Re: [DAS] Transaction support

[Luciano Resende]

Comments inline

On 8/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> Below is what is happening today:-
> managedtx(default-true) - config attribute in  element to
> control transactions
>
> managedtx   database conn. supplied effect on transaction
> --
> 1)true  from caller each DAS command undergoes
> commit/rollback
> 2)false from within DAS this is not handled in any way
> 3)true  from within DAS each DAS command undergoes
> commit/rollback
> 4)false from caller DAS does not issue
> commit/rollback, external caller manages
>
> So what is lacking is
> a> ability to issue commit/rollback on group of commands where connection is
> managed by DAS  (managedtx=true).(case 3)). this will be essential to handle
> any business unit work. otherwise DAS is ending up today in mimicking
> autocommit behavior of Database which is not so useful when business
> transactions need to handle a group of operations as one atomic unit

So, the test case below is an example of multiple commands under one
transaction. On this scenario, connection is supplied by client, and I
think this gives you the same results as if the connection was created
by DAS and exposed to client code, and also gives more flexibility to
how the client will aquire the connection, or re-use some other
connection to be part of the same transaction.

[1] 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/TransactionTests.java


> b> what is the reason behind providing case 1)? when client/container
> provides connection, it can be controlled by client/container. and even if
> DAS tries to controll it, as user has handle to connection,
> commits/rollbacks can be issued by client "async" with what DAS is trying to
> control. So there will be no meaning in DAS controlling the connection
> supplied by client. And so there is no meaning to managedtx either.
>
> c> case 2), as of today there is no way to expose connection to client when
> it is created by DAS. so neither DAS nor client manages transaction. For
> this case exposing connection thru getConnection() will be useful (for other
> cases, it can be banned)
>

In the case where client code requires access to the connection, is
there any issue with supplying it to DAS ?


> d> as DAS is "heterogeneous" API, is the DAS config going to be
> heterogeneous too? If yes, then it will be advantageousto support the
> transactional nature of RDB using such semantics. If the backend (non RDB)
> does not support transaction, this semantics will be of no use, but
> in this case the DAS config can be different (more tuned to that particular
> backend)
> So, it all depends on whether we are following the path to support DAS with
> heterogeneous APIs or not. Will you please elaborate meaning of
> "heterogeneous API" in context of different flavors of DAS?
>

Yes, the idea is that each impl would define it's own model,
inheriting from a common root class (xsd element)

> e> {If you already defined the transaction demarcation flags...}Where are we
> doing that at present? What is there is only issue commit/rollback at the
> end of each DAS Command. Am I missing some other transaction demarcation
> mechanism already available in DAS?
>
> Regards,
> Amita
>
> On 8/13/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >
> > I think that the main goal of DAS, is to be an heterogeneous API that
> > could be used to implement support for various backends (rdb, ldap,
> > xml etc). Starting to add various semantics that might be specific to
> > RDB might take us out of this direction.
> >
> > So, for this issue, let's take a step back and think around the
> > scenarios where this new enhancement might be useful, could you please
> > list a couple here ? It would be great if you could also mention the
> > deficiencies you found from managedtx parameter on each scenario.
> >
> > Also, couple questions :
> >- Could you please elaborate more on why you need to expose
> > DAS.getConnection() ?
> >
> >- If you already defined the transaction demarcation flags, why you
> > still ask the client code to handle start/endTransaction? Why is that
> > different from passing managedtx = false ?
> >
> > On 8/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > > -When connection is provider by caller(say container), there is no
> > > meaning
> > > of managedtx attribute, and it is better to let the caller handle the
> > > transactionality of the operations. So, when DAS is instantiated using
> > > external connection - mandate managedtx = false. Also, expose
> > > getConnection() from DAS to give a ref. of the connection (User already
> > owns
> > > it, DAS is just providing ref.). DAS will not issue any commit/rollback
> > >
> > > -When connection is created internally, mana

Re: [DAS] Transaction support

[Amita Vadhavkar]

Below is what is happening today:-
managedtx(default-true) - config attribute in  element to
control transactions

managedtx   database conn. supplied effect on transaction
--
1)true  from caller each DAS command undergoes
commit/rollback
2)false from within DAS this is not handled in any way
3)true  from within DAS each DAS command undergoes
commit/rollback
4)false from caller DAS does not issue
commit/rollback, external caller manages

So what is lacking is
a> ability to issue commit/rollback on group of commands where connection is
managed by DAS  (managedtx=true).(case 3)). this will be essential to handle
any business unit work. otherwise DAS is ending up today in mimicking
autocommit behavior of Database which is not so useful when business
transactions need to handle a group of operations as one atomic unit

b> what is the reason behind providing case 1)? when client/container
provides connection, it can be controlled by client/container. and even if
DAS tries to controll it, as user has handle to connection,
commits/rollbacks can be issued by client "async" with what DAS is trying to
control. So there will be no meaning in DAS controlling the connection
supplied by client. And so there is no meaning to managedtx either.

c> case 2), as of today there is no way to expose connection to client when
it is created by DAS. so neither DAS nor client manages transaction. For
this case exposing connection thru getConnection() will be useful (for other
cases, it can be banned)

d> as DAS is "heterogeneous" API, is the DAS config going to be
heterogeneous too? If yes, then it will be advantageousto support the
transactional nature of RDB using such semantics. If the backend (non RDB)
does not support transaction, this semantics will be of no use, but
in this case the DAS config can be different (more tuned to that particular
backend)
So, it all depends on whether we are following the path to support DAS with
heterogeneous APIs or not. Will you please elaborate meaning of
"heterogeneous API" in context of different flavors of DAS?

e> {If you already defined the transaction demarcation flags...}Where are we
doing that at present? What is there is only issue commit/rollback at the
end of each DAS Command. Am I missing some other transaction demarcation
mechanism already available in DAS?

Regards,
Amita

On 8/13/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> I think that the main goal of DAS, is to be an heterogeneous API that
> could be used to implement support for various backends (rdb, ldap,
> xml etc). Starting to add various semantics that might be specific to
> RDB might take us out of this direction.
>
> So, for this issue, let's take a step back and think around the
> scenarios where this new enhancement might be useful, could you please
> list a couple here ? It would be great if you could also mention the
> deficiencies you found from managedtx parameter on each scenario.
>
> Also, couple questions :
>- Could you please elaborate more on why you need to expose
> DAS.getConnection() ?
>
>- If you already defined the transaction demarcation flags, why you
> still ask the client code to handle start/endTransaction? Why is that
> different from passing managedtx = false ?
>
> On 8/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > -When connection is provider by caller(say container), there is no
> > meaning
> > of managedtx attribute, and it is better to let the caller handle the
> > transactionality of the operations. So, when DAS is instantiated using
> > external connection - mandate managedtx = false. Also, expose
> > getConnection() from DAS to give a ref. of the connection (User already
> owns
> > it, DAS is just providing ref.). DAS will not issue any commit/rollback
> >
> > -When connection is created internally, managedtx has a meaning.
> > 1>When false, DAS.getConnection() should be exposed and user should be
> > allowed to handle transactions. DAS should not issue any
> commits/rollbacks
> >
> > 2>When true, do not expose DAS.getConnection().
> >
> > If TRANSACTION_DEMARCATION_PER_COMMAND is true, work like today (commit
> > /rollback per command).
> >
> > If TRANSACTION_DEMARCATION_PER_COMMAND is false (now is time for DAS to
> > manager group of commands as a sigle transaction).Here, DAS at the
> simplest
> > can use a static FLAG  set/unset using methods
> > - void DAS.startTransaction(), //mark FLAG to set
> > - void DAS.endTransaction("commit/rollback"). //mark FLAG to reset
> > endTransaction() will issue commit/rollback based on arg passed to it.
> > For any exception condition DAS will issue rollback() on transaction and
> > will reset the FLAG.
> > Client needs to call start/endTransaction() for group of Commands.
> >
> > Also, here for timeout impelmentation, Java Timer c

Re: Policy intents and policySets on bindings and implementations

[Jean-Sebastien Delfino]

[snip]
Venkata Krishnan wrote:

Hi Sebastien,

Yes, this was what I intended to do initially.  But got a bit
concerned about losing the original state of the model after build
time.  I was thinking of a Admin or Mgmt function that might display
the original configurations before thing got built i.e. computed or
aggregated.  For this I thought its best to have information that was
originially loaded preserved.

The 'ComputedIntents' and 'ComputedPolicies' will only emerge during
the build time.  I could not figure out a better place to hold this
information than the model itself.

Well, that's just for explaining the thoughts behind that
implementation.  I am open to cutting this out :).

Independent of this change, could you please help me get some clarity
on how we could retrieve the original configurations.  Thanks.

- Venkat
  


If you want to implement an administration tool that shows the original 
composites, components, services, references, implementations, 
bindings... and policies then just don't call CompositeBuilder.build()  :)


Administration tools, wizards, and editors should use the original 
models loaded from the development artifacts. CompositeBuilder.build() 
refactors and transforms the original assembly model so much (to make it 
easier to process at runtime) than preserving only the original policies 
wouldn't help anyway.


--
Jean-Sebastien


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

Re: [SCA Native] java implementation and interface schema files loaded but not used

[Jean-Sebastien Delfino]

David Haney wrote:
  

-Original Message-
From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
Sent: Friday, August 10, 2007 8:33 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] java implementation and interface schema


files
  

loaded but not used

Brady Johnson wrote:


Does anyone have any insight into why these files are loaded but
  

never
  

used in TuscanySCA Native:

 /xsd/
sca-implementation-java.xsd
sca-interface-java.xsd

I created a JIRA for this:
https://issues.apache.org/jira/browse/TUSCANY-1513

Their existence in the project is misleading and implies that
  

TuscanySCA
  

Native supports Java services.
Perhaps these should be removed in M4.



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





  

Will you be able to load (and ignore without breaking) a composite
containing implementation.java and interface.java elements? I'm


thinking
  

about scenarios where people share a composite between the two


runtimes,
  

with part of it running on the Native runtime and part running on the
Java runtime.

I guess I'll have the same question for the Java project, we should be
able to ignore (or just handle with a warning) implementation.cpp and
interface.cpp in the Java runtime.

--
Jean-Sebastien




Won't this still be a problem for other extensions that are provided by
Tuscany Java?  For example, implementation.script?  Does this imply that
we should copy all of the extension xsd files from Tuscany Java into
Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)? 
  


I'm not implying anything  or advocating for any solution. It's just 
that the discussion about the schemas made me think about scenarios 
mixing implementation and binding types and I'm just asking if there 
will be an issue at all with these scenarios.



Is it possible we could have the composite loader ignore (or warn about)
extension types that it doesn't recognize?  This would allow it to parse
the composite files, but wouldn't require that our runtime explicitly
recognize every extension type that isn't supported.
  


That would be a good idea.


-- David Haney
-- Chief Architect, Hydra Products
-- Rogue Wave Software
-- http://www.roguewave.com/

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


  



--
Jean-Sebastien


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

Re: [SCA Native] java implementation and interface schema files loaded but not used

[Raymond Feng]

Hi,

The SCA Java runtime doesn't use the XSD for the assembly or extensions at 
runtime to parse the composite file. A StAX-based artifact processor is 
plugged into the runtime to handle the extensions such as 
implementation.java, implementation.script and binidng.rmi.


Does SCA Native use the generated SDO from the XSDs to load the composite 
file?


Thanks,
Raymond

- Original Message - 
From: "David Haney" <[EMAIL PROTECTED]>

To: 
Sent: Monday, August 13, 2007 2:35 PM
Subject: RE: [SCA Native] java implementation and interface schema files 
loaded but not used






-Original Message-
From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
Sent: Friday, August 10, 2007 8:33 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] java implementation and interface schema

files

loaded but not used

Brady Johnson wrote:
> Does anyone have any insight into why these files are loaded but

never

> used in TuscanySCA Native:
>
>  /xsd/
> sca-implementation-java.xsd
> sca-interface-java.xsd
>
> I created a JIRA for this:
> https://issues.apache.org/jira/browse/TUSCANY-1513
>
> Their existence in the project is misleading and implies that

TuscanySCA

> Native supports Java services.
> Perhaps these should be removed in M4.
>
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
> 
>
>
>
>

Will you be able to load (and ignore without breaking) a composite
containing implementation.java and interface.java elements? I'm

thinking

about scenarios where people share a composite between the two

runtimes,

with part of it running on the Native runtime and part running on the
Java runtime.

I guess I'll have the same question for the Java project, we should be
able to ignore (or just handle with a warning) implementation.cpp and
interface.cpp in the Java runtime.

--
Jean-Sebastien



Won't this still be a problem for other extensions that are provided by
Tuscany Java?  For example, implementation.script?  Does this imply that
we should copy all of the extension xsd files from Tuscany Java into
Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)?

Is it possible we could have the composite loader ignore (or warn about)
extension types that it doesn't recognize?  This would allow it to parse
the composite files, but wouldn't require that our runtime explicitly
recognize every extension type that isn't supported.

-- David Haney
-- Chief Architect, Hydra Products
-- Rogue Wave Software
-- http://www.roguewave.com/

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


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

Re: sample news page....

[haleh mahbod]

Thanks Brady.

As I mentioned below I am hoping that everyone who has something to share
about the project will participate and share information. Thanks for making
the effort to update Native SCA section on News page.  One piece of news
might be interesting is OSCON demo that goes across Java and Native if it is
ready.

Haleh

On 8/13/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
>
> Looks nice!
>
> I meant to reply last week saying that I thought it was a good idea, but
> time just got away from me again...
>
> The Native part looks a bit sparse. Imp trying to think of something to
> beef it up a bit. :)
>
> Brady
>
> -Original Message-
> From: haleh mahbod [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 13, 2007 3:33 PM
> To: tuscany-dev; Tuscany Users
> Subject: sample news page
>
> Hi,
>
> Here is a sample of  SCA news page that I had proposed last week[1].
> This news page includes information about both Java SCA and Native SCA.
> It is a live page that reflects what's going on in the project (no old
> news).
>
> This page is  created on TuscanyWiki  so that everyone can add
> information to it. It currently has two main sections. Project news and
> user news.
> Please feel free to add more if  you can think of other news categories
> to add.
>
> Please help keep this page interesting!  Share what you think is useful.
> If your news script consists of long text, please provide a link to a
> page to keep this page easy to read.
>
> I'll go ahead and link it to the website for now at [2].
> Let's give this a few weeks to see how it evolves. Do you think we
> should have one Tuscany news page or separate ones for SCA, SDO and DAS?
>
> [1]:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+News+
> Page
> [2]:
> http://incubator.apache.org/tuscany/tuscany-downloads-documentations.htm
> l
>
> Haleh
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[jira] Commented: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros

[Luciano Resende (JIRA)]

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

Luciano Resende commented on TUSCANY-1524:
--

This was also fixed in trunk under revision #565487

> Need to fix file permission with DAS beta1 release distros
> --
>
> Key: TUSCANY-1524
> URL: https://issues.apache.org/jira/browse/TUSCANY-1524
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Luciano Resende
>Assignee: Luciano Resende
> Fix For: Java-DAS-beta1
>
>
> See details here :
> http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html
> and
> http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html

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


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

[jira] Resolved: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros

[Luciano Resende (JIRA)]

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

Luciano Resende resolved TUSCANY-1524.
--

Resolution: Fixed

Fixed under revision #565488

> Need to fix file permission with DAS beta1 release distros
> --
>
> Key: TUSCANY-1524
> URL: https://issues.apache.org/jira/browse/TUSCANY-1524
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Luciano Resende
>Assignee: Luciano Resende
> Fix For: Java-DAS-beta1
>
>
> See details here :
> http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html
> and
> http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html

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


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

[VOTE] Release Tuscany Java DAS beta1 (RC4)

[Luciano Resende]

Please vote to release the beta1 distribution of Tuscany DAS for Java.

All the major issues reported in previous RC should now be fixed, and
the only change from RC3 is a fix to file permission issues on the
distribution as described in TUSCANY-1524.

The Release Candidate RC4 for Tuscany Java DAS beta1 is available at

http://people.apache.org/~lresende/tuscany/das-beta1-rc4/

Release Notes are available at

https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/distribution/binary/RELEASE_NOTES

The maven repository artifacts are posted in a staging repository and
is available at

http://people.apache.org/~lresende/tuscany/das-beta1-rc4/maven/

The release audit tool (rat) results are available at

http://people.apache.org/~lresende/tuscany/das-beta1-rc4/das-beta1-rat.log

The tag for the source code is at

https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/

Seems OK to me, here is my +1

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

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

[SCA Native] Test suite is stale and hasn't been maintained for ages

[Brady Johnson]

 
I wrote a JIRA about this:
https://issues.apache.org/jira/browse/TUSCANY-1533
 
Why don't we just delete it to avoid people wasting time wondering why
it doesn't even compile for them (like I did).
We'll be making a new one for the M4 release anyways.
 

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

[jira] Created: (TUSCANY-1533) TuscanySCA Native test suite is stale and hasnt been maintained for ages

[Brady Johnson (JIRA)]

TuscanySCA Native test suite is stale and hasnt been maintained for ages


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


The TuscanySCA Native test suite is stale and hasn't been maintained for ages. 

It could be very confusing for anyone who downloads the source code and tries to
run the tests since they don't even compile. 
(like I once did and then spent a few hours searching/wondering what I did 
wrong)

Why don't we just delete it? We'll be creating a new one with the M4 release.


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



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


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

[jira] Updated: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros

[Luciano Resende (JIRA)]

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

Luciano Resende updated TUSCANY-1524:
-

Description: 
See details here :
http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html
and
http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html

  was:
See details here :
http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html


> Need to fix file permission with DAS beta1 release distros
> --
>
> Key: TUSCANY-1524
> URL: https://issues.apache.org/jira/browse/TUSCANY-1524
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Luciano Resende
>Assignee: Luciano Resende
> Fix For: Java-DAS-beta1
>
>
> See details here :
> http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html
> and
> http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html

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


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

RE: sample news page....

[Brady Johnson]

Looks nice! 

I meant to reply last week saying that I thought it was a good idea, but
time just got away from me again...

The Native part looks a bit sparse. Imp trying to think of something to
beef it up a bit. :)

Brady 

-Original Message-
From: haleh mahbod [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 13, 2007 3:33 PM
To: tuscany-dev; Tuscany Users
Subject: sample news page

Hi,

Here is a sample of  SCA news page that I had proposed last week[1].
This news page includes information about both Java SCA and Native SCA.
It is a live page that reflects what's going on in the project (no old
news).

This page is  created on TuscanyWiki  so that everyone can add
information to it. It currently has two main sections. Project news and
user news.
Please feel free to add more if  you can think of other news categories
to add.

Please help keep this page interesting!  Share what you think is useful.
If your news script consists of long text, please provide a link to a
page to keep this page easy to read.

I'll go ahead and link it to the website for now at [2].
Let's give this a few weeks to see how it evolves. Do you think we
should have one Tuscany news page or separate ones for SCA, SDO and DAS?

[1]:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+News+
Page
[2]:
http://incubator.apache.org/tuscany/tuscany-downloads-documentations.htm
l

Haleh

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

RE: [SCA Native] java implementation and interface schema files loaded but not used

[David Haney]

> -Original Message-
> From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 10, 2007 8:33 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] java implementation and interface schema
files
> loaded but not used
> 
> Brady Johnson wrote:
> > Does anyone have any insight into why these files are loaded but
never
> > used in TuscanySCA Native:
> >
> >  /xsd/
> > sca-implementation-java.xsd
> > sca-interface-java.xsd
> >
> > I created a JIRA for this:
> > https://issues.apache.org/jira/browse/TUSCANY-1513
> >
> > Their existence in the project is misleading and implies that
TuscanySCA
> > Native supports Java services.
> > Perhaps these should be removed in M4.
> >
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> > 
> >
> >
> >
> >
> 
> Will you be able to load (and ignore without breaking) a composite
> containing implementation.java and interface.java elements? I'm
thinking
> about scenarios where people share a composite between the two
runtimes,
> with part of it running on the Native runtime and part running on the
> Java runtime.
> 
> I guess I'll have the same question for the Java project, we should be
> able to ignore (or just handle with a warning) implementation.cpp and
> interface.cpp in the Java runtime.
> 
> --
> Jean-Sebastien
> 

Won't this still be a problem for other extensions that are provided by
Tuscany Java?  For example, implementation.script?  Does this imply that
we should copy all of the extension xsd files from Tuscany Java into
Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)? 

Is it possible we could have the composite loader ignore (or warn about)
extension types that it doesn't recognize?  This would allow it to parse
the composite files, but wouldn't require that our runtime explicitly
recognize every extension type that isn't supported.

-- David Haney
-- Chief Architect, Hydra Products
-- Rogue Wave Software
-- http://www.roguewave.com/

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

sample news page....

[haleh mahbod]

Hi,

Here is a sample of  SCA news page that I had proposed last week[1]. This
news page includes information about both Java SCA and Native SCA.  It is a
live page that reflects what's going on in the project (no old news).

This page is  created on TuscanyWiki  so that everyone can add information
to it. It currently has two main sections. Project news and user news.
Please feel free to add more if  you can think of other news categories to
add.

Please help keep this page interesting!  Share what you think is useful. If
your news script consists of long text, please provide a link to a page to
keep this page easy to read.

I'll go ahead and link it to the website for now at [2].
Let's give this a few weeks to see how it evolves. Do you think we should
have one Tuscany news page or
separate ones for SCA, SDO and DAS?

[1]:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+News+Page
[2]:
http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html

Haleh

Re: I think Tuscany needs a graph generator for composite layouts

[Mike Edwards]

Shaoguang,

The Eclipse SOA Tools Project is building a graphical editor for SCA 
composites.  You can find the project here:


http://www.eclipse.org/stp/

In addition to the graphical composition editor, there is a range of SCA 
and SOA related tooling available in this tools project.


Of course, there are also commercial tools produced by some vendors, of 
which the IBM WebSphere Integration Developer (WID) tool is an example:


http://www-306.ibm.com/software/integration/wid/

...the commercial tools are big on graphical editors, but as you might 
expect for such productive tools, they come at a significant price!


Yours,  Mike.

shaoguang geng wrote:

as the title, when composite contents comes more and more complicated, a layout 
graph generator would do greate help to developers.

Or did some one see commercial providers of such a grapher?

Good day.

   
-
Building a website is a piece of cake. 
Yahoo! Small Business gives you all the tools to get online.


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

Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files

[Simon Laws]

On 8/6/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>
>
> On 8/6/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> > Simon Laws wrote:
> > > On 8/3/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > >
> > >> ant elder wrote:
> > >>
> > >>> On 8/1/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> > >>>
> > >>>
> >  Jean-Sebastien Delfino wrote:
> > 
> > 
> > > Jean-Sebastien Delfino wrote:
> > >
> > >
> > >> [snip]
> > >>
> > >>
> > >>
> >  Another problem is all our bindings work differently. So
> >  , <
> > 
> > 
> > > binding.rmi/> < binding.jms/>  etc all
> > result in
> > >
> > >> a
> > >>
> > > service
> > > being available at a different endpoint. Also the uri
> > attribute
> > >
> > >
> >  on those
> > 
> > 
> > > bindings all work differently so uri="foo" for some bindings
> > >
> > >
> >  would be
> > 
> > 
> > > treated as relative uri, for others an absolute one. What we
> > need
> > >
> > >
> >  is a
> > 
> > 
> > > bit
> > > of code that implements section 1.7.2.1 of the assembly spec
> > >
> > >
> >  which all
> > 
> > 
> > > bindings then use. (a generic version of
> > > Axis2ServiceProvider.computeActualURI ). Didn't this come up
> > once
> > >
> > >
> >  before
> > 
> > 
> > > and
> > > something was changing in the runtime binding for this?
> > >
> > >
> > >> I think that these URIs should be determined as part of the
> > process
> > >> of combining wires and uris specified at different levels in the
> > SCA
> > >> assembly. If the correct URIs are determined once as part of this
> >
> > >> process, a binding provider should be able to just call
> > >> binding.getURI(), without having to calculate it at all, on its
> > own
> > >> or even calling a central URI calculator method.
> > >>
> > >>
> > >>
> > > Before trying to implement a common algorithm for all bindings, I
> > > thought I'd double check the various SCA spec docs. Here's what I
> > >
> > >> found:
> > >>
> > > - WebService binding
> > > absolute URI specified in binding/@uri
> > > or
> > > base domain URI for http: + '/' + component URI + '/' + relative
> > URI
> > > specified in binding/@uri
> > > or
> > > absolute URI specified in WSDL
> > > or
> > > base domain URI for http: + '/' + component URI + '/' + relative
> > URI
> > > specified in WSDL
> > > or
> > > absolute URI specified in a wsa:Address
> > > or
> > > base domain URI for http: + '/' + component URI + '/' + relative
> > URI
> > > specified in a wsa:Address
> > >
> > > - JMS binding
> > > JMS specific URI specified in binding/@uri
> > > or
> > > no URI, combination of JMS specific attributes
> > >
> > > - EJB binding
> > > base domain URI for corba:iiop: + '#' + relative URI specified in
> > > binding/@uri
> > > or
> > > base domain URI for corba:rir: + '#' + relative URI specified in
> > > binding/@uri
> > > or
> > > absolute URI specified in binding/@uri
> > >
> > > I think that other bindings introduced by Tuscany can follow
> > similar
> > > patterns:
> > >
> > > - RMI binding
> > > similar to EJB binding
> > >
> > > - JSON, Ajax and Feed bindings
> > > absolute URI specified in binding/@uri
> > > or
> > > base domain URI for http: + '/' + component URI + '/' + relative
> > URI
> > > specified in binding/@uri
> > >
> > > Thoughts? could you guys please review to make sure I understood
> > the
> > > specs correctly? Thanks.
> > >
> > >
> > >
> >  After more reading of the various SCA specs, I think we should
> > defer
> >  supporting a domain URI (or a set of domain URIs) until the specs
> >  clarify the use cases for it. Here are the issues I'm seeing:
> > 
> >  - Component URI is not clearly defined in the spec (there's an
> > errata
> >  for this), the name of the component cannot be used alone for
> > nested
> >  components, and concatenating names of nested components with a
> > domain
> >  URI is likely to cause ambiguities and collisions.
> > 
> >  - Having a domain URI per node in a domain (proposed earlier in
> > this
> >  thread) is not in line with the spec.
> > 
> >  - Also doing that will burn the node topology in the SCA domain
> > logical
> >  assembly, as you'll see the addresses of your nodes in the URIs on
> > your
> >  reference bindings, so the logical assembly won't be so "logical"
> > 
> > >> anymore
> > >>
> >  :)
> > 
> >  - We coul

Re: SCA distribution is really big now

[haleh mahbod]

It would be good to get user 's view on this as well.  I am re-posting to
tuscany-user list since I am not sure if  everyone monitors both lists.

On 8/11/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> Our SCA binary distribution is over 100Meg now and there's still
> extensions
> and dependencies I've not added yet. This seems a little big considering
> we're trying to sell Tuscany as all svelte and light weight.
>
> So what to do? The reason its so big is that every webapp sample and demo
> we
> have ends up including a copy of most of the runtime and dependencies. One
> solution could be to just ship fewer prebuilt webapp samples and demos.
> Another could be to change the way we do those samples so that each
> sample/demo is just a simple SCA contribution jar and you have to deploy
> that to some Tuscany runtime. We've already the webapp runtime that would
> work for that, and the Geronimo Tuscany support, and we could  create
> another standalone runtime if you don't want to use Tomcat or Geronimo.
>
> What do people think, does the size matter, are there some other things we
> could do?
>
>...ant
>

[SCA Native] Next Release Design

[Brady Johnson]

 
Hello all,
 
I have written some preliminary design specifications for the TuscanySCA
M4 release.  This is a living document, and I will be continuously
updating it.
 
Before I get any further, I would like some opinions on the refactor of
the "SCA Data Model". Input/Suggestions are very welcome. 
 
Here's the WIKI page:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+Nativ
e+Release+M4+Design+Specifications
 
(the mail program may cut the link into several lines, so make sure you
copy all the way to +Specifications)
 
Thanks
 

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

Re: mvn eclipse:eclipse fails on java

[Simon Laws]

On 8/13/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:
>
> Hi Luciano, Simon,
>
> I ran it like this:
>
> mvn -U -fn clean install
>
> And it runs fine (Some test errors, but build completes) with maven 2.0.5and 
> java
> 1.5.12.
>
> Thanks for all the feedback,
> - Ole
>
>
>
> Simon Laws wrote:
> > On 8/13/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >> Hi Ole
> >>
> >>Here is what I tried, and all went OK
> >>
> >> 1.Removed .m2\repository\org\apache\tuscany
> >> 2.svn update to revision #565235
> >> 3.cd %tuscany_home%\java
> >> 4.mvn -U -fn clean install
> >>
> >> java version "1.5.0_12"
> >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
> >> Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
> >>
> >> Maven version: 2.0.5  --> If you have a higher version, I'd recommend
> >> trying with 2.0.5
> >>
> >>
> >> [INFO]
> >>
> 
> >> [INFO]
> >>
> 
> >> [INFO] BUILD SUCCESSFUL
> >> [INFO]
> >>
> 
> >> [INFO] Total time: 48 minutes 3 seconds
> >> [INFO] Finished at: Sun Aug 12 22:28:52 PDT 2007
> >> [INFO] Final Memory: 61M/63M
> >> [INFO]
> >>
> 
> >>
> >>
> >> On 8/12/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:
> >>> Hi Simon,
> >>>
> >>> Simon Laws wrote:
> >>>
>  I note from your other post that you are having problems with the
> full
> >> build
>  with JDK1.6. Is it possible for you to try with 1.5 as this is known
> >> to
>  work? We can then isolate JDK issues from these more general build
> >> issues.
> >>> Oh Man - It almost made it - I gave 1.5.12 a go for the whole build
> and
> >> it made it this far (I also disabled SELinux to make sure nothing funky
> was
> >> happening):
> >>> ---
> >>>  T E S T S
> >>> ---
> >>> Running supplychain.SupplyChainClientTestCase
> >>> In SupplyChainClientTestCase.test: Calling customer.purchaseGoods,
> >> customer is [Proxy - f6438d]
> >>> java.lang.ClassNotFoundException: supplychain.retailer.Retailer
> >>> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java
> >> :1422)
> >>> at org.apache.felix.framework.BundleImpl.loadClass(
> >> BundleImpl.java:335)
> >>> at
> >>
> org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveWireRegisterProxyService
> >> (OSGiImplementationProvider.java:773)
> >>> at
> >>
> org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveBundle
> >> (OSGiImplementationProvider.java:873)
> >>> at
> >>
> org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle
> >> (OSGiImplementationProvider.java:326)
> >>> at
> >>
> org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance
> >> (OSGiInstanceWrapper.java:70)
> >>> at
> >>
> org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget
> >> (OSGiTargetInvoker.java:121)
> >>> at
> >>
> org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke
> >> (OSGiTargetInvoker.java:172)
> >>> at
> >> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke
> (
> >> RuntimeSCABindingInvoker.java:41)
> >>> at
> >> org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke
> (
> >> AbstractInvocationHandler.java:145)
> >>> at
> >> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(
> >> JDKInvocationHandler.java:75)
> >>> at $Proxy7.purchaseGoods(Unknown Source)
> >>> at supplychain.SupplyChainClientTestCase.test(
> >> SupplyChainClientTestCase.java:52)
> >>> 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 junit.framework.TestCase.runTest(TestCase.java:168)
> >>> at junit.framework.TestCase.runBare(TestCase.java:134)
> >>> at junit.framework.TestResult$1.protect(TestResult.java:110)
> >>> at junit.framework.TestResult.runProtected(TestResult.java
> :128)
> >>> at junit.framework.TestResult.run(TestResult.java:113)
> >>> at junit.framework.TestCase.run(TestCase.java:124)
> >>> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> >>> at junit.framework.TestSuite.run(TestSuite.java:227)
> >>> at org.junit.internal.runners.OldTestClassRunner.run(
> >> OldTestClassRunner.ja

Re: [Fwd: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible]

[Caroline Maynard]

Brady Johnson wrote:


That's good to know the background to that include file, I didn't know
about it. I'll definitely keep it in mind. I don't think the change I
made should affect you, let me know if it does.


Thanks. As discussed previously, we're sticking with the branch for now, 
and will move up to the trunk when it is more stable - it's clear there 
will be a >lot< of changes to make, though the majority should be fairly 
mindless refactoring. Just wanted to make sure that you knew how some of 
the Tuscany code ended up like it is.




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

Re: mvn eclipse:eclipse fails on java

[Ole Ersoy]

Hi Luciano, Simon,

I ran it like this:

mvn -U -fn clean install

And it runs fine (Some test errors, but build completes) with maven 2.0.5 and 
java 1.5.12.

Thanks for all the feedback,
- Ole



Simon Laws wrote:

On 8/13/07, Luciano Resende <[EMAIL PROTECTED]> wrote:

Hi Ole

   Here is what I tried, and all went OK

1.Removed .m2\repository\org\apache\tuscany
2.svn update to revision #565235
3.cd %tuscany_home%\java
4.mvn -U -fn clean install

java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)

Maven version: 2.0.5  --> If you have a higher version, I'd recommend
trying with 2.0.5


[INFO]

[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]

[INFO] Total time: 48 minutes 3 seconds
[INFO] Finished at: Sun Aug 12 22:28:52 PDT 2007
[INFO] Final Memory: 61M/63M
[INFO]



On 8/12/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:

Hi Simon,

Simon Laws wrote:


I note from your other post that you are having problems with the full

build

with JDK1.6. Is it possible for you to try with 1.5 as this is known

to

work? We can then isolate JDK issues from these more general build

issues.

Oh Man - It almost made it - I gave 1.5.12 a go for the whole build and

it made it this far (I also disabled SELinux to make sure nothing funky was
happening):

---
 T E S T S
---
Running supplychain.SupplyChainClientTestCase
In SupplyChainClientTestCase.test: Calling customer.purchaseGoods,

customer is [Proxy - f6438d]

java.lang.ClassNotFoundException: supplychain.retailer.Retailer
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java

:1422)

at org.apache.felix.framework.BundleImpl.loadClass(

BundleImpl.java:335)

at

org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveWireRegisterProxyService
(OSGiImplementationProvider.java:773)

at

org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveBundle
(OSGiImplementationProvider.java:873)

at

org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle
(OSGiImplementationProvider.java:326)

at

org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance
(OSGiInstanceWrapper.java:70)

at

org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget
(OSGiTargetInvoker.java:121)

at

org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke
(OSGiTargetInvoker.java:172)

at

org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke(
RuntimeSCABindingInvoker.java:41)

at

org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(
AbstractInvocationHandler.java:145)

at

org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:75)

at $Proxy7.purchaseGoods(Unknown Source)
at supplychain.SupplyChainClientTestCase.test(

SupplyChainClientTestCase.java:52)

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 junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.OldTestClassRunner.run(

OldTestClassRunner.java:35)

at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(

JUnit4TestSet.java:62)

at

org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(
AbstractDirectoryTestSuite.java:138)

at

org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(
AbstractDirectoryTestSuite.java:125)

at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(

NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMetho

Re: SDOFactory: NoClassDefFoundError.

[Frank Budinsky]

Hi,

>From the stack trace below, this doesn't really sound like an EMF/SDO 
version problem. It looks like it's trying to load a Tuscany class:

org/apache/tuscany/sdo/SDOFactory

This should be in the tuscany impl project JAR. Since it's not finding it, 
it sounds like the classpath is missing some JAR(s).

Frank

Fuhwei Lwo <[EMAIL PROTECTED]> wrote on 08/13/2007 12:34:05 PM:

> 
> Hi Ramesh,
> 
> My best guess is you have EMF version conflict between WPS and SDO 2.1.
>  The EMF in WPS is much older than the one in Tuscany SDO. Since EMF is
>  a runtime library in WPS, you cannot upgrade it on your own. The only
>  way to make your env work is to refactor EMF in Tuscany SDO to avoid
>  EMF conflict.
> 
> This is probably something Tuscany SDO should do - to refactor EMF so
>  it can hide EMF as implementation details. I am not sure whether
>  refactoring EMF is allowed under Eclipse license. Any investigation is
>  welcome.
> 
> Fuhwei
> 
> 
> [EMAIL PROTECTED] wrote: 
> Hi All,
> 
> 
> 
> I am trying to read out an XML file by using your library files
> (tuscany-sdo-api-r2.1-1.0-incubating.jar). I placed your library in my
> Websphere process server lib folder as well I set all the tuscany jar's
> in my class path. Still, I am experiencing  the below error. 
> 
> 
> 
> YOUR SUGGESTIONS WILL BE VERY MUCH APPRECIATED.
> 
> 
> 
> 
> 
> [8/13/07 13:30:19:616 IST] 005a ExceptionUtil E   CNTR0020E: EJB
> threw an unexpected (non-declared) exception during invocation of method
> "transactionNotSupportedActivitySessionSupports" on bean
> "BeanId(XMLValidationApp#XMLValidationEJB.jar#Module, null)". Exception
> data: java.lang.NoClassDefFoundError: org/apache/tuscany/sdo/SDOFactory
> 
>   at
> org.apache.tuscany.sdo.impl.FactoryBase.(FactoryBase.java:225)
> 
>   at
> org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> 
>   at
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelper
> Impl.java:63)
> 
>   at
> org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:
> 81)
> 
>   at
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl
> .java:64)
> 
>   at
> org.apache.tuscany.sdo.helper.DefaultHelperContextImpl.(DefaultHel
> perContextImpl.java:31)
> 
>   at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(He
> lperProviderImpl.java:37)
> 
>   at
> org.apache.tuscany.sdo.spi.HelperProviderBase.(HelperProviderBase.
> java:81)
> 
>   at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderIm
> pl.java:30)
> 
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> 
>   at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA
> ccessorImpl.java(Compiled Code))
> 
>   at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
> tructorAccessorImpl.java(Compiled Code))
> 
>   at
> java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled
> Code))
> 
>   at java.lang.Class.newInstance3(Class.java(Compiled Code))
> 
>   at java.lang.Class.newInstance(Class.java(Compiled Code))
> 
>   at
> commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:1
> 57)
> 
>   at
> commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126)
> 
>   at
> commonj.sdo.impl.HelperProvider.(HelperProvider.java:69)
> 
>   at commonj.sdo.helper.XMLHelper.(XMLHelper.java:200)
> 
>   at
> sca.component.java.impl.XMLValidateImpl.doValidation(XMLValidateImpl.jav
> a:59)
> 
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a(Compiled Code))
> 
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a(Compiled Code))
> 
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java(Compiled Code))
> 
>   at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
> 
>   at
> com.ibm.ws.sca.internal.java.handler.JavaReflectionAdapter.invoke(JavaRe
> flectionAdapter.java:138)
> 
>   at
> com.ibm.ws.sca.internal.java.handler.JavaImplementationHandler.processMe
> ssage(JavaImplementationHandler.java:258)
> 
>   at
> com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag
> e(MessageDispatcherImpl.java:386)
> 
>   at
> com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM
> essageImpl.java:476)
> 
>   at
> com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessage(Mo
> duleSessionBean.java:335)
> 
>   at
> com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.transactionNotSuppor
> tedActivitySessionSupports(ModuleSessionBean.java:276)
> 
>   at
> com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.transactio
> nNotSupportedActivitySessionSupports(EJSLocalStatelessModule_43132892.ja
> va:199)
> 
>   at
> com.ibm.ws.s

Re: SDOFactory: NoClassDefFoundError.

[Fuhwei Lwo]

Hi Ramesh,

My best guess is you have EMF version conflict between WPS and SDO 2.1.
 The EMF in WPS is much older than the one in Tuscany SDO. Since EMF is
 a runtime library in WPS, you cannot upgrade it on your own. The only
 way to make your env work is to refactor EMF in Tuscany SDO to avoid
 EMF conflict.

This is probably something Tuscany SDO should do - to refactor EMF so
 it can hide EMF as implementation details. I am not sure whether
 refactoring EMF is allowed under Eclipse license. Any investigation is
 welcome.

Fuhwei


[EMAIL PROTECTED] wrote: 
Hi All,

 

I am trying to read out an XML file by using your library files
(tuscany-sdo-api-r2.1-1.0-incubating.jar). I placed your library in my
Websphere process server lib folder as well I set all the tuscany jar's
in my class path. Still, I am experiencing  the below error. 

 

YOUR SUGGESTIONS WILL BE VERY MUCH APPRECIATED.

 

 

[8/13/07 13:30:19:616 IST] 005a ExceptionUtil E   CNTR0020E: EJB
threw an unexpected (non-declared) exception during invocation of method
"transactionNotSupportedActivitySessionSupports" on bean
"BeanId(XMLValidationApp#XMLValidationEJB.jar#Module, null)". Exception
data: java.lang.NoClassDefFoundError: org/apache/tuscany/sdo/SDOFactory

  at
org.apache.tuscany.sdo.impl.FactoryBase.(FactoryBase.java:225)

  at
org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)

  at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelper
Impl.java:63)

  at
org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:
81)

  at
org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl
.java:64)

  at
org.apache.tuscany.sdo.helper.DefaultHelperContextImpl.(DefaultHel
perContextImpl.java:31)

  at
org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(He
lperProviderImpl.java:37)

  at
org.apache.tuscany.sdo.spi.HelperProviderBase.(HelperProviderBase.
java:81)

  at
org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderIm
pl.java:30)

  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)

  at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA
ccessorImpl.java(Compiled Code))

  at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
tructorAccessorImpl.java(Compiled Code))

  at
java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled
Code))

  at java.lang.Class.newInstance3(Class.java(Compiled Code))

  at java.lang.Class.newInstance(Class.java(Compiled Code))

  at
commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:1
57)

  at
commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126)

  at
commonj.sdo.impl.HelperProvider.(HelperProvider.java:69)

  at commonj.sdo.helper.XMLHelper.(XMLHelper.java:200)

  at
sca.component.java.impl.XMLValidateImpl.doValidation(XMLValidateImpl.jav
a:59)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a(Compiled Code))

  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a(Compiled Code))

  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java(Compiled Code))

  at java.lang.reflect.Method.invoke(Method.java(Compiled Code))

  at
com.ibm.ws.sca.internal.java.handler.JavaReflectionAdapter.invoke(JavaRe
flectionAdapter.java:138)

  at
com.ibm.ws.sca.internal.java.handler.JavaImplementationHandler.processMe
ssage(JavaImplementationHandler.java:258)

  at
com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag
e(MessageDispatcherImpl.java:386)

  at
com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM
essageImpl.java:476)

  at
com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessage(Mo
duleSessionBean.java:335)

  at
com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.transactionNotSuppor
tedActivitySessionSupports(ModuleSessionBean.java:276)

  at
com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.transactio
nNotSupportedActivitySessionSupports(EJSLocalStatelessModule_43132892.ja
va:199)

  at
com.ibm.ws.sca.internal.uow.handler.UOWStrategyImpl.transactionLocalActi
vitySessionAny(UOWStrategyImpl.java:406)

  at
com.ibm.ws.sca.internal.uow.handler.UOWAttribute.invoke(UOWAttribute.jav
a:478)

  at
com.ibm.ws.sca.internal.uow.handler.AbstractUOWHandler.processMessage(Ab
stractUOWHandler.java:162)

  at
com.ibm.ws.sca.internal.uow.handler.UOWHandler.processMessage(UOWHandler
.java:81)

  at
com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag
e(MessageDispatcherImpl.java:397)

  at
com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM
essageImpl.java:476)

  at
com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessa

Re: Calling XSD2JavaGenerator from ANT

[Luciano Resende]

I was expecting the non-recommended approach to work...but the SDO
generator code explicitly interpret and expects the key/value as two
separate command line args.

>The non-recommended approach to emulate the two-argument behavior is
>

If this is the expected behavior, we should at least have it documented.

Thoughts ?

On 8/12/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
> Hi,
>   The observed behaviour is the documented behavior of Ant
> 
> 
>
> means there are two separate command-line arguments i.e. args.length=2
>
> Is different from
> 
> Which means there is one command-line argument of value "key1 value1".
>
> The non-recommended approach to emulate the two-argument behaviour is
> 
>
>
>
>
>
> Pinaki Poddar
> 972.834.2865
>
> -Original Message-
> From: Luciano Resende [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 13, 2007 1:51 AM
> To: tuscany-dev
> Subject: Calling XSD2JavaGenerator from ANT
>
> I was playing with XSD2JavaGenerator to generate static sdo objects for
> some SCA samples,  and realized it has some strange behavior with
> regards to command line argument processing.
>
> Basically, it treat the a command line option and it's value as two
> separate arguments, so, instead of being able to pass an argument like
> , you actually MUST
> pass the arguments like two separate arguments  value="-targetDirectory"/>  .
>
> Is this the expected behavior ?
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> Notice:  This email message, together with any attachments, may contain 
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
> entities,  that may be confidential,  proprietary,  copyrighted  and/or 
> legally privileged, and is intended solely for the use of the individual or 
> entity named in this message. If you are not the intended recipient, and have 
> received this message in error, please immediately return this by email and 
> then delete it.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

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

Re: Metadata related to extension types

[Venkata Krishnan]

Hi Simon,

You mentioned whatever was running in my mind - a module for sca-domain.  I
did look at the host-embeded for a fit but wasn't comfortable.  I'd imagine
the sca-domain to be a module on its own - having its model, processors and
other things and various runtimes should strap up this domain.  Though the
definitions.xml has mostly about policy related things I'd expect it to
accomodate more things that go just beyond policy and pertain braodly to the
domain.  Infact I'd guess somewhere down the line with the distributed
domain scaling up, this file 'could' have a role to play.

Thanks.

- Venkat

On 8/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 8/13/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > The Assembly Model specs mentions the 'need' for definitions of metadata
> > related to implementation and binding extensions types as follows:
> >
> >
> > "2665 In addition to the definition for the new implementation instance
> > element, there needs to be an
> > 2666 associated implementationType element which provides metadata about
> > the
> > new implementation
> > 2667 type. The pseudo schema for the implementationType element is shown
> > in
> > the following snippet:
> > 2668   > 2669
> alwaysProvides="list
> > of
> > intent xs:QName"
> > 2670 mayProvide="list of
> > intent xs:QName"/>"
> >
> > 2749  > 2750 alwaysProvides="list of intent
> > QNames"?
> > 2751 mayProvide = "list of intent
> > QNames"?/>
> >
> > This metadata is supposed to be defined in definitions.xml file as
> defined
> > on page 57, section title "SCA Definitions".
> >
> > Since I am having to address the definitions.xml file as part of the
> > policy
> > framework implementation, I have included model and processors for
> > implementationType and bindingType elements within the policy and
> > policy-xml
> > modules.  But I guess this has to move out to a place that typically
> deals
> > with 'domain' related things in general.  Could people share some
> thoughts
> > on this please ?
> >
> > Thanks
> >
> > - Venkat
> >
> Hi Venkat
>
> These all seem to be policy related apart from  which, if I
> understand it correctly, allows binding definitions to be pre defined for
> a
> domain.
>
> I think we have three places that do domain kinds of things.
>   host-embedded
>   distributed (am just about to check in a new version along with a
> distributed-impl)
>   topology (this might go depending on the answer to the base uri
> question)
>
> None of these look like particularly likely candidates. How about we have
> a
> "domain" module for this domain level information?
>
> Simon
>

Re: [DAS] Transaction support

[Luciano Resende]

I think that the main goal of DAS, is to be an heterogeneous API that
could be used to implement support for various backends (rdb, ldap,
xml etc). Starting to add various semantics that might be specific to
RDB might take us out of this direction.

So, for this issue, let's take a step back and think around the
scenarios where this new enhancement might be useful, could you please
list a couple here ? It would be great if you could also mention the
deficiencies you found from managedtx parameter on each scenario.

Also, couple questions :
   - Could you please elaborate more on why you need to expose
DAS.getConnection() ?

   - If you already defined the transaction demarcation flags, why you
still ask the client code to handle start/endTransaction? Why is that
different from passing managedtx = false ?

On 8/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> -When connection is provider by caller(say container), there is no
> meaning
> of managedtx attribute, and it is better to let the caller handle the
> transactionality of the operations. So, when DAS is instantiated using
> external connection - mandate managedtx = false. Also, expose
> getConnection() from DAS to give a ref. of the connection (User already owns
> it, DAS is just providing ref.). DAS will not issue any commit/rollback
>
> -When connection is created internally, managedtx has a meaning.
> 1>When false, DAS.getConnection() should be exposed and user should be
> allowed to handle transactions. DAS should not issue any commits/rollbacks
>
> 2>When true, do not expose DAS.getConnection().
>
> If TRANSACTION_DEMARCATION_PER_COMMAND is true, work like today (commit
> /rollback per command).
>
> If TRANSACTION_DEMARCATION_PER_COMMAND is false (now is time for DAS to
> manager group of commands as a sigle transaction).Here, DAS at the simplest
> can use a static FLAG  set/unset using methods
> - void DAS.startTransaction(), //mark FLAG to set
> - void DAS.endTransaction("commit/rollback"). //mark FLAG to reset
> endTransaction() will issue commit/rollback based on arg passed to it.
> For any exception condition DAS will issue rollback() on transaction and
> will reset the FLAG.
> Client needs to call start/endTransaction() for group of Commands.
>
> Also, here for timeout impelmentation, Java Timer can be used.
>
> Regards,
> Amita
>
> On 8/10/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> >
> > Hi Amita,
> >
> > I think it can be useful to bunch commands, but I didn't get how you are
> > planning to do it : (
> >
> > What would be the parameter of method getTransaction?
> >
> > Regards,
> > Adriano Crestani
> >
> > On 7/12/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > >
> > > Below is a simple matrix based on current RDB DAS Config, showing what
> > it
> > > does/does not
> > > do today
> > >
> > > managedtx(default-true) - config attribute in  element
> > to
> > > control transactions
> > >
> > > managedtx   database conn. supplied effect on transaction
> > >
> > >
> > --
> > > 1)true   from caller each DAS
> > command
> > > undergoes commit/rollback
> > > 2)false  from within DAS this is not handled
> > > in
> > > any way
> > > 3)true   from within DAS each DAS command
> > > undergoes commit/rollback
> > > 4)false from caller DAS does not issue
> > > commit/rollback, external caller manages
> > >
> > > Case 2) - when database Connection is created in RDB DAS, it does not
> > > expose
> > > it to caller
> > > today. So,   in case 2) neither RDB DAS nor caller can manage
> > > transactions.
> > >
> > > From above, it seems that, RDB DAS in general does not provide support
> > to
> > > handle a group
> > > of Commands under one database transactions. Only case 4) is the place
> > > when
> > > multiple
> > > DAS Commands can undergo as one transaction.
> > >
> > > To help serve the transaction control better, I would like to propose
> > the
> > > following requirements:-
> > > [1]RDB DAS should have a way to issue commit/rollback for single/group
> > of
> > > Commands
> > > [2]When there is exception, the ongoing transaction should be
> > immediately
> > > aborted by RDB
> > >DAS irrespective of whether it was for single/group of Commands
> > > [3]Optional Timeout feature - to have an escape route to end the
> > > transaction controlled by
> > > RDB DAS,  when it seems to linger for time > Timeout (to take care of
> > > situations like
> > > deadlocks).
> > >
> > >For this, I am thinking of introducing 2 new attributes in RDB DAS
> > > Config
> > >A) TRANSACTION_DEMARCATION_PER_COMMAND - true/false (mandatory when
> > > managedtx=true)
> > >B) TRANSACTION_TIMEOUT - millis (always optional)
> > >These 2 attributes can be specified at  level.
> > >
> > > When case 1) or 3) - bo

RE: [Fwd: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible]

[Brady Johnson]

Caroline,

That's good to know the background to that include file, I didn't know
about it. I'll definitely keep it in mind. I don't think the change I
made should affect you, let me know if it does.

Thanks


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


-Original Message-
From: Caroline Maynard [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 13, 2007 6:29 AM
To: [EMAIL PROTECTED]
Subject: [Fwd: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for
windows is not msvc backwards compatible]





 Original Message 
Subject: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for 
windows is   not msvc backwards compatible
Date: Mon, 13 Aug 2007 10:57:44 +0100
From: Caroline Maynard <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Newsgroups: gmane.comp.apache.webservices.tuscany.devel
References: <[EMAIL PROTECTED]>

Brady Johnson (JIRA) wrote:
> Tuscany SDO native for windows is not msvc backwards compatible
> 

Don't I know it. In the PHP project the automated build servers for Win
use VC6, so we are obliged to use that compiler in the SDO for PHP
project. Since the Tuscany team decided to support only VC8, I usually
find some minor problems porting the code over - you'll find a trail of
these in the issues database where I've sent the fixes back as patches.
It's not really a big problem, more an inconvenience. However it was a
policy decision by the Tuscany committers at the time. YMMV.

Again, with the localtime behaviour, this came from concerns about using
non-reentrant versions of localtime(). You may not have noticed the
SDOUserMacros.h file - this mechanism was introduced so that consumers
of Tuscany C++ could adapt the macros to their environment. You can see
the PHP version here:

http://cvs.php.net/viewvc.cgi/pecl/sdo/commonj/sdo/SDOUserMacros.h?view=
markup

It would be helpful if you would keep this mechanism in place.


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


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

Re: Metadata related to extension types

[Simon Laws]

On 8/13/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> The Assembly Model specs mentions the 'need' for definitions of metadata
> related to implementation and binding extensions types as follows:
>
>
> "2665 In addition to the definition for the new implementation instance
> element, there needs to be an
> 2666 associated implementationType element which provides metadata about
> the
> new implementation
> 2667 type. The pseudo schema for the implementationType element is shown
> in
> the following snippet:
> 2668   2669 alwaysProvides="list
> of
> intent xs:QName"
> 2670 mayProvide="list of
> intent xs:QName"/>"
>
> 2749  2750 alwaysProvides="list of intent
> QNames"?
> 2751 mayProvide = "list of intent
> QNames"?/>
>
> This metadata is supposed to be defined in definitions.xml file as defined
> on page 57, section title "SCA Definitions".
>
> Since I am having to address the definitions.xml file as part of the
> policy
> framework implementation, I have included model and processors for
> implementationType and bindingType elements within the policy and
> policy-xml
> modules.  But I guess this has to move out to a place that typically deals
> with 'domain' related things in general.  Could people share some thoughts
> on this please ?
>
> Thanks
>
> - Venkat
>
Hi Venkat

These all seem to be policy related apart from  which, if I
understand it correctly, allows binding definitions to be pre defined for a
domain.

I think we have three places that do domain kinds of things.
  host-embedded
  distributed (am just about to check in a new version along with a
distributed-impl)
  topology (this might go depending on the answer to the base uri question)

None of these look like particularly likely candidates. How about we have a
"domain" module for this domain level information?

Simon

[Fwd: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible]

[Caroline Maynard]

 Original Message 
Subject: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for 
windows is   not msvc backwards compatible

Date: Mon, 13 Aug 2007 10:57:44 +0100
From: Caroline Maynard <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Newsgroups: gmane.comp.apache.webservices.tuscany.devel
References: <[EMAIL PROTECTED]>

Brady Johnson (JIRA) wrote:
Tuscany SDO native for windows is not msvc backwards compatible 



Don't I know it. In the PHP project the automated build servers for Win
use VC6, so we are obliged to use that compiler in the SDO for PHP
project. Since the Tuscany team decided to support only VC8, I usually
find some minor problems porting the code over - you'll find a trail of
these in the issues database where I've sent the fixes back as patches.
It's not really a big problem, more an inconvenience. However it was a
policy decision by the Tuscany committers at the time. YMMV.

Again, with the localtime behaviour, this came from concerns about using
non-reentrant versions of localtime(). You may not have noticed the
SDOUserMacros.h file - this mechanism was introduced so that consumers
of Tuscany C++ could adapt the macros to their environment. You can see
the PHP version here:

http://cvs.php.net/viewvc.cgi/pecl/sdo/commonj/sdo/SDOUserMacros.h?view=markup

It would be helpful if you would keep this mechanism in place.


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

Metadata related to extension types

[Venkata Krishnan]

Hi,

The Assembly Model specs mentions the 'need' for definitions of metadata
related to implementation and binding extensions types as follows:


"2665 In addition to the definition for the new implementation instance
element, there needs to be an
2666 associated implementationType element which provides metadata about the
new implementation
2667 type. The pseudo schema for the implementationType element is shown in
the following snippet:
2668  "

2749 

This metadata is supposed to be defined in definitions.xml file as defined
on page 57, section title "SCA Definitions".

Since I am having to address the definitions.xml file as part of the policy
framework implementation, I have included model and processors for
implementationType and bindingType elements within the policy and policy-xml
modules.  But I guess this has to move out to a place that typically deals
with 'domain' related things in general.  Could people share some thoughts
on this please ?

Thanks

- Venkat

Re: Release management for next release, was: SCA 0.92 release?

[ant elder]

On 8/13/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> Simon Laws wrote:
> > +1 for 21st as the target. Can I suggest we take some time (assuming
> there
> > is some)  on the 20th to test the samples and check through the readmes
> etc
> > before taking the branch.
>
> We could probably get a "stable distribution" available on the 20th,
> and we would check that.


That sounds like a good plan, i'll continue with some tidy up this week
aiming to get distribution out for the 20th.

   ...ant

SDOFactory: NoClassDefFoundError.

[Ramesh.KS]

Hi All,

 

I am trying to read out an XML file by using your library files
(tuscany-sdo-api-r2.1-1.0-incubating.jar). I placed your library in my
Websphere process server lib folder as well I set all the tuscany jar's
in my class path. Still, I am experiencing  the below error. 

 

YOUR SUGGESTIONS WILL BE VERY MUCH APPRECIATED.

 

 

[8/13/07 13:30:19:616 IST] 005a ExceptionUtil E   CNTR0020E: EJB
threw an unexpected (non-declared) exception during invocation of method
"transactionNotSupportedActivitySessionSupports" on bean
"BeanId(XMLValidationApp#XMLValidationEJB.jar#Module, null)". Exception
data: java.lang.NoClassDefFoundError: org/apache/tuscany/sdo/SDOFactory

  at
org.apache.tuscany.sdo.impl.FactoryBase.(FactoryBase.java:225)

  at
org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)

  at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelper
Impl.java:63)

  at
org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:
81)

  at
org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl
.java:64)

  at
org.apache.tuscany.sdo.helper.DefaultHelperContextImpl.(DefaultHel
perContextImpl.java:31)

  at
org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(He
lperProviderImpl.java:37)

  at
org.apache.tuscany.sdo.spi.HelperProviderBase.(HelperProviderBase.
java:81)

  at
org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderIm
pl.java:30)

  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)

  at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA
ccessorImpl.java(Compiled Code))

  at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
tructorAccessorImpl.java(Compiled Code))

  at
java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled
Code))

  at java.lang.Class.newInstance3(Class.java(Compiled Code))

  at java.lang.Class.newInstance(Class.java(Compiled Code))

  at
commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:1
57)

  at
commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126)

  at
commonj.sdo.impl.HelperProvider.(HelperProvider.java:69)

  at commonj.sdo.helper.XMLHelper.(XMLHelper.java:200)

  at
sca.component.java.impl.XMLValidateImpl.doValidation(XMLValidateImpl.jav
a:59)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a(Compiled Code))

  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a(Compiled Code))

  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java(Compiled Code))

  at java.lang.reflect.Method.invoke(Method.java(Compiled Code))

  at
com.ibm.ws.sca.internal.java.handler.JavaReflectionAdapter.invoke(JavaRe
flectionAdapter.java:138)

  at
com.ibm.ws.sca.internal.java.handler.JavaImplementationHandler.processMe
ssage(JavaImplementationHandler.java:258)

  at
com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag
e(MessageDispatcherImpl.java:386)

  at
com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM
essageImpl.java:476)

  at
com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessage(Mo
duleSessionBean.java:335)

  at
com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.transactionNotSuppor
tedActivitySessionSupports(ModuleSessionBean.java:276)

  at
com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.transactio
nNotSupportedActivitySessionSupports(EJSLocalStatelessModule_43132892.ja
va:199)

  at
com.ibm.ws.sca.internal.uow.handler.UOWStrategyImpl.transactionLocalActi
vitySessionAny(UOWStrategyImpl.java:406)

  at
com.ibm.ws.sca.internal.uow.handler.UOWAttribute.invoke(UOWAttribute.jav
a:478)

  at
com.ibm.ws.sca.internal.uow.handler.AbstractUOWHandler.processMessage(Ab
stractUOWHandler.java:162)

  at
com.ibm.ws.sca.internal.uow.handler.UOWHandler.processMessage(UOWHandler
.java:81)

  at
com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag
e(MessageDispatcherImpl.java:397)

  at
com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM
essageImpl.java:476)

  at
com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessage(Mo
duleSessionBean.java:335)

  at
com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.transactionNotSuppor
tedActivitySessionNotSupported(ModuleSessionBean.java:284)

  at
com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.transactio
nNotSupportedActivitySessionNotSupported(EJSLocalStatelessModule_4313289
2.java:131)

  at
com.ibm.ws.sca.internal.uow.handler.UOWStrategyImpl.joinTransactionFalse
JoinActivitySessionFalse(UOWStrategyImpl.java:240)

  at
com.ibm.ws.sca.internal.uow.handler.UOWAttribute.invoke(UOWAttribute.jav
a:452)

Re: [SCA Native] Tuscany SCA Native for Windows is not msvc backwards compatible

[Pete Robbins]

I've applied 1529 and 1530.

Cheers,

On 10/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Hello all,
>
> I created a JIRA for this compilation issue and have already uploaded a
> patch. Can someone submit it please.
>
> https://issues.apache.org/jira/browse/TUSCANY-1530
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
>


-- 
Pete

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

Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible

[Caroline Maynard]

Brady Johnson (JIRA) wrote:
Tuscany SDO native for windows is not msvc backwards compatible 



Don't I know it. In the PHP project the automated build servers for Win 
use VC6, so we are obliged to use that compiler in the SDO for PHP 
project. Since the Tuscany team decided to support only VC8, I usually 
find some minor problems porting the code over - you'll find a trail of 
these in the issues database where I've sent the fixes back as patches. 
It's not really a big problem, more an inconvenience. However it was a 
policy decision by the Tuscany committers at the time. YMMV.


Again, with the localtime behaviour, this came from concerns about using 
non-reentrant versions of localtime(). You may not have noticed the 
SDOUserMacros.h file - this mechanism was introduced so that consumers 
of Tuscany C++ could adapt the macros to their environment. You can see 
the PHP version here:


http://cvs.php.net/viewvc.cgi/pecl/sdo/commonj/sdo/SDOUserMacros.h?view=markup

It would be helpful if you would keep this mechanism in place.


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

Re: [DAS] Transaction support

[Amita Vadhavkar]

-When connection is provider by caller(say container), there is no
meaning
of managedtx attribute, and it is better to let the caller handle the
transactionality of the operations. So, when DAS is instantiated using
external connection - mandate managedtx = false. Also, expose
getConnection() from DAS to give a ref. of the connection (User already owns
it, DAS is just providing ref.). DAS will not issue any commit/rollback

-When connection is created internally, managedtx has a meaning.
1>When false, DAS.getConnection() should be exposed and user should be
allowed to handle transactions. DAS should not issue any commits/rollbacks

2>When true, do not expose DAS.getConnection().

If TRANSACTION_DEMARCATION_PER_COMMAND is true, work like today (commit
/rollback per command).

If TRANSACTION_DEMARCATION_PER_COMMAND is false (now is time for DAS to
manager group of commands as a sigle transaction).Here, DAS at the simplest
can use a static FLAG  set/unset using methods
- void DAS.startTransaction(), //mark FLAG to set
- void DAS.endTransaction("commit/rollback"). //mark FLAG to reset
endTransaction() will issue commit/rollback based on arg passed to it.
For any exception condition DAS will issue rollback() on transaction and
will reset the FLAG.
Client needs to call start/endTransaction() for group of Commands.

Also, here for timeout impelmentation, Java Timer can be used.

Regards,
Amita

On 8/10/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
>
> Hi Amita,
>
> I think it can be useful to bunch commands, but I didn't get how you are
> planning to do it : (
>
> What would be the parameter of method getTransaction?
>
> Regards,
> Adriano Crestani
>
> On 7/12/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> >
> > Below is a simple matrix based on current RDB DAS Config, showing what
> it
> > does/does not
> > do today
> >
> > managedtx(default-true) - config attribute in  element
> to
> > control transactions
> >
> > managedtx   database conn. supplied effect on transaction
> >
> >
> --
> > 1)true   from caller each DAS
> command
> > undergoes commit/rollback
> > 2)false  from within DAS this is not handled
> > in
> > any way
> > 3)true   from within DAS each DAS command
> > undergoes commit/rollback
> > 4)false from caller DAS does not issue
> > commit/rollback, external caller manages
> >
> > Case 2) - when database Connection is created in RDB DAS, it does not
> > expose
> > it to caller
> > today. So,   in case 2) neither RDB DAS nor caller can manage
> > transactions.
> >
> > From above, it seems that, RDB DAS in general does not provide support
> to
> > handle a group
> > of Commands under one database transactions. Only case 4) is the place
> > when
> > multiple
> > DAS Commands can undergo as one transaction.
> >
> > To help serve the transaction control better, I would like to propose
> the
> > following requirements:-
> > [1]RDB DAS should have a way to issue commit/rollback for single/group
> of
> > Commands
> > [2]When there is exception, the ongoing transaction should be
> immediately
> > aborted by RDB
> >DAS irrespective of whether it was for single/group of Commands
> > [3]Optional Timeout feature - to have an escape route to end the
> > transaction controlled by
> > RDB DAS,  when it seems to linger for time > Timeout (to take care of
> > situations like
> > deadlocks).
> >
> >For this, I am thinking of introducing 2 new attributes in RDB DAS
> > Config
> >A) TRANSACTION_DEMARCATION_PER_COMMAND - true/false (mandatory when
> > managedtx=true)
> >B) TRANSACTION_TIMEOUT - millis (always optional)
> >These 2 attributes can be specified at  level.
> >
> > When case 1) or 3) - both these attributes will take effect. When 2) or
> > 4),
> > these will be
> > ignored.
> >
> > To handle case 2) - here user is required to be given handle to the
> > database
> > Connection,
> > created by RDB DAS (in 1) and 3), this should be prohibited, and in 4)
> > user
> > already has
> > handle of the  Connection.) This way, the responsibility of transaction
> > management can be
> > taken by user for 4)(as it is today) and 2)(as now user will get handle)
> >
> > For 1) and 3) - TRANSACTION_DEMARCATION_PER_COMMAND=true is already
> > working
> > in
> > RDB DAS today. For handling TRANSACTION_DEMARCATION_PER_COMMAND=false,
> > new APIs can be given to user like DAS.getTransaction().commit()
> > /rollback() , so in a
> > controlled way, user will be able to bunch group of Commands based on
> > business logic
> > and issue commits/rollbacks. Also, internally, RDB DAS will be
> responsible
> > to rollback in
> > case of exceptions and in case of Timeouts.
> >
> > Please share your thoughts.
> >
> > Regards,
> > Amita
> >
> > On 6/12/07, Amita Vadhavkar <[EMAIL 

[DAS] Relationship info using DBMS Metadata getCrossReference() - pros and cons?

[Amita Vadhavkar]

(Prev mail thread:-
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20770.html)
More on this...
Looks like, single table registry approach was taken to dump all rows
fetcted from database
without linking DataObjects, as there is no relationship information in DAS
Config.
So, from the above mail thread, as join between singer and song returns 3
rows, there were
3 singer DOs and 3 song DOs and it is user's responsibility to see that out
of 3 singer DOs
2 are actually identical.

So question here is...can DAS use DatabaseMetadata.getCrossReference() JDBC
API to form
relationship information when it is missing in DAS Config. To keep matter
simple, DAS can
take approach of using DAS Config relationship info as first priority and
DatabaseMetadata.getCrossReference()
 as next priority. In case queries involve tables where for some
relationship is defined in DAS Config and for some
it is not, DAS can just stick to DAS Config. i.e. avoid mixing DAS Config
provided relationship info and DBMS provided
relationship info. Whatever is the approach (we can take mixed approach too,
for that matter), it just needs to be
documented clearly.

DAS - from the basic usage so far, promotes less config and thus uses DBMS
Metadata info for tables
and columns when one is not available in DAS Config. So same can be extended
for Relationships too.

Are there any known issues around usage of
DatabaseMetadata.getCrossReference()?
Checked for Derby, MySQL so far and found no issues. Also, if some vendor do
not have
implementation for this method, we can detect exception/null/empty ResultSet
returns and
continue the way we are at present using SingleTableRegistry.

Comments?

Regards,
Amita