date:20070713


+1

On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote:


Amita Vadhavkar  has been helping DAS for couple months and recently
also started to help on SDO and had contributed many patches. I'd like
to give her developer access to JIRA so she can manage JIRAs with more
flexibility, etc.

Thoughts ?

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

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

Re: SCA 0.92 release?


Just a reminder - I did say I quite like the current approach. The
alternative suggestion was just to prompt some debate to make sure we're all
happy. I agree as soon as things start being separated out it raises its a
whole lot of new issues.

We do seem to have issues with build stability, was a bit surprising to come
back after a week away and find just so many problems getting a complete
build through. One reason for that may be that everyone is so busy with
their own work that they don't have time to investigate and fix other
problems when they arise. Maybe we all just need to slow down a bit and find
more time to spend on non-specific work items for the good of the project.

  ...ant

On 7/12/07, Luciano Resende [EMAIL PROTECTED] wrote:


I think there are two issues here. I thought Ant's suggestion were
more towards release/distribution, and you are raising the question
around build. For the build issue, my personal choice is to build all
the working modules, and comment the ones that are failing. This looks
like the approach we have agreed before. As for making this happen,
people should be more careful when making commits. I've started a new
thread on the current build issues, and based on feedback of the
community (if anyone is fixing them) I'll comment them out.

On 7/12/07, Simon Nash [EMAIL PROTECTED] wrote:
 I'm getting really concerned about all the extensions, samples, etc.
 that are now part of the Tuscany SCA Java build.  My latest struggle
 to get a clean build involves the OSGi-related modules and samples
 (see my recent post about today's problem with this).  It seems to be
 getting increasingly difficult to get a clean build without commenting
 out a number of modules.  So I am +1 for Ant's suggestion, and I think
 the default build should only build the core extensions and their
samples.

Simon

 Luciano Resende wrote:

  I would like to better understand your suggestion here, how this would
  affect the SCA distribution, we would have a sca-bin and an
  sca-extension distribution ? How would be the end user experience to
  deploy and use these extensions. Also, my understanding is that,
  today, we have many extensions in trunk, but when releases are cut, we
  are only shipping the official/production/stable ones, is that right
  ?
 
  On 7/12/07, ant elder [EMAIL PROTECTED] wrote:
 
  Was there any further discussion about this (I'm catching up on mail
  after
  being away so likely missed things)? Its an interesting question i
  think. So
  far we seem to be operating in that everyone can just add what
extensions
  they choose to trunk we don't need to get any consensus first. I
quite
  like
  this approach but there are other ways. One alternative could be to
have
  some 'core' set of extensions and another 'additional' set. The core
  set we
  deem by consensus are the official/production/stable/??? ones, and we
  need
  to vote to get an extension included in that core set, but anyone can
add
  what they like to the 'additional' set. Do others have any opinions
on
  this
  or suggestions on alternative approaches?
 
 ...ant
 
  On 7/3/07, Simon Nash [EMAIL PROTECTED] wrote:
  
   I'd like to restart the earlier discussion in
  
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19224.html
   about whether implementation.das and implementation.data should be
   packaged with SCA releases or DAS releases.
  
   I think it's better for these to be packaged with DAS releases as
   the code will be more aligned with evolving DAS capabilities than
   with evolving SCA capabilities.  This will allow new features to be
   added as and when it makes sense for DAS to move up to support
them.
  
  Simon
  
   Luciano Resende wrote:
  
Now that we are going to have a DAS release out, I'd like to plan
to
have implementation.das and implementation.data available for the
  next
release.
   
I also like to have some improvements to the Contribution
Services,
such as import/export and other scenarios that have been
described on
the list recently. I'll update the wiki with these items.
   
On 7/2/07, haleh mahbod [EMAIL PROTECTED] wrote:
   
Posting to tuscany-user list as well to get input.
   
Any real world scenarios/samples that can be shared by users? It
  would
   be
great if we could start building a library of tips and real
usage
examples..  a knowledge base.
   
Thanks
Haleh
   
On 7/2/07, Simon Laws [EMAIL PROTECTED] wrote:

 On 7/2/07, ant elder [EMAIL PROTECTED] wrote:
 
  On 7/2/07, Simon Laws [EMAIL PROTECTED] wrote:
  
   On 7/2/07, Venkata Krishnan [EMAIL PROTECTED] wrote:
   
Hi,
   
I am looking at the Policy Framework and shall update
the
  wiki
   on
 the
specifics soon.  Once this is done to some level, I'd
also
like to
  help
   a
bit with the ws-* things (may be WS-Security to start
with)
that Ant
  has

Re: Intermittent exception from itest\osgi-implementation suite


I've temporarily removed the module from the build under revision #555903.

On 7/12/07, Raymond Feng [EMAIL PROTECTED] wrote:

Hi,

I see the following exception thrown from the itest\osgi-implementation
suite intermittently. It seems to be a timing issue. Can somebody take a
look?

Thanks,
Raymond

Work thread Thread[main,5,main] - Order, submitted (play.com), fulfilled,
shippe
d (ParcelForce)
Test complete
Deactivated OSGiShipperComponentImpl bundle
Deactivated OSGiShipperComponentImpl bundle
Deactivated OSGiRetailerComponentImpl bundle
Deactivated OSGiRetailerComponentImpl bundle
Deactivated OSGiCustomerComponentImpl bundle
--- Exception with component : Unexpected problem executing task ---
java.lang.IllegalStateException: Service already unregistered.
at
org.apache.felix.framework.ServiceRegistrationImpl.unregister(Service
RegistrationImpl.java:105)
at
org.apache.felix.scr.AbstractComponentManager.unregisterComponentServ
ice(AbstractComponentManager.java:503)
at
org.apache.felix.scr.AbstractComponentManager.deactivateInternal(Abst
ractComponentManager.java:369)
at
org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComp
onentManager.java:55)
at
org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponent
Manager.java:176)
at
org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.ja
va:81)
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5 sec


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





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

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

Re: SCA 0.92 release?


Comments inline.

  Simon

ant elder wrote:


Just a reminder - I did say I quite like the current approach. The
alternative suggestion was just to prompt some debate to make sure we're 
all

happy. I agree as soon as things start being separated out it raises its a
whole lot of new issues.


The current flat module structure with a single top-level build was put
in place back in April when we had 47 modules and about 1600 java files
excluding the contents of contrib.  We now have 66 modules and about
2300 java files.  The current approach has served us well so far, but
I think the scope and variety of the contents of the SCA Java trunk have
grown to the point where we should think about what structure we need as
we move forward into a phase of adding more content that covers a greater
spectrum from core functionality to more specialized, and also from more
mature and stable to more experimental.

Yes, this does raise issues, and I think we need to discuss them and come
up with an approach that allows core content to be built quickly and
reliably, while making it easy for those who need the additional pieces
to include those in their builds.  We also need to retain the option of
building the complete trunk from the top that we have today.

I see this as more pressing than the release discussion.  That one's
interesting as well, and maybe the same solution could apply to both.
But they don't necessarily need to be tied together.  For example, when
a release comes up, we would always include all core functionality.
We could also choose to include selected additional functionality based
on its level of stability and maturity at the time of release.  This
would require the selected additional functionality to be included in
the release build.

We do seem to have issues with build stability, was a bit surprising to 
come

back after a week away and find just so many problems getting a complete
build through. One reason for that may be that everyone is so busy with
their own work that they don't have time to investigate and fix other
problems when they arise. Maybe we all just need to slow down a bit and 
find

more time to spend on non-specific work items for the good of the project.


This may be part of the reason.  I am trying to help with this by reporting
the build problems as I encounter them.  For the more specialized modules
like OSGi, I don't have enough knowledge to interpret the symptoms and work
out a fix myself.

Another part of the reason is the factor I mentioned above that the trunk
is growing ever larger and more diverse.  Just by statistics it is inevitable
that as this trend continues (which is a good thing), the number of build
breaks will be greater because of the larger number of moving parts.
I think we need to tackle this problem from both of these directions.


  ...ant

On 7/12/07, Luciano Resende [EMAIL PROTECTED] wrote:



I think there are two issues here. I thought Ant's suggestion were
more towards release/distribution, and you are raising the question
around build. For the build issue, my personal choice is to build all
the working modules, and comment the ones that are failing. This looks
like the approach we have agreed before. As for making this happen,
people should be more careful when making commits. I've started a new
thread on the current build issues, and based on feedback of the
community (if anyone is fixing them) I'll comment them out.


Commenting out failing modules certainly helps.  It's not a perfect
solution because it is reactive and only happens after one or two people
have already had a problem.  Also, there are some problems that seem
unique to a single person's environment, so these modules would presumably
not be commented out, leaving that person still with a problem.


On 7/12/07, Simon Nash [EMAIL PROTECTED] wrote:
 I'm getting really concerned about all the extensions, samples, etc.
 that are now part of the Tuscany SCA Java build.  My latest struggle
 to get a clean build involves the OSGi-related modules and samples
 (see my recent post about today's problem with this).  It seems to be
 getting increasingly difficult to get a clean build without commenting
 out a number of modules.  So I am +1 for Ant's suggestion, and I think
 the default build should only build the core extensions and their
samples.

Simon

 Luciano Resende wrote:

  I would like to better understand your suggestion here, how this 
would

  affect the SCA distribution, we would have a sca-bin and an
  sca-extension distribution ? How would be the end user experience to
  deploy and use these extensions. Also, my understanding is that,
  today, we have many extensions in trunk, but when releases are 
cut, we
  are only shipping the official/production/stable ones, is that 
right

  ?
 
  On 7/12/07, ant elder [EMAIL PROTECTED] wrote:
 
  Was there any further discussion about this (I'm catching up on mail
  after
  being away so likely missed things)? Its an interesting

[jira] Commented: (TUSCANY-1143) Generated code should separate metadata creation from registration to permit proper scoping


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

Kelvin Goodson commented on TUSCANY-1143:
-

Sorry to do this in such a piecemeal fashion,  but I note that we still have a 
reference to the dependent factories in the generated factory's init() method.  
 We can drop this completely.  The dependencies will then only be initialized 
the first time the static INSTANCES are referenced in the initializeMetaData 
calls as part of the register operation.

 Generated code should separate metadata creation from registration to permit 
 proper scoping
 ---

 Key: TUSCANY-1143
 URL: https://issues.apache.org/jira/browse/TUSCANY-1143
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
Reporter: Kelvin Goodson
 Fix For: Java-SDO-1.0

 Attachments: 1143.patch


 The switch to registration of metadata from the global scope to selected 
 scopes is not complete yet, although for all current test cases there are no 
 failures.
 Currently the generated init() method for a factory calls the deprecated 
 SDOUtil.registerStaticTypes for its simple dependencies.
 In the simple case this is just ModelFactory and SDOFactory,  but could 
 contain other user generated dependencies if for example
 there were to be an xsd import of another namespace (exposed a gap in our 
 test case set).  This would mean that the user generated model dependency
 would also be registered against the global registry.
 It is proposed that all registrations, including the built in models, are 
 made against the helper context provided to the Factory's register method.
 I.e. a state invariant that no models are ever registered against the global 
 registry.
 The pattern of looking up models from within packages is not required, since 
 the code can just refer to each model's singleton INSTANCE (see below for the 
 exception SDOFactoryImpl).  Creation of the metadata should be done in the 
 init
 method, and the registration of all metadata (built-in or otherwise) should 
 be done in the register method. It would appear on inspection that no 
 reference to the simple dependencies of a factory need be made in its init 
 method,  and simple reference to the dependencies INSTANCE in the register 
 will be enough to ensure that those dependencies are initialised before being 
 registered against the provided scope. 
 SDOFactoryImpl does not have an INSTANCE currently.  The current proposed 
 solution is to modify SDOFactory to have an INSTANCE, in order that it can 
 behave like an ordinary generated dependency in this new approach.

-- 
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: lost wiki login credentials

2007-07-13 Thread Venkata Krishnan


Hi Kelvin,

I will send your credentials to your mail id.

- Venkat

On 7/13/07, kelvin goodson [EMAIL PROTECTED] wrote:

One of the few things I have truly lost in my recent hard drive crash was my
login details for the tuscany wiki.  They seem to have been saved in my
firefox browser and no-where else :-(How do I retrieve this?  Can
someone help please?

Regards, Kelvin.

P.S.
In the meantime I'll record the update I wanted to make to the SDO FAQ
section here so that I can do it later.

re the FAQ for Installing JavaJet function in eclipse,  to do this via Help
= Software Updates = Find and Install
if you select Java Emmitter Templates (JET) SDKIt may complain that you
don't have the codegen plugin.  To get this you must also tick EMF Extender
SDK.



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

Re: Website ACL


I'm not sure I follow how it gets from the reply at [1] to giving any old
person with a CLA on file write access to our website?

i'm not sure that policy is required: just an understanding and application
of the usual apache process...documentation is as important as code. both
are source and the same rulesapply. provenance needs to be established and
oversight maintained.

That to me says you need to be a committer.  Fine to give anyone with a CLA
on file who asks write access to the separate TUSCANYWIKI space but I think
the actual project website needs to be more controlled than that.

  ...ant

On 7/10/07, Luciano Resende [EMAIL PROTECTED] wrote:


Based on the following discussion on Apache General [1], I'd like to
give Website write permissions to members of the community that have a
CLA on file [2].

Thoughts ?

[1]
http://www.mail-archive.com/general%40incubator.apache.org/msg14391.html
[2] http://people.apache.org/~jim/committers.html

--
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 packaging (was Re: SCA 0.92 release?)


I agree that data integration is needed in SCA and that DAS has an
important role to play in this.  This close connection is the
reason why DAS (and SDO) are part of the Tuscany project.  And
beacuse of this, we as the Tuscany project have the opportunity to
decide the optimal packaging of the various interdependent pieces.
The creates a different situation than the one we have with the
other SCA extension dependencies that involve other projects.

I think the main reason to have implementation-das packaged with
DAS is that the functionality and evolution of implementation-das
is likely to be more closely bound to DAS evolution than to
SCA evolution.  DAS isn't yet a published spec, and the declarative
DAS for data service exposure is a new concept that I would expect
to evolve quite rapidly.  The reference [1] below alludes to this.
It's much less likely that SCA would undergo changes that would
require changes to DAS or implementation-das (or vice versa).

  Simon

Luciano Resende wrote:


Data integration is something needed in SCA. The main idea around
Implementation.das [1] is to integrate DAS and SCA to allow exposing
services that interact with a persistent layer in a declarative
fashion hiding some of the implementation details from the service
developer. Some more info is also available in [3].

As discussed on the following thread [4], we have many other
dependencies, and I'd like to still treat the DAS dependency as the
others. As for inclusion on the next release distros, I think this is
something that needs to be accessed around the time we cut the next
branch, if you would ask me today, I'd say implementation.das still
need a little more work before it could be included on a release, and
it is also waiting for the DAS beta1 release to get approved.

As for your comment around build issue :


On the DAS packaging specifically, I'm unable to build the SCA trunk
because of implementation.das issues (see my post of yesterday).
I'm sure we'll figure these issues out eventually, but this points
out the problems with tightly coupling SCA builds to a particular
level of DAS, which is moving forward rapidly (that's great!)



this was caused by SDO dependencies, and affected many other modules
on the Tuscany SCA build, but looks like Raymond and I have addressed
all of them now and things should be back to normal and stable. Note
that you might need to re-build the latest SDO from trunk to get the
fixes.

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18908.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09978.html
[3] 
http://incubator.apache.org/tuscany/das-overview.data/das-data-services-v01.pdf 


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


On 7/12/07, Simon Nash [EMAIL PROTECTED] wrote:


Thanks for restarting the discussion on this.  I think DAS is in
a special position because it's part of our project and therefore
we have the opportunity to choose whether these DAS components are
packaged and released with Tuscany SCA or with Tuscany DAS.
For other SCA extensions, we as Tuscany could only choose whether
to make them core or additional since it would be up to the other
project to decide whether to package them as part of its releases.

I'd therefore like to take these as separate discussions (hence
the change of subject line on this post).

On the DAS packaging specifically, I'm unable to build the SCA trunk
because of implementation.das issues (see my post of yesterday).
I'm sure we'll figure these issues out eventually, but this points
out the problems with tightly coupling SCA builds to a particular
level of DAS, which is moving forward rapidly (that's great!)

I think the alternative packaging that I proposed would be better
for both SCA and for DAS.  For SCA, it reduces the number of
moving parts, instability, and opportunity for build breaks.
For DAS, it creates an component that extends both SCA and SDO
to add significant value.  These base dependencies should be quite
stable from now on, so DAS builds would be largely independent of
the current state of the SCA and SDO trunks.

What do other people think about this?

   Simon

ant elder wrote:

 Was there any further discussion about this (I'm catching up on mail 
after

 being away so likely missed things)? Its an interesting question i
 think. So
 far we seem to be operating in that everyone can just add what 
extensions
 they choose to trunk we don't need to get any consensus first. I 
quite like
 this approach but there are other ways. One alternative could be to 
have
 some 'core' set of extensions and another 'additional' set. The core 
set we
 deem by consensus are the official/production/stable/??? ones, and 
we need
 to vote to get an extension included in that core set, but anyone 
can add
 what they like to the 'additional' set. Do others have any opinions 
on this

 or suggestions on alternative approaches?

   ...ant

 On 7/3/07, Simon Nash [EMAIL PROTECTED]

Re: [VOTE] Release Tuscany Java SCA 0.91-incubating RC3


+1 from me.

  ...ant

On 7/12/07, Venkata Krishnan [EMAIL PROTECTED] wrote:


Hi again :),

Please review and vote on the 0.91 release artifacts of Tuscany SCA for
Java. (RC3).

The artifacts are available for review at:
http://people.apache.org/~svkrish/tuscany/0.91-rc3/

This includes the binary and source distributions, the RAT reports, and
the
Maven staging repository.

The SVN tag for the release is:

https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc3-incubating/

- Comments on RC2 related to READMEs of samples have been fixed [1].
- License file in binary distribution now includes the missing BSD
license reported during IPMC review [2]

Othere than these two there are no other changes made to this RC over
the previous one.

[1] -
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19690.html
[2] -
http://www.mail-archive.com/[EMAIL PROTECTED]/msg14615.html

Looks ok to me - so here's my +1.

Thanks

- Venkat

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

Re: Getting developer jira access to Amita Vadhavkar

2007-07-13 Thread Fuhwei Lwo

+1 from me

Fuhwei Lwo

Luciano Resende [EMAIL PROTECTED] wrote: Amita Vadhavkar  has been helping 
DAS for couple months and recently
also started to help on SDO and had contributed many patches. I'd like
to give her developer access to JIRA so she can manage JIRAs with more
flexibility, etc.

Thoughts ?

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

[jira] Created: (TUSCANY-1431) DAS with XQuery based data access support

2007-07-13 Thread Amita Vadhavkar (JIRA)

DAS with XQuery based data access support
-

 Key: TUSCANY-1431
 URL: https://issues.apache.org/jira/browse/TUSCANY-1431
 Project: Tuscany
  Issue Type: New Feature
  Components: Java DAS XQuery
Affects Versions: Java-DAS-Next
Reporter: Amita Vadhavkar


place for submitting incremental patches for the ground work of XQuery DAS

-- 
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: [RDB DAS] Consistent use of Parameters in Config

2007-07-13 Thread Amita Vadhavkar


I went through [1] and [2], it talks about removing name attribute from
Parameter
and about generatedKeys. Also saw JIRA-528 on the way. But I could not get
the exact
rational behind removing Name from Parameter (It is definitely not required
by JDBC for sure, but can have some aid in usage clarity)

1)One place in RDB DAS (here Name is not removed and can not be removed)
BasicCustomerMappingWithCUD.xml (CRUDWithChangeHistory.testDeleteAndCreate
())
Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd;

 Table tableName=CUSTOMER
 create sql=insert into customer values (?, ?, ?) parameters=ID
LASTNAME ADDRESS/
 update sql=update customer set lastname = ?, address = ? where ID =
? parameters=LASTNAME ADDRESS ID/
 delete sql=delete from customer where ID = ? parameters=ID/
 /Table

/Config

This is informative because we have create sql=insert into customer values
(?, ?, ?) parameters=ID LASTNAME ADDRESS/
In the client code we will typically have
   DataObject customer = root.createDataObject(CUSTOMER);
   customer.setInt(ID, 720);
   customer.set(LASTNAME, foobar);
   customer.set(ADDRESS, asdfasdf);

   das.applyChanges(root);

Here client has a chance to understand that he needs to set ID, LASTNAME,
ADDRESS because the config states -  parameters=ID LASTNAME ADDRESS and
internally we will map names to idx when doing
PreparedStatement.setParameter.

For the matter of whether it is required to have parameters=ID LASTNAME
ADDRESS , it is  required. We can no say parameters=1 2 3 or X Y Z
because during SDO to Parameter mapping  (in ChangeOperation) we need the
Name of parameter, so Name and Idx both are required.

2)Another place in RDB DAS (this is where Name is removed in JIRA-658)
   Command name=InsertCustomers SQL=insert into CUSTOMER values (?,?,?)
 kind=Insert
   Parameter direction=IN index=1 columnType=commonj.sdo.IntObject/
   Parameter direction=IN index=2
columnType=commonj.sdo.String/

   Parameter direction=IN index=3
columnType=commonj.sdo.String/

   /Command

A typical client code will be,
   Command insert = das.getCommand(InsertCustomers);
   insert.setParameter(1, 1000);
   insert.setParameter(2, MYNAME);
   insert.setParameter(3, MYADDR);
   insert.execute();

In this example, nowhere the client has a way to know what 1000, MYNAME or
MYADDRESS means. If this  is a table with many columns and such many tables,
how the client is going to set values using setParameter() with any comfort
level, unless otherwise the he has a direct access to database and can know
the names and order or columns in database table or if the insert syntax is
used
like insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?) 

but in tables having large number of rows, it is likely that client will try
to have short
(insert) statements without column names. And this is what I felt was the
issue of the user in
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html, as he
admitted that even though JDBC does not need Names, he needs it for the sake
of clarity.

So, as such, first thig I am just curious to know is, what were the
advantages of JIRA-658?

Also, not quite clear about Also, have you thought about multiple queries
retrieving the same column,you would have to configure the parameter in
multiple places. If there are 10 different Select Commands with 10
different Where clauses, we anyway need to set Parameters in 10 different
places.

I guess I am completely intepreting something wrong here, please help.

Regards,
Amita

On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote:


The named parameter support was removed from earlier versions of DAS,
here is some previous discussion around the subject [1] See also
tuscany-658. We might need to do further cleanup on the impl, if I
understood correctly.

As for your second suggestion (parameter column types), could you
expose some use cases scenarios where this would be helpful ? Also,
have you thought about multiple queries retrieving the same column,
you would have to configure the parameter in multiple places.

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
[2] http://issues.apache.org/jira/browse/TUSCANY-658

On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
 Hi,
 A few days ago there was a user question about passing name in
Parameter:-
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html

 When checking how Parameters are used in Config, came across the
following
 points.
 There is a difference in Config (SDO) generated Parameter and
 org.apache.tuscany.das.rdb.impl.ParameterImpl.

 The one from Config has only ColumnType, Direction and Index whereas in
 impl, it has
 in addition Name and some other attributes. Not having Name in Config
 generated version
 does not cause any problems anywhere as JDBC PreparedStatement
 setParameter() requires
 Index and not Name. But to give a consistent user experience, it can be
good
 to add Name

Re: lost wiki login credentials

2007-07-13 Thread kelvin goodson


Venkat
  many thanks,
Kelvin.

On 13/07/07, Venkata Krishnan [EMAIL PROTECTED] wrote:


Hi Kelvin,

I will send your credentials to your mail id.

- Venkat

On 7/13/07, kelvin goodson [EMAIL PROTECTED] wrote:
 One of the few things I have truly lost in my recent hard drive crash
was my
 login details for the tuscany wiki.  They seem to have been saved in my
 firefox browser and no-where else :-(How do I retrieve this?  Can
 someone help please?

 Regards, Kelvin.

 P.S.
 In the meantime I'll record the update I wanted to make to the SDO FAQ
 section here so that I can do it later.

 re the FAQ for Installing JavaJet function in eclipse,  to do this via
Help
 = Software Updates = Find and Install
 if you select Java Emmitter Templates (JET) SDKIt may complain that
you
 don't have the codegen plugin.  To get this you must also tick EMF
Extender
 SDK.


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

[jira] Commented: (TUSCANY-1143) Generated code should separate metadata creation from registration to permit proper scoping

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

Kelvin Goodson commented on TUSCANY-1143:
-

David,

just to be a bit more thorough in my treatment of your comments. I think
issues 1,2 and 3 are addressed by simply using a reference to the each of the
static Factory INSTANCEs for dependencies in the initializeMataData() methods.
I have been able to remove the scope variable and associated methods, including
the getStaticFactory(URI) and successfully run the tests. Point 4 is
addressed by editing the SDOFactory and introducing an INSTANCE variable that
will similarly initialize the SDOPackage metadata, then we can treat it in
same way as any factory generated by the SDO generator.

Generated code should separate metadata creation from registration to permit
proper scoping
---

Key: TUSCANY-1143
URL: https://issues.apache.org/jira/browse/TUSCANY-1143
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
Reporter: Kelvin Goodson
Fix For: Java-SDO-1.0

Attachments: 1143.patch

The switch to registration of metadata from the global scope to selected
scopes is not complete yet, although for all current test cases there are no
failures.
Currently the generated init() method for a factory calls the deprecated
SDOUtil.registerStaticTypes for its simple dependencies.
In the simple case this is just ModelFactory and SDOFactory, but could
contain other user generated dependencies if for example
there were to be an xsd import of another namespace (exposed a gap in our
test case set). This would mean that the user generated model dependency
would also be registered against the global registry.
It is proposed that all registrations, including the built in models, are
made against the helper context provided to the Factory's register method.
I.e. a state invariant that no models are ever registered against the global
registry.
The pattern of looking up models from within packages is not required, since
the code can just refer to each model's singleton INSTANCE (see below for the
exception SDOFactoryImpl). Creation of the metadata should be done in the
init
method, and the registration of all metadata (built-in or otherwise) should
be done in the register method. It would appear on inspection that no
reference to the simple dependencies of a factory need be made in its init
method, and simple reference to the dependencies INSTANCE in the register
will be enough to ensure that those dependencies are initialised before being
registered against the provided scope.
SDOFactoryImpl does not have an INSTANCE currently. The current proposed
solution is to modify SDOFactory to have an INSTANCE, in order that it can
behave like an ordinary generated dependency in this new approach.

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

A design question about visitor pattern in Tuscany

2007-07-13 Thread shaoguang geng

I found that there is a Visitable interface, and almost all the classes of the 
composite-component model have implemented this interface. So it seems a 
Visitor Pattern applied. But in fact, it is just a un-finished work, the 
pattern is never used, no implement of Visitor interface.

Those Processors inside ModuleActivators just look like visitors, but they are 
not Visitor Pattern's visitors.

So, I may ask for a favor, that some one could tell me the truth.

 
-
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.

[jira] Commented: (TUSCANY-1143) Generated code should separate metadata creation from registration to permit proper scoping

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

Kelvin Goodson commented on TUSCANY-1143:
-

David,
I don't think we want to make a 1:1 association between scopes and factories.
The only place that you need the new scope instance member in your current
implementation is in the method getInstanceStaticFactory(String namespaceURI),
which is only referenced in the initializeMetaData methods of generated factory
impls. This is not needed. You can refer to the Factory interface's INSTANCE
variable. This is what I meant by The pattern of looking up models from
within packages is not required, since the code can just refer to each model's
singleton INSTANCE so the line in generated factories that currently looks
like
ModelFactoryImpl theModelPackageImpl =
(ModelFactoryImpl)getInstanceStaticFactory(ModelFactoryImpl.NAMESPACE_URI);

would become
ModelFactoryImpl theModelPackageImpl =
(ModelFactoryImpl)ModelFactory.INSTANCE;

Generated code should separate metadata creation from registration to permit
proper scoping
---

Attachments: 1143.patch

--
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: Getting developer jira access to Amita Vadhavkar


+1 (non-binding)

  Simon

ant elder wrote:


+1

On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote:



Amita Vadhavkar  has been helping DAS for couple months and recently
also started to help on SDO and had contributed many patches. I'd like
to give her developer access to JIRA so she can manage JIRAs with more
flexibility, etc.

Thoughts ?

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






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

[jira] Created: (TUSCANY-1432) Unable to implement helloworld-ws-reference sample with complex types.

2007-07-13 Thread David Haney (JIRA)

Unable to implement helloworld-ws-reference sample with complex types.
--

 Key: TUSCANY-1432
 URL: https://issues.apache.org/jira/browse/TUSCANY-1432
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-M2
 Environment: Windows XP, JDK 1.5.0_11-b03, ant 1.7.0
Reporter: David Haney
 Attachments: helloworld-ws-reference.zip

I'm attempting to modify the helloworld-ws-reference example so that it is 
sending a complexType instead of simple types, and am having trouble with an 
exception that I can't explain.  I wasn't able to find an example of this sort 
of thing in one of the other samples, so I've been trying to piece together the 
necessary changes, and I'm guessing I've just missed a step along the way.  

Here's what I've done so far (all file references are relative to
installdir/samples/helloworld-ws-reference):

- Modified the src/main/resources/wsdl/helloworld.wsdl So that the getGreetings 
operation contains a complexType:

...

element name=getGreetings
  complexType
sequence
  element name=name type=tns:Name/
/sequence
  /complexType
/element

...

complexType name=Name
  sequence
element name=first type=xsd:string/
element name=last type=xsd:string/
  /sequence
/complexType

...

- Next, I code-generated the static SDO types based on the updated WSDL file.  
I added the following to the root build.xml in order to generate the types (I 
wasn't able to find the necessary code-generator tools in the SCA distribution, 
so the following depends on an external SDO distribution specified by the 
environment variable TUSCANY_SDO.  I used the tuscany-sdo-1.0-incubating-beta1 
binary distribution for this test):

...

property environment=env/   

target name=codegen depends=init
  java classname=org.apache.tuscany.sdo.generate.XSD2JavaGenerator
fork=true
classpath
  pathelement
path=${env.TUSCANY_SDO}/lib/tuscany-sdo-tools-1.0-incubating-beta1.jar
/
  pathelement path=${env.TUSCANY_SDO}/lib/common-2.2.2.jar/
  pathelement path=${env.TUSCANY_SDO}/lib/ecore-2.2.2.jar/
  pathelement
path=${env.TUSCANY_SDO}/lib/sdo-api-r2.1-1.0-incubating-beta1.jar/
  pathelement
path=${env.TUSCANY_SDO}/lib/tuscany-sdo-impl-1.0-incubating-beta1.jar/

  pathelement path=${env.TUSCANY_SDO}/lib/ecore-xmi-2.2.2.jar/
  pathelement path=${env.TUSCANY_SDO}/lib/xsd-2.2.2.jar/
  pathelement
path=${env.TUSCANY_SDO}/lib/ecore-change-2.2.2.jar/
  pathelement path=${env.TUSCANY_SDO}/lib/codegen-2.2.2.jar/
  pathelement
path=${env.TUSCANY_SDO}/lib/codegen-ecore-2.2.2.jar/
/classpath
arg value=-targetDirectory/
arg value=src/main/java/
arg value=-javapackage/
arg value=helloworld/
arg value=src/main/resources/wsdl/helloworld.wsdl/
  /java
/target

...


- This produced the following files in src/main/java/helloworld:

getGreetings.java
getGreetingsResponse.java
HelloworldFactory.java
Name.java
impl/getGreetingsImpl.java
impl/getGreetingsResponseImpl.java
impl/HelloworldFactoryImpl.java
impl/NameImpl.java

- Once these were in place, I modified HelloWorldService::getGreetings() to 
take the new Name type:

...

public interface HelloWorldService {
public String getGreetings(Name name); }

- and modified HelloWorldServiceComponent::getGreeting() to match:

... 
public String getGreetings(Name name) {
System.out.println(Called getGreetings);
return helloWorldService.getGreetings(name);
}

- Finally, I modified HelloWorldServiceClient::main() to create a Name 
instance, and pass it into the getGreetings() call.

...

Name name = HelloworldFactory.INSTANCE.createName();

name.setFirst(David);
name.setLast(Haney);

String value = helloWorldService.getGreetings(name);

...

- Once all of the code changes were in place, I went back to the 
src/main/resources/helloworldws.composite file, and attempted to update it so 
that it would recognize that it should be using the SDO binding:

dbsdo:import.sdo
  xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
  factory=helloworld.HelloworldFactory/


- That seemed like it should be sufficient based on the 
documentation/tests/demos/examples that I was able to find, however when I 
attempt to run the application, I'm seeing the following output:

Buildfile: build.xml

run:
 [java] log4j:WARN No appenders could be found for logger 
(org.apache.axiom.om.util.StAXUtils).
 [java] log4j:WARN Please initialize the log4j system properly.
 [java] Injected helloWorldService
 [java] Called getGreetings
 [java] Exception in thread main org.apache.axiom.om.OMException:
java.util.NoSuchElementException: End of stream has reached.
 [java] at
org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:2
11)
 [java] at

[jira] Updated: (TUSCANY-1432) Unable to implement helloworld-ws-reference sample with complex types.

2007-07-13 Thread David Haney (JIRA)


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

David Haney updated TUSCANY-1432:
-

Attachment: helloworld-ws-reference.zip

A test case for modifying the helloworld-ws-reference sample for use with 
complex types and the SDO databinding.

 Unable to implement helloworld-ws-reference sample with complex types.
 --

 Key: TUSCANY-1432
 URL: https://issues.apache.org/jira/browse/TUSCANY-1432
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-M2
 Environment: Windows XP, JDK 1.5.0_11-b03, ant 1.7.0
Reporter: David Haney
 Attachments: helloworld-ws-reference.zip


 I'm attempting to modify the helloworld-ws-reference example so that it is 
 sending a complexType instead of simple types, and am having trouble with an 
 exception that I can't explain.  I wasn't able to find an example of this 
 sort of thing in one of the other samples, so I've been trying to piece 
 together the necessary changes, and I'm guessing I've just missed a step 
 along the way.  
 Here's what I've done so far (all file references are relative to
 installdir/samples/helloworld-ws-reference):
 - Modified the src/main/resources/wsdl/helloworld.wsdl So that the 
 getGreetings operation contains a complexType:
 ...
 element name=getGreetings
   complexType
 sequence
   element name=name type=tns:Name/
 /sequence
   /complexType
 /element
 ...
 complexType name=Name
   sequence
 element name=first type=xsd:string/
 element name=last type=xsd:string/
   /sequence
 /complexType
 ...
 - Next, I code-generated the static SDO types based on the updated WSDL file. 
  I added the following to the root build.xml in order to generate the types 
 (I wasn't able to find the necessary code-generator tools in the SCA 
 distribution, so the following depends on an external SDO distribution 
 specified by the environment variable TUSCANY_SDO.  I used the 
 tuscany-sdo-1.0-incubating-beta1 binary distribution for this test):
 ...
 property environment=env/ 
 target name=codegen depends=init
   java classname=org.apache.tuscany.sdo.generate.XSD2JavaGenerator
 fork=true
 classpath
   pathelement
 path=${env.TUSCANY_SDO}/lib/tuscany-sdo-tools-1.0-incubating-beta1.jar
 /
   pathelement path=${env.TUSCANY_SDO}/lib/common-2.2.2.jar/
   pathelement path=${env.TUSCANY_SDO}/lib/ecore-2.2.2.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/sdo-api-r2.1-1.0-incubating-beta1.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/tuscany-sdo-impl-1.0-incubating-beta1.jar/
 
   pathelement path=${env.TUSCANY_SDO}/lib/ecore-xmi-2.2.2.jar/
   pathelement path=${env.TUSCANY_SDO}/lib/xsd-2.2.2.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/ecore-change-2.2.2.jar/
   pathelement path=${env.TUSCANY_SDO}/lib/codegen-2.2.2.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/codegen-ecore-2.2.2.jar/
 /classpath
 arg value=-targetDirectory/
 arg value=src/main/java/
 arg value=-javapackage/
 arg value=helloworld/
 arg value=src/main/resources/wsdl/helloworld.wsdl/
   /java
 /target
 ...
 - This produced the following files in src/main/java/helloworld:
 getGreetings.java
 getGreetingsResponse.java
 HelloworldFactory.java
 Name.java
 impl/getGreetingsImpl.java
 impl/getGreetingsResponseImpl.java
 impl/HelloworldFactoryImpl.java
 impl/NameImpl.java
 - Once these were in place, I modified HelloWorldService::getGreetings() to 
 take the new Name type:
 ...
 public interface HelloWorldService {
 public String getGreetings(Name name); }
 - and modified HelloWorldServiceComponent::getGreeting() to match:
 ... 
 public String getGreetings(Name name) {
 System.out.println(Called getGreetings);
 return helloWorldService.getGreetings(name);
 }
 - Finally, I modified HelloWorldServiceClient::main() to create a Name 
 instance, and pass it into the getGreetings() call.
 ...
 Name name = HelloworldFactory.INSTANCE.createName();
 name.setFirst(David);
 name.setLast(Haney);
 String value = helloWorldService.getGreetings(name);
 ...
 - Once all of the code changes were in place, I went back to the 
 src/main/resources/helloworldws.composite file, and attempted to update it so 
 that it would recognize that it should be using the SDO binding:
 dbsdo:import.sdo
   xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
   factory=helloworld.HelloworldFactory/
 - That seemed like it should be sufficient based on the 
 documentation/tests/demos/examples that I was able to find, however when I 
 attempt to run the application, I'm seeing the following output:
 Buildfile: build.xml
 run:
  [java] log4j:WARN No appenders could be found for logger

Re: Getting developer jira access to Amita Vadhavkar

2007-07-13 Thread Venkata Krishnan


+1 from me too.

- Venkat

On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote:

Amita Vadhavkar  has been helping DAS for couple months and recently
also started to help on SDO and had contributed many patches. I'd like
to give her developer access to JIRA so she can manage JIRAs with more
flexibility, etc.

Thoughts ?

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




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

Re: TUSCANY-1379 and incremental updates to SCA contributions


Ok I just read spec section 1.10.2 about contributions and import/export, it
sounds like the runtime shouldn't be using a single class loader then but
separate class loaders for each contribution, right? This seems to me like
it should be fixed before we worry about TUSCANY-1379 as there doesn't seem
much point trying to stop/start individual components if it doesn't do
anything till the domain is stop/started. How about i go look at fixing this
first, what do people think?

  ...ant

On 7/13/07, Raymond Feng [EMAIL PROTECTED] wrote:


Hi,

I'm excited to see it as an important step for the Tuscany integration
with
web containers. Now that web applications start to share the same Tuscany
runtime, I expect to see the isolation/sharing issues between different
contributions :-). Java classloading is one of them. Luciano has started
the
work to support import/export for XML artifacts and the java import/export
will follow.

Thanks,
Raymond

- Original Message -
From: ant elder [EMAIL PROTECTED]
To: tuscany-dev tuscany-dev@ws.apache.org
Sent: Thursday, July 12, 2007 9:36 AM
Subject: TUSCANY-1379 and incremental updates to SCA contributions


 As part of looking at TUSCANY-1379 I've added a new webapp distribution
 module that supports using multiple SCA contribution jars and hot update
 of
 those jars so you can modify the contribution jar and the changes are
 picked
 up without having to restart the webapp. Its not in the build but you
can
 manually build distribution/webapp (or there's a prebuilt war I'm using
at
 http://people.apache.org/~antelder/tuscany/tuscany.war). Its also got a
 very
 trivial web interface that shows the current active components, go to:
 http://localhost:8080/tuscany/. To use it you just drop your SCA
 contribution jar's into the sca-contributions folder within the webapp
and
 they should get picked up and installed right away, eg the Tuscany
 sample-calculator.jar or helloworld-ws-service.jar work. Once installed
 you
 can use something like winzip to edit the contents of the jar's and the
 changes should also get picked up.

 Playing around with this highlights lots of problems, there's TODOs
around
 the code about some of them, but one issue is the way the runtime and
 contribution service currently uses a single class loader so if you try
to
 update and stop/start a single component or contribution the changes
don't
 get picked without restarting the entire SCA domain to use a new class
 loader. I wondered if this class loader issue is something that might
 already be being looked at with all the other work going on right now in
 this area?

   ...ant



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

lost wiki login credentials

2007-07-13 Thread kelvin goodson


One of the few things I have truly lost in my recent hard drive crash was my
login details for the tuscany wiki.  They seem to have been saved in my
firefox browser and no-where else :-(How do I retrieve this?  Can
someone help please?

Regards, Kelvin.

P.S.
In the meantime I'll record the update I wanted to make to the SDO FAQ
section here so that I can do it later.

re the FAQ for Installing JavaJet function in eclipse,  to do this via Help
= Software Updates = Find and Install
if you select Java Emmitter Templates (JET) SDKIt may complain that you
don't have the codegen plugin.  To get this you must also tick EMF Extender
SDK.

Re: Does DAS could support the blob field read and write ?

2007-07-13 Thread Amita Vadhavkar


Hi All,
In an attempt to see how to ensure support from DAS to Blob, Clob etc. I
tried
a MySQL table with Blob column having some rows and tried to access it using
DAS. It could not go through and on the way of debugging - I finally wrote
the below
code (part from
org.apache.tuscany.das.rdb.graphbuilder.schema.ResultSetTypeMap),
to see what is supported and what is not.
---
public class TestSupportedTypes {
//picked from
org.apache.tuscany.das.rdb.graphbuilder.schema.ResultSetTypeMap
   public static void main(String[] args){
   TypeHelper helper = TypeHelper.INSTANCE;
   SDOPackage.eINSTANCE.eClass();//what is this for
   if(helper.getType(commonj.sdo, String) == null){
   System.out.println(String Not supported!);
   }
   if(helper.getType(commonj.sdo, Decimal) == null){
   System.out.println(Decimal Not supported!);
   }
   if(helper.getType(commonj.sdo, Boolean) == null){
   System.out.println(Boolean Not supported!);
   }
   if(helper.getType(commonj.sdo, boolean) == null){
   System.out.println(boolean Not supported!);
   }
   if(helper.getType(commonj.sdo, IntObject) == null){
   System.out.println(IntObject Not supported!);
   }
   if(helper.getType(commonj.sdo, Int) == null){
   System.out.println(Int Not supported!);
   }
   if(helper.getType(commonj.sdo, Long) == null){
   System.out.println(Long Not supported!);
   }
   if(helper.getType(commonj.sdo, long) == null){
   System.out.println(long Not supported!);
   }
   if(helper.getType(commonj.sdo, Float) == null){
   System.out.println(Float Not supported!);
   }
   if(helper.getType(commonj.sdo, float) == null){
   System.out.println(float Not supported!);
   }
   if(helper.getType(commonj.sdo, Double) == null){
   System.out.println(Double Not supported!);
   }
   if(helper.getType(commonj.sdo, double) == null){
   System.out.println(double Not supported!);
   }
   if(helper.getType(commonj.sdo, ByteArray) == null){
   System.out.println(ByteArray Not supported!);
   }
   if(helper.getType(commonj.sdo, Date) == null){
   System.out.println(Date Not supported!);
   }
   if(helper.getType(commonj.sdo, Clob) == null){
   System.out.println(Clob Not supported!);
   }
   if(helper.getType(commonj.sdo, Blob) == null){
   System.out.println(Blob Not supported!);
   }
   if(helper.getType(commonj.sdo, Array) == null){
   System.out.println(Array Not supported!);
   }
   if(helper.getType(commonj.sdo, Object) == null){
   System.out.println(Object Not supported!);
   }
   }
}

The result is :--
boolean Not supported!
long Not supported!
float Not supported!
double Not supported!
ByteArray Not supported!
Clob Not supported!
Blob Not supported!
Array Not supported!

Thus for all the above, in RDB DAS, getEDataType() returns null and then
finally gets a
NPE in GraphBuilderMetaData,createDynamicTypes() , when calling
SDOUtil.createProperty(), due to this null commonj.sdo.Type.

Please let me know if I am doing something totally wrong here. And what is
the way
to make RDB DAS work for the above Types.

Regards,
Amita

On 7/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:


Hi,
There is none at present, am giving it a try, will give you some update in
couple of hrs.
Regards,
Amita

On 7/13/07, litaojian [EMAIL PROTECTED] wrote:

 Hi Amita ,
 Thanks , but where is the sample that I could find ?





 litaojian
 2007-07-13



 发件人： Amita Vadhavkar
 发送时间： 2007-07-13 17:08:11
 收件人： [EMAIL PROTECTED]
 抄送：
 主题： Re: Does DAS could support the blob field read and write ?

 Hi,
 DAS does show support for Blob. I am trying a small sample with MySQL
 -DAS
 to verify
 the same. There is  also a DefaultConverter provided in DAS Impl which
 seems
 to
 be there for handling Blobs.
 Thanks,
 Amita

 On 7/13/07, litaojian  [EMAIL PROTECTED]  wrote:
 
  Hi All ,
 I need to read or write  the image data from database blob
 field ,
  Does the DAS support it ?  Is there any solution for this problem ?
 
 
  Best regards ,
 
 
 
 
  litaojian
  2007-07-13

[SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

2007-07-13 Thread Brady Johnson

Hello all,
 
I understand there is an SDO branch created for the SDO 2.1 spec
compliance changes. The SCA code also needs changes made for the SDO
changes, so can we just make an SCA branch where those changes can be
made.
 

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

Re: [DAS] XQuery-DAS

2007-07-13 Thread Doug Tidwell

Gang, how is XPath support implemented today?  I've looked at the code 
briefly in the past, but couldn't make sense of it.  I was hoping that 
XPath support came from the Xalan jar files.  If that were true, it would 
be a SMOP to replace the Xalan XPath libraries with the Saxon libraries. 
Saxon supports XSLT 2.0, XPath 2.0 and XQuery.

That's a straightforward approach to leveraging someone else's excellent 
work, although I don't know if Saxon's license would be compatible. 

Anyway, if somebody knows how XPath is implemented now, that would be a 
start towards figuring out how to plug in an XQuery engine.

Cheers, 
-Doug

SDO dependencies in implementation-das and implementation-data


I was looking through the Java SCA trunk for dependencies on SDO.
Both implementation-das and implementation-data use commonj.sdo APIs,
but they don't declare an SDO dependency in their poms.  This happens
to work out because the tuscany-das-rdb dependency pulls in the SDO
dependency.  Should the SDO dependency be declared directly rather
than pulled in indirectly in this way?

  Simon



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

SDO standard schemas published at osoa.org

2007-07-13 Thread Frank Budinsky

The xsd files containing the standard SDO types have recently been 
published at http://www.osoa.org/sdo/2.1/schemas/;.

To reference commonj.sdo types, for example, in your xsd files you can now 
import them like this:

xsd:import namespace=commonj.sdo 
schemaLocation=http://www.osoa.org/sdo/2.1/schemas/datagraph.xsd; /

Frank.

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

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes


The SDO HEAD will contain the ongoing development for the 2.1 spec
changes. The branch was created to maintain a stable version as some
of the spec changes will cause instability.

I think ongoing development should continue in HEAD so we do not need
an SCA branch. We just need to ensure that SCA HEAD will compile/run
against SDO HEAD.

What do you think?

Cheers,

On 13/07/07, Brady Johnson [EMAIL PROTECTED] wrote:

Hello all,

I understand there is an SDO branch created for the SDO 2.1 spec
compliance changes. The SCA code also needs changes made for the SDO
changes, so can we just make an SCA branch where those changes can be
made.


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]

[jira] Resolved: (TUSCANY-578) Exceptions thrown by SDO runtime not the same as defined in the spec


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

Kelvin Goodson resolved TUSCANY-578.


Resolution: Fixed

I applied the patch to the trunk and the branch, thanks.  I changed the package 
of the example code to example.org.xxx as we don't own com.sdo.xxx.  Ia 
commented out the failing tests you reference with a // Not fixed in 
TUSCANY-578 comment,  as I plan to close this defect now,  and open a fresh 
one to keep track of remaining / future issues. This one is way to complicated 
to use any more.

 Exceptions thrown by SDO runtime not the same as defined in the spec
 

 Key: TUSCANY-578
 URL: https://issues.apache.org/jira/browse/TUSCANY-578
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SCA-M2
Reporter: Brian Murray
Priority: Minor
 Fix For: Java-SDO-Next

 Attachments: 578.patch, 578.patch, 578.zip, 578.zip, 
 DataObjectUtil.patch


 On page 27 of V2.01 of the spec, specific exceptions are listed for certain 
 kinds of errors.  In some cases, a different exception is thrown (each case 
 will be added as a subtask).  Either the specification or the implementation 
 should be updated.

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


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

[jira] Created: (TUSCANY-1433) Exceptions not of the correct kind

Exceptions not of the correct kind
--

 Key: TUSCANY-1433
 URL: https://issues.apache.org/jira/browse/TUSCANY-1433
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SDO-beta1
Reporter: Kelvin Goodson
Priority: Minor


TUSCANY-578 was a bucket defect for exceptions.  Three of the issues detailed 
there are carried over to this defect.  They are marked in the 
ExpectedExceptionsTestCase created for TUSCANY-578 by a comment // Not fixed in 
Tuscany-578 and are commented out.

-- 
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: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes


The alternative is for us to develop SCA Head against a stable (M3)
version of SDO?

On 13/07/07, Pete Robbins [EMAIL PROTECTED] wrote:

The SDO HEAD will contain the ongoing development for the 2.1 spec
changes. The branch was created to maintain a stable version as some
of the spec changes will cause instability.

I think ongoing development should continue in HEAD so we do not need
an SCA branch. We just need to ensure that SCA HEAD will compile/run
against SDO HEAD.

What do you think?

Cheers,

On 13/07/07, Brady Johnson [EMAIL PROTECTED] wrote:
 Hello all,

 I understand there is an SDO branch created for the SDO 2.1 spec
 compliance changes. The SCA code also needs changes made for the SDO
 changes, so can we just make an SCA branch where those changes can be
 made.

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




--
Pete




--
Pete

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

Re: [jira] Created: (TUSCANY-1431) DAS with XQuery based data access support


Thanks Amita

  Also, let's try to work as the Matthieu is doing with the BPEL/ODE
extension, and create multiple jiras for this task, and have small
patches for each jira. This makes things easier to understand, and
help while applying the patches.

On 7/13/07, Amita Vadhavkar (JIRA) tuscany-dev@ws.apache.org wrote:

DAS with XQuery based data access support
-

 Key: TUSCANY-1431
 URL: https://issues.apache.org/jira/browse/TUSCANY-1431
 Project: Tuscany
  Issue Type: New Feature
  Components: Java DAS XQuery
Affects Versions: Java-DAS-Next
Reporter: Amita Vadhavkar


place for submitting incremental patches for the ground work of XQuery DAS

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





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

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

RE: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

2007-07-13 Thread David Haney

So SDO HEAD and SCA HEAD will contain changes related to moving the SDO
implementation towards compliance with SDO 2.1?  And SDO will create a
branch (PRE-SDO21 or something similar) from the current code base that
represents the stable pre-SDO 2.1 work?  This sounds good to me.

Will there be ongoing work on the PRE-SDO21 branch (bug fixes,
enhancements etc...)?  If so, do we need a stable SCA branch that builds
against the PRE-SDO21 branch that can take advantage of those changes,
or is it intended just for stand-alone SDO work?

I guess part of my question is whether the M4 release of either SDO or
SCA will be based on the PRE-SDO21 branch, or whether both will be
coming from HEAD.

Thanks.

David.


 -Original Message-
 From: Pete Robbins [mailto:[EMAIL PROTECTED]
 Sent: Friday, July 13, 2007 8:45 AM
 To: tuscany-dev@ws.apache.org
 Subject: Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec
 changes
 
 The SDO HEAD will contain the ongoing development for the 2.1 spec
 changes. The branch was created to maintain a stable version as some
 of the spec changes will cause instability.
 
 I think ongoing development should continue in HEAD so we do not need
 an SCA branch. We just need to ensure that SCA HEAD will compile/run
 against SDO HEAD.
 
 What do you think?
 
 Cheers,
 
 On 13/07/07, Brady Johnson [EMAIL PROTECTED] wrote:
  Hello all,
 
  I understand there is an SDO branch created for the SDO 2.1 spec
  compliance changes. The SCA code also needs changes made for the SDO
  changes, so can we just make an SCA branch where those changes can
be
  made.
 
  
  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]


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

Re: Website ACL


I was referring to the following paragraph...

a CLA is required for cover substantial contributions for source. therefore
wiki karma must only be granted those with a CLA.

Robert also says later on :

a committer is essentially a developer with a CLA 

If we have control to who gets access, and we are covered, on the
legal aspects, by having the CLA in place, we should be Ok.  What are
your concerns here ?

The other two alternatives I see are :

  - Make wiki patches, or copies from ocpy of the website wiki
  - Make all website contributors a Tuscany committer

Thoughts ? Suggestions ?

On 7/13/07, ant elder [EMAIL PROTECTED] wrote:

I'm not sure I follow how it gets from the reply at [1] to giving any old
person with a CLA on file write access to our website?

i'm not sure that policy is required: just an understanding and application
of the usual apache process...documentation is as important as code. both
are source and the same rulesapply. provenance needs to be established and
oversight maintained.

That to me says you need to be a committer.  Fine to give anyone with a CLA
on file who asks write access to the separate TUSCANYWIKI space but I think
the actual project website needs to be more controlled than that.

   ...ant

On 7/10/07, Luciano Resende [EMAIL PROTECTED] wrote:

 Based on the following discussion on Apache General [1], I'd like to
 give Website write permissions to members of the community that have a
 CLA on file [2].

 Thoughts ?

 [1]
 http://www.mail-archive.com/general%40incubator.apache.org/msg14391.html
 [2] http://people.apache.org/~jim/committers.html

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






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

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

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes


Any M4 should be based on HEAD. The pre-sdo21 branch exists here
https://svn.apache.org/repos/asf/incubator/tuscany/branches/sdo-cpp-pre2.1and
will get bug fixes applied on request. The main user of this is the
PHP SDO-SCA group who need fixes to SDO but not the instability as we
move forward towards a 2.1 compatible version. I do not forsee a
release being built from the branch.

I'm reluctant to create a branch if we can do without it. As I say the
SDO branch is there to support a group who are actively using the
code. I think the stable SCA is M3. If someone needs fixes in M3 but
does not want to use the HEAD version then we may need to consider a
maintenance branch.


On 13/07/07, David Haney [EMAIL PROTECTED] wrote:

So SDO HEAD and SCA HEAD will contain changes related to moving the SDO
implementation towards compliance with SDO 2.1?  And SDO will create a
branch (PRE-SDO21 or something similar) from the current code base that
represents the stable pre-SDO 2.1 work?  This sounds good to me.

Will there be ongoing work on the PRE-SDO21 branch (bug fixes,
enhancements etc...)?  If so, do we need a stable SCA branch that builds
against the PRE-SDO21 branch that can take advantage of those changes,
or is it intended just for stand-alone SDO work?

I guess part of my question is whether the M4 release of either SDO or
SCA will be based on the PRE-SDO21 branch, or whether both will be
coming from HEAD.

Thanks.

David.


 -Original Message-
 From: Pete Robbins [mailto:[EMAIL PROTECTED]
 Sent: Friday, July 13, 2007 8:45 AM
 To: tuscany-dev@ws.apache.org
 Subject: Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec
 changes

 The SDO HEAD will contain the ongoing development for the 2.1 spec
 changes. The branch was created to maintain a stable version as some
 of the spec changes will cause instability.

 I think ongoing development should continue in HEAD so we do not need
 an SCA branch. We just need to ensure that SCA HEAD will compile/run
 against SDO HEAD.

 What do you think?

 Cheers,

 On 13/07/07, Brady Johnson [EMAIL PROTECTED] wrote:
  Hello all,
 
  I understand there is an SDO branch created for the SDO 2.1 spec
  compliance changes. The SCA code also needs changes made for the SDO
  changes, so can we just make an SCA branch where those changes can
be
  made.
 
  
  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]


-
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] Can we make an SCA branch for SDO 2.1 spec changes


The current state is that SCA HEAD will only build against the sdo
branch or M3. The minor change was renaming IntegerType to IntType
which I put in the SCA HEAD but then backed out. If everyone agrees
that HEAD SCA should build against HEAD SDO I will re-apply the
change.

Cheers,

--
Pete

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

Re: Website ACL


On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote:


I was referring to the following paragraph...

a CLA is required for cover substantial contributions for source.
therefore
wiki karma must only be granted those with a CLA.



Yes but that doesn't mean that the converse is also true, ie just having a
CLA doesn't give the right to be granted wiki karma.

Robert also says later on :


a committer is essentially a developer with a CLA 



and also that provenance needs to be established and oversight maintained

If we have control to who gets access, and we are covered, on the

legal aspects, by having the CLA in place, we should be Ok.  What are
your concerns here ?



As with the code, it requires more than just having a CLA to be granted
commit access to our SVN.

The other two alternatives I see are :


   - Make wiki patches, or copies from ocpy of the website wiki
   - Make all website contributors a Tuscany committer



+1, both of these seem appropriate to me. People can raise JIRAs and do
proposed updates on the TUSCANYWIKI space, once they've proven themselves we
can vote them in as a website committer just like from code contributions.

  ...ant

Re: Website ACL


My only concern is that, after we restricted access to our wiki, and
started using the process of JIRA or updates on the other wiki space,
the website contributions basically stopped. I think we had only one
JIRA created on this space.

On 7/13/07, ant elder [EMAIL PROTECTED] wrote:



On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote:
 I was referring to the following paragraph...

 a CLA is required for cover substantial contributions for source.
therefore
 wiki karma must only be granted those with a CLA.

Yes but that doesn't mean that the converse is also true, ie just having a
CLA doesn't give the right to be granted wiki karma.



+1


 Robert also says later on :

 a committer is essentially a developer with a CLA 

and also that provenance needs to be established and oversight maintained

 If we have control to who gets access, and we are covered, on the
 legal aspects, by having the CLA in place, we should be Ok.  What are
 your concerns here ?

As with the code, it requires more than just having a CLA to be granted
commit access to our SVN.

 The other two alternatives I see are :

- Make wiki patches, or copies from ocpy of the website wiki
- Make all website contributors a Tuscany committer

+1, both of these seem appropriate to me. People can raise JIRAs and do
proposed updates on the TUSCANYWIKI space, once they've proven themselves we
can vote them in as a website committer just like from code contributions.

   ...ant



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

[jira] Commented: (TUSCANY-1432) Unable to implement helloworld-ws-reference sample with complex types.

2007-07-13 Thread Raymond Feng (JIRA)


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

Raymond Feng commented on TUSCANY-1432:
---

Hi, David.

I have two questions for the test case.

1) Are you using HelloWorldClientTestCase to test the code? 
HelloWorldClientTestCase cannot be compiled as it still takes a simple String 
instead of Name for the getGreetings() call.

2) What's the server side test case that expose the WS?

Thanks,
Raymond

 Unable to implement helloworld-ws-reference sample with complex types.
 --

 Key: TUSCANY-1432
 URL: https://issues.apache.org/jira/browse/TUSCANY-1432
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-M2
 Environment: Windows XP, JDK 1.5.0_11-b03, ant 1.7.0
Reporter: David Haney
 Attachments: helloworld-ws-reference.zip


 I'm attempting to modify the helloworld-ws-reference example so that it is 
 sending a complexType instead of simple types, and am having trouble with an 
 exception that I can't explain.  I wasn't able to find an example of this 
 sort of thing in one of the other samples, so I've been trying to piece 
 together the necessary changes, and I'm guessing I've just missed a step 
 along the way.  
 Here's what I've done so far (all file references are relative to
 installdir/samples/helloworld-ws-reference):
 - Modified the src/main/resources/wsdl/helloworld.wsdl So that the 
 getGreetings operation contains a complexType:
 ...
 element name=getGreetings
   complexType
 sequence
   element name=name type=tns:Name/
 /sequence
   /complexType
 /element
 ...
 complexType name=Name
   sequence
 element name=first type=xsd:string/
 element name=last type=xsd:string/
   /sequence
 /complexType
 ...
 - Next, I code-generated the static SDO types based on the updated WSDL file. 
  I added the following to the root build.xml in order to generate the types 
 (I wasn't able to find the necessary code-generator tools in the SCA 
 distribution, so the following depends on an external SDO distribution 
 specified by the environment variable TUSCANY_SDO.  I used the 
 tuscany-sdo-1.0-incubating-beta1 binary distribution for this test):
 ...
 property environment=env/ 
 target name=codegen depends=init
   java classname=org.apache.tuscany.sdo.generate.XSD2JavaGenerator
 fork=true
 classpath
   pathelement
 path=${env.TUSCANY_SDO}/lib/tuscany-sdo-tools-1.0-incubating-beta1.jar
 /
   pathelement path=${env.TUSCANY_SDO}/lib/common-2.2.2.jar/
   pathelement path=${env.TUSCANY_SDO}/lib/ecore-2.2.2.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/sdo-api-r2.1-1.0-incubating-beta1.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/tuscany-sdo-impl-1.0-incubating-beta1.jar/
 
   pathelement path=${env.TUSCANY_SDO}/lib/ecore-xmi-2.2.2.jar/
   pathelement path=${env.TUSCANY_SDO}/lib/xsd-2.2.2.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/ecore-change-2.2.2.jar/
   pathelement path=${env.TUSCANY_SDO}/lib/codegen-2.2.2.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/codegen-ecore-2.2.2.jar/
 /classpath
 arg value=-targetDirectory/
 arg value=src/main/java/
 arg value=-javapackage/
 arg value=helloworld/
 arg value=src/main/resources/wsdl/helloworld.wsdl/
   /java
 /target
 ...
 - This produced the following files in src/main/java/helloworld:
 getGreetings.java
 getGreetingsResponse.java
 HelloworldFactory.java
 Name.java
 impl/getGreetingsImpl.java
 impl/getGreetingsResponseImpl.java
 impl/HelloworldFactoryImpl.java
 impl/NameImpl.java
 - Once these were in place, I modified HelloWorldService::getGreetings() to 
 take the new Name type:
 ...
 public interface HelloWorldService {
 public String getGreetings(Name name); }
 - and modified HelloWorldServiceComponent::getGreeting() to match:
 ... 
 public String getGreetings(Name name) {
 System.out.println(Called getGreetings);
 return helloWorldService.getGreetings(name);
 }
 - Finally, I modified HelloWorldServiceClient::main() to create a Name 
 instance, and pass it into the getGreetings() call.
 ...
 Name name = HelloworldFactory.INSTANCE.createName();
 name.setFirst(David);
 name.setLast(Haney);
 String value = helloWorldService.getGreetings(name);
 ...
 - Once all of the code changes were in place, I went back to the 
 src/main/resources/helloworldws.composite file, and attempted to update it so 
 that it would recognize that it should be using the SDO binding:
 dbsdo:import.sdo
   xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
   factory=helloworld.HelloworldFactory/
 - That seemed like it should be sufficient based on the 
 documentation/tests/demos/examples that I was able to find, however when I

Re: SDO dependencies in implementation-das and implementation-data

2007-07-13 Thread Raymond Feng


Hi,

This is the transitive dependency support by maven. IMO, duplicating the SDO 
dependency might lead to inconsistent versions for SDO and DAS unless we 
need to use a different version of SDO other than the one used by a given 
DAS version.


Thanks,
Raymond

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

To: tuscany-dev@ws.apache.org
Sent: Friday, July 13, 2007 7:29 AM
Subject: SDO dependencies in implementation-das and implementation-data



I was looking through the Java SCA trunk for dependencies on SDO.
Both implementation-das and implementation-data use commonj.sdo APIs,
but they don't declare an SDO dependency in their poms.  This happens
to work out because the tuscany-das-rdb dependency pulls in the SDO
dependency.  Should the SDO dependency be declared directly rather
than pulled in indirectly in this way?

  Simon



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




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

RE: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

2007-07-13 Thread Brady Johnson


There are 2 options here:

1. Make the sdo spec 2.1 changes in SDO head and SCA head. This will
cause SCA head to not compile with SDO M3.

2. Make the sdo spec 2.1 changes in an SDO branch and an SCA branch,
thus allowing SCA head to compile with SDO M3. Then a merge will have to
be done at some point to get the changes into M4.

The deciding factor is whether or not we ALWAYS want SCA head to compile
with SDO M3. IMO I don't think this is necessary. It should be
understood that the SVN Head is changing and that it may not always
compile 100% with previous releases (M3). If someone wants to compile
the source code, get either:
SDO M3 and SCA M3
-- Or --
SDO SVN Head and SCA SVN Head 
(efforts should be made that these 2 compile together as often
as possible, if not always)

That said, I vote for option 1.


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


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 13, 2007 10:42 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec
changes

The current state is that SCA HEAD will only build against the sdo
branch or M3. The minor change was renaming IntegerType to IntType which
I put in the SCA HEAD but then backed out. If everyone agrees that HEAD
SCA should build against HEAD SDO I will re-apply the change.

Cheers,

--
Pete

-
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: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

2007-07-13 Thread Justin Thomas \(Contractor\)

I'm also in favor of option 1.  It seems the most logical way to handle
things.


Justin Thomas
Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 13, 2007 11:42 AM
To: tuscany-dev@ws.apache.org
Subject: RE: [SCA Native] Can we make an SCA branch for SDO 2.1 spec
changes


There are 2 options here:

1. Make the sdo spec 2.1 changes in SDO head and SCA head. This will
cause SCA head to not compile with SDO M3.

2. Make the sdo spec 2.1 changes in an SDO branch and an SCA branch,
thus allowing SCA head to compile with SDO M3. Then a merge will have to
be done at some point to get the changes into M4.

The deciding factor is whether or not we ALWAYS want SCA head to compile
with SDO M3. IMO I don't think this is necessary. It should be
understood that the SVN Head is changing and that it may not always
compile 100% with previous releases (M3). If someone wants to compile
the source code, get either:
SDO M3 and SCA M3
-- Or --
SDO SVN Head and SCA SVN Head 
(efforts should be made that these 2 compile together as often
as possible, if not always)

That said, I vote for option 1.


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


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Friday, July 13, 2007 10:42 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec
changes

The current state is that SCA HEAD will only build against the sdo
branch or M3. The minor change was renaming IntegerType to IntType which
I put in the SCA HEAD but then backed out. If everyone agrees that HEAD
SCA should build against HEAD SDO I will re-apply the change.

Cheers,

--
Pete

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


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

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes


On 13/07/07, Brady Johnson [EMAIL PROTECTED] wrote:


There are 2 options here:

1. Make the sdo spec 2.1 changes in SDO head and SCA head. This will
cause SCA head to not compile with SDO M3.

2. Make the sdo spec 2.1 changes in an SDO branch and an SCA branch,
thus allowing SCA head to compile with SDO M3. Then a merge will have to
be done at some point to get the changes into M4.

The deciding factor is whether or not we ALWAYS want SCA head to compile
with SDO M3. IMO I don't think this is necessary. It should be
understood that the SVN Head is changing and that it may not always
compile 100% with previous releases (M3). If someone wants to compile
the source code, get either:
   SDO M3 and SCA M3
-- Or --
   SDO SVN Head and SCA SVN Head
   (efforts should be made that these 2 compile together as often
as possible, if not always)

That said, I vote for option 1.



+1



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


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Friday, July 13, 2007 10:42 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec
changes

The current state is that SCA HEAD will only build against the sdo
branch or M3. The minor change was renaming IntegerType to IntType which
I put in the SCA HEAD but then backed out. If everyone agrees that HEAD
SCA should build against HEAD SDO I will re-apply the change.

Cheers,

--
Pete

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

Re: [SDO Java DISCUSS] Contents of the next SDO release

2007-07-13 Thread David Adcox

Kelvin,

I'm a bit late adding this to the pile, but I'd like to see that
T-1428 is included in the 1.0 release. The changes are somewhat small
and making the change now will reduce headaches down the road.

On 6/11/07, kelvin goodson [EMAIL PROTECTED] wrote:

Good suggestion Steffen. If you were able to open a Jira and dump into it
any thoughts you may have had about the details of how you see this working
that would be great. The more detail you put there, the more likely it is
that someone who wants to get their hands dirty would be likely to pick it
up; unless of course you have plans for doing it yourself. As an aside,
it's always interesting to know the background to why a particular feature
is important to someone, so if you felt like commenting on your scenarios
that would benefit from this too, whether in the JIRA on or the list, that
would be great.

For my part here are the things that I'd like to see done ...
- reorganisation of the build to create release distributions in line with
the SCA release format
- review and improvement of the samples and implementation of an alternative
simple approach to running the samples that does not involve running a maven
build
- review and improvement of the website documentation

In addition, some things I'd like to see being done, but I don't see as
absolute prerequisites for a release are ...
- creation of a further sdo sub-project that permits automated exercising of
the sdo plugin and java generator
- more test cases

In terms of JIRA's, we currently have 3 marked for the specific release
[1], rather then the generic Java-SDO-Next bucket [2] that is the
placeholder for Jiras not assigned to a release.
TUSCANY-1317 http://issues.apache.org/jira/browse/TUSCANY-1317,
TUSCANY-1143 http://issues.apache.org/jira/browse/TUSCANY-1143 ,
TUSCANY-513 http://issues.apache.org/jira/browse/TUSCANY-513

The first is there because the originator marked it for the beta1, which it
didn't make, but it looks well defined, so after the beta1 I changed the
fix release to the 1.0 release, but I don't think I'll have the bandwidth to
cover this.
The second is there because I want it to be, and plan to tackle it.
The third is there because the originator has provided a patch and I'm in
the process of committing it.

In the light of my priorities above, having taken a scan through [2] in
addition to 1143, I plan to look at ...

TUSCANY-1122TypeConversionTestCase fails for JDK 1.4.2
TUSCANY-1127ObtainingDataGraphFromXml, and maybe other samples,
incorrectly accessing xsd:any content
TUSCANY-1284Manifest version number in Java SDO Impl and Tools jars
TUSCANY-257recently added file Interface2JavaGenerator.java is not
compatible with JDK 1.4

and there are a few others I have my eye on, e.g. 303, if all the above
goes well.

Regards, Kelvin.

[1]
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=1status=3status=4component=12311542component=12310660component=12310973component=12310802fixfor=12312521sorter/field=issuekeysorter/order=DESC
[2]
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=1status=3status=4component=12310660component=12310973component=12310802fixfor=12312262sorter/field=issuekeysorter/order=DESC

On 09/06/07, Steffen Glomb [EMAIL PROTECTED] wrote:

i would like to see support for typesafe collections in the xsd2java
generator.

regards
Steffen

On 6/8/07, kelvin goodson [EMAIL PROTECTED] wrote:

I'd like to draw the communities attention to this issue again please.
Thanks to David for responding with his requirements and with the fix
for
1223. I have some thoughts that I'm structuring at the moment on what's
important for a next release from my perspective that I'll post
soon, but
in general I'm just keen to get the good stuff that we have added
recently
out in a release that, as I said before from my perspective, warrants
the
title of 1.0. With the Summer holiday season coming up, I'd like to
do
this soon so that I can sun myself on a beach without that niggling
feeling
of things that ought to have been done ;-)

What say you we put a stake in the ground of aiming for a SDO 1.0release to
be at the IPMC ratification stage by mid-July?

So to that end I ask again, if you have requirements that you feel are
fundamental to the next release please raise them now; with the caveat
of
course that the only way to be sure of getting your requirements into
the
release is to step forward and supply the fixes.

--
Kelvin.

On 23/05/07, David Adcox [EMAIL PROTECTED] wrote:

Kelvin,

I would like to see the multiple namepace issue resolved in the
XSD2JavaGenerator tool. This issue is covered in JIRA 1223.
Optionally, making it available to the plugin (JIRA 303) would be
nice. JIRA 1143 is something that I need fixed, as well. So any
focus that can be given to that prior to this release

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes


I have applied a change (revision 556081). Now SCA HEAD requires SDO HEAD.

Cheers,

--
Pete

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

[jira] Resolved: (TUSCANY-1380) DataObjectListTest.testGetInvalidInstanceProperty is invalid

2007-07-13 Thread Frank Budinsky (JIRA)


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

Frank Budinsky resolved TUSCANY-1380.
-

Resolution: Fixed

I changed aaa[1] to nonexistentProperty in revision 556085.

 DataObjectListTest.testGetInvalidInstanceProperty is invalid
 

 Key: TUSCANY-1380
 URL: https://issues.apache.org/jira/browse/TUSCANY-1380
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove
 Fix For: Java-SDO-CTS-Next


 The following callin DataObjectListTest.testGetInvalidInstanceProperty  is 
 invalid because getInstanceProperty() is not intended to work with xpath 
 expressions, just property names.
 testObj.getInstanceProperty(aaa[1]);
 I don't have committer rights yet. Could someone please mark this test 
 @Ignore for the moment.
 Thanks.

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


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

[jira] Commented: (TUSCANY-1432) Unable to implement helloworld-ws-reference sample with complex types.

2007-07-13 Thread David Haney (JIRA)


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

David Haney commented on TUSCANY-1432:
--

1) I haven't been using the test case.  I've been running the client 
application via the ant run command.

2) I haven't implemented the server side at the moment.  The client is sending 
it's request to a proxy, and I'm mainly just attempting to verify that the SOAP 
message is formatted correctly.  Once I get the reference side working as 
expected, I planned to modify the helloworld-ws-service to match.  

Thanks for looking into this.

David.

 Unable to implement helloworld-ws-reference sample with complex types.
 --

 Key: TUSCANY-1432
 URL: https://issues.apache.org/jira/browse/TUSCANY-1432
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-M2
 Environment: Windows XP, JDK 1.5.0_11-b03, ant 1.7.0
Reporter: David Haney
 Attachments: helloworld-ws-reference.zip


 I'm attempting to modify the helloworld-ws-reference example so that it is 
 sending a complexType instead of simple types, and am having trouble with an 
 exception that I can't explain.  I wasn't able to find an example of this 
 sort of thing in one of the other samples, so I've been trying to piece 
 together the necessary changes, and I'm guessing I've just missed a step 
 along the way.  
 Here's what I've done so far (all file references are relative to
 installdir/samples/helloworld-ws-reference):
 - Modified the src/main/resources/wsdl/helloworld.wsdl So that the 
 getGreetings operation contains a complexType:
 ...
 element name=getGreetings
   complexType
 sequence
   element name=name type=tns:Name/
 /sequence
   /complexType
 /element
 ...
 complexType name=Name
   sequence
 element name=first type=xsd:string/
 element name=last type=xsd:string/
   /sequence
 /complexType
 ...
 - Next, I code-generated the static SDO types based on the updated WSDL file. 
  I added the following to the root build.xml in order to generate the types 
 (I wasn't able to find the necessary code-generator tools in the SCA 
 distribution, so the following depends on an external SDO distribution 
 specified by the environment variable TUSCANY_SDO.  I used the 
 tuscany-sdo-1.0-incubating-beta1 binary distribution for this test):
 ...
 property environment=env/ 
 target name=codegen depends=init
   java classname=org.apache.tuscany.sdo.generate.XSD2JavaGenerator
 fork=true
 classpath
   pathelement
 path=${env.TUSCANY_SDO}/lib/tuscany-sdo-tools-1.0-incubating-beta1.jar
 /
   pathelement path=${env.TUSCANY_SDO}/lib/common-2.2.2.jar/
   pathelement path=${env.TUSCANY_SDO}/lib/ecore-2.2.2.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/sdo-api-r2.1-1.0-incubating-beta1.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/tuscany-sdo-impl-1.0-incubating-beta1.jar/
 
   pathelement path=${env.TUSCANY_SDO}/lib/ecore-xmi-2.2.2.jar/
   pathelement path=${env.TUSCANY_SDO}/lib/xsd-2.2.2.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/ecore-change-2.2.2.jar/
   pathelement path=${env.TUSCANY_SDO}/lib/codegen-2.2.2.jar/
   pathelement
 path=${env.TUSCANY_SDO}/lib/codegen-ecore-2.2.2.jar/
 /classpath
 arg value=-targetDirectory/
 arg value=src/main/java/
 arg value=-javapackage/
 arg value=helloworld/
 arg value=src/main/resources/wsdl/helloworld.wsdl/
   /java
 /target
 ...
 - This produced the following files in src/main/java/helloworld:
 getGreetings.java
 getGreetingsResponse.java
 HelloworldFactory.java
 Name.java
 impl/getGreetingsImpl.java
 impl/getGreetingsResponseImpl.java
 impl/HelloworldFactoryImpl.java
 impl/NameImpl.java
 - Once these were in place, I modified HelloWorldService::getGreetings() to 
 take the new Name type:
 ...
 public interface HelloWorldService {
 public String getGreetings(Name name); }
 - and modified HelloWorldServiceComponent::getGreeting() to match:
 ... 
 public String getGreetings(Name name) {
 System.out.println(Called getGreetings);
 return helloWorldService.getGreetings(name);
 }
 - Finally, I modified HelloWorldServiceClient::main() to create a Name 
 instance, and pass it into the getGreetings() call.
 ...
 Name name = HelloworldFactory.INSTANCE.createName();
 name.setFirst(David);
 name.setLast(Haney);
 String value = helloWorldService.getGreetings(name);
 ...
 - Once all of the code changes were in place, I went back to the 
 src/main/resources/helloworldws.composite file, and attempted to update it so 
 that it would recognize that it should be using the SDO binding:
 dbsdo:import.sdo
   xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
   factory=helloworld.HelloworldFactory/

[jira] Created: (TUSCANY-1434) DAS.applyChanges() does not initialize database connection if needed

2007-07-13 Thread Ron Gavlin (JIRA)

DAS.applyChanges() does not initialize database connection if needed


 Key: TUSCANY-1434
 URL: https://issues.apache.org/jira/browse/TUSCANY-1434
 Project: Tuscany
  Issue Type: Bug
  Components: Java DAS RDB
Affects Versions: Java-DAS-beta1
Reporter: Ron Gavlin


I am attempting to use das.applyChanges() to insert a row into the CUSTOMER 
table. My augmented basicCustomerMappingWithCUD2.xml file includes a 
ConnectionInfo element with a datasource attribute specified. Note below 
that I am using static SDO without invoking the standard priming 
das.getCommand(command).executeQuery() before invoking das.applyChanges(). 
When I execute the following code snippet, I receive an error in 
das.applyChanges() that there is no database connection currently open.

DAS das = 
DAS.FACTORY.createDAS(getConfig(basicCustomerMappingWithCUD2.xml));
DataGraph dg = SDOUtil.createDataGraph();
dg.getChangeSummary().beginLogging();
dg.createRootObject(TypeHelper.INSTANCE.getType(Customers.class));
Customers customers = (Customers) dg.getRootObject();
Customer customer = CustomerFactory.INSTANCE.createCustomer();
customer.setID();
customer.setLASTNAME(Jones);
customers.getCustomer().add(customer);

// FIXME the following line is required to workaround this DAS bug  
// whereby no connection exists w/out a priming 
getCommand().executeQuery()
// Note that the following line should be removed in this test code 
after the patch for this bug is applied
((DASImpl) das).getConnection();
// end of FIXME
  
das.applyChanges((DataObject) customers);


The proposed patch for this bug is as follows:


org.apache.tuscany.das.rdb.impl.DASImpl.class

Change line 114 FROM

Line 107
/*
 * (non-Javadoc)
 * 
 * @see org.apache.tuscany.das.rdb.CommandGroup#getApplyChangesCommand()
 */
public ApplyChangesCommandImpl getApplyChangesCommand() {
ApplyChangesCommandImpl cmd = new 
ApplyChangesCommandImpl(configWrapper, connection); // Line 114
return cmd;
}

TO

Line 107
/*
 * (non-Javadoc)
 * 
 * @see org.apache.tuscany.das.rdb.CommandGroup#getApplyChangesCommand()
 */
public ApplyChangesCommandImpl getApplyChangesCommand() {
ApplyChangesCommandImpl cmd = new 
ApplyChangesCommandImpl(configWrapper, getConnection()); //Line 114
return cmd;
}

FYI, the customer.xsd for this test was augmented to include the Customers 
complex type as follows:

xsd:complexType name=Customers
   xsd:sequence
  xsd:element name=customer type=Customer maxOccurs=unbounded /
   /xsd:sequence
/xsd:complexType

Let me know if you have questions.

- Ron



-- 
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: SCA Toys?


I've added the patch for TUSCANY-1423 into tuscany/cpp/sca/tools now
that I have moved the scagen tool to the cpp extension.

I have not added this source into the build. We can use this tree to
see how the ant build works???

Cheers,

On 12/07/07, Pete Robbins [EMAIL PROTECTED] wrote:

I'm thinking this should go in cpp/sca/tools. Currently we have the
scagen tool in that folder but I've been meaning to move that to
cpp\sca\runtime\extensions\cpp\tools for some time now as it is really
part of the C++ language extension.

Cheers,

On 11/07/07, Brady Johnson [EMAIL PROTECTED] wrote:

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

 I also uploaded a patch, so its ready for some kindly commiter to submit
 it.

 FYI, the -model option doesn't work yet, since its depending on
 functionality to be added with:
https://issues.apache.org/jira/browse/TUSCANY-1422

 Thanks

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


 -Original Message-
 From: Pete Robbins [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, July 11, 2007 2:00 PM
 To: tuscany-dev@ws.apache.org
 Subject: Re: SCA Toys?

 Nice!

 please attach a patch to a Jira and I'll test/commit it.

 Cheers,

 On 11/07/07, Brady Johnson [EMAIL PROTECTED] wrote:
 
  I havent seen much posted about this lately.
 
  I have a toy for TuscanySCA C++ that will use the SCARuntime to load

  a service and dump out pertinent information. Also, if there are any
  failures, it will dump that to stderr as well.
 
  See below for a sample output with the CppBigBank service:
 
  After looking at the svn structure, maybe the best place for it would
  be:
 
  cpp/sca/toys
 
  If anyone thinks this would be useful, I'll attach the code and
  someone can submit it for me.
 
  Thanks
 
  
  Brady Johnson
  Lead Software Developer - HydraSCA
  Rogue Wave Software - [EMAIL PROTECTED]
 
 
  [EMAIL PROTECTED] bin]$ ./tuscanyServiceChecker -ir ${TUSCANY_SCACPP}

  -sr ${TUSCANY_SCACPP}/samples/CppBigBank/deploy
  Included composite: bigbank.app
 WSDL namespace: http://www.bigbank.com/AccountService
 PortType: AccountService
 Operation Info:
 OperationName: getAccountReport
 SOAP Action:
  http://www.bigbank.com/AccountService/getAccountReport
 Endpoint:
  http://localhost:9090/axis2/services/bigbank.AccountManagementComponen
  t/
  AccountService
 SOAP version:  0
 Document Style:1
 Wrapped Style: 1
 In Encoded Style:  0
 Out Encoded Style: 0
 InputMsgURI:
  http://www.bigbank.com/AccountService
 InputMsgName:
  getAccountReportRequest
 OutputMsgURI:
  http://www.bigbank.com/AccountService
 OutputMsgName:
  getAccountReportResponse
 Input Message Part:
  Name: getAccountReportRequest
  Type: getAccountReport
  URI:
  http://www.bigbank.com/AccountService
 Output Message Part:
  Name: getAccountReportResponse
  Type: getAccountReportResponse
  URI:
  http://www.bigbank.com/AccountService
 WSDL namespace: http://www.webserviceX.NET/
 PortType: StockQuoteSoap
 Operation Info:
 OperationName: GetQuote
 SOAP Action:
  http://www.webserviceX.NET/GetQuote
 Endpoint:
  http://www.webservicex.net/stockquote.asmx
 SOAP version:  0
 Document Style:1
 Wrapped Style: 1
 In Encoded Style:  0
 Out Encoded Style: 0
 InputMsgURI:
  http://www.webserviceX.NET/
 InputMsgName:  GetQuoteSoapIn
 OutputMsgURI:
  http://www.webserviceX.NET/
 OutputMsgName: GetQuoteSoapOut
 Input Message Part:
  Name: parameters
  Type: GetQuote
  URI:
  http://www.webserviceX.NET/
 Output Message Part:

[jira] Updated: (TUSCANY-1143) Generated code should separate metadata creation from registration to permit proper scoping

2007-07-13 Thread David T. Adcox (JIRA)

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

David T. Adcox updated TUSCANY-1143:

Attachment: 1143.patch

I have incorporate Kelvin's thoughts into this latest patch. The
FactoryInterface.INSTANCE is now used as the means of retrieving the dependent
factory instances in metadata initialization. This enabled me to move the
initializesMetadata back down into the init() method. This also meant that I
could remove the scope from being stored in the factory.

Generated code should separate metadata creation from registration to permit
proper scoping
---

Attachments: 1143.patch, 1143.patch

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

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

[jira] Commented: (TUSCANY-1397) createDataObject() throws NPE if property does not exist

2007-07-13 Thread Fuhwei Lwo (JIRA)


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

Fuhwei Lwo commented on TUSCANY-1397:
-

I cannot seem to locate the spec definition of return value of 
DataObject.createDataObject(invalidProperty) method if an invalid property was 
passed in. If that's the case, the best we can do is to return null DataObject 
without throwing NPE. The only difference this solution makes is the users 
either check for NPE or null.

Current:
try {
DataObject child = parent.createDataObject(invalidProperty);
}
catch (NullPoinerException e) {
// Instance property (open type or not) doesn't exist
}

New:
DataObject child = parent.createDataObject(invalidProperty);
if (child == null) {
// Instance property (open type or not) doesn't exist
}

I also cannot find in the spec that createDataObject() needs to demand-create 
the instance property only DataObject.set() does. Beside that, I don't think we 
have enough information to determine the HelperContext (scope) of this new 
instance property.

 createDataObject() throws NPE if property does not exist
 

 Key: TUSCANY-1397
 URL: https://issues.apache.org/jira/browse/TUSCANY-1397
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Reporter: Andy Grove

 Calling createDataObject( foo ) where the data object's type does not 
 define a property foo causes a null pointer exception in 
 DataObjectUtil.createDataObject(DataObject dataObject, Property property, 
 Type type) because it attempts to call property.isContainment without 
 checking if the property is null.
 Calling createDataObject( foo ) on an open type should create an on-demand 
 property. If the type is not open and the property does not exist then an 
 exception should be thrown.
 Thanks,
 Andy.

-- 
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-1421) XMLHelper.save on root object of DataGraph gives serialization of href=root.xml#/

2007-07-13 Thread Frank Budinsky (JIRA)


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

Frank Budinsky resolved TUSCANY-1421.
-

Resolution: Fixed

Fixed in revision 556147.

 XMLHelper.save on root object of DataGraph gives serialization of 
 href=root.xml#/
 ---

 Key: TUSCANY-1421
 URL: https://issues.apache.org/jira/browse/TUSCANY-1421
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
Reporter: Kelvin Goodson

 There's an issue reported on the user list ...
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200707.mbox/[EMAIL 
 PROTECTED]
 which relates to a some missing logic in XMLDocumentImpl's save method
 The precondition for hitting this issue is when the data object is the root 
 data object of a DataGraph.  In this case the eContainer of the root object 
 is null,  but the root object is contained in a resource.  We need to 
 replicate the unhooking and replacing behaviour that exists for the container 
 of the data object for the case where the data object is directly contained 
 in a resource.

-- 
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-1391) Provide capability to load and save XML with unknown features

2007-07-13 Thread Fuhwei Lwo (JIRA)


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

Fuhwei Lwo updated TUSCANY-1391:


Attachment: 1391.patch

Amita,

I have reviewed and cleaned up the code with unneeded comments. I have also 
recompiled the whole java/sdo project and run the test. Everything looks fine 
to me. The only improvement I can think of for the future is to well define the 
content of returned unknown properties in SDO terms instead of EMF. Please 
review the new patch I uploaded to make sure I didn't miss anything. Thanks.

 Provide capability to load and save XML with unknown features
 -

 Key: TUSCANY-1391
 URL: https://issues.apache.org/jira/browse/TUSCANY-1391
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Reporter: Amita Vadhavkar
 Attachments: 1391.patch, 1391.patch, 1391.patch, 1391.patch, 
 JIRA1391Design.txt, JIRA1391Design.txt


 expose XMLResource.OPTION_RECORD_UNKNOWN_FEATURE through tuscany-sdo-impl

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

[LDAP DAS] Restoring non-containment references?

2007-07-13 Thread Ole Ersoy


Hey Guys,

I'm working on the approach for restoring the non-containment references.  I'm 
thinking I should do it like this:

First restore the entire graph with all containment references.  For each 
object restored add it and it's xpath fragment to a map.  Then during a second 
pass process each object's non-containment reference by looking up the object 
being referenced by fragment path using the map, and setting the reference that 
way. (So during the first pass, I just create annotations containing the xpath 
to the non-containment reference's object keyed by the name of the reference.)

Does anyone know of a better way to handle this?

Thanks,
- Ole

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

Re: Adding support for Contribution Import/Export