Re: [DAS] DAS & SDO

[Amita Vadhavkar]

Please check patch for JIRA-961. A>,B>,C> is the approach followed.

Regards,
Amita

On 8/1/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
>
> A>So far, RDB DAS was doing SDOUtil.createTypeHelper() during each
> construction of GraphBuilderMetadata(GBMD). This was resulting in a new
> instance fo TypeHelper for each new query execution. This is not
> required as the data model used during one runtime of DAS is constant.
>
> B>Using the new SDO APIs, we can do HelperProvider.getDefaultContext
> ().getTypeHelper()
> in this case to consistently use the same TypeHelper instance.
>
> C>Another question is, when a user extends ReadCommandImpl and also
> provide
> a static data model - like in - ReadCustomersStaticTypesCommand from test
> suite,
> and also uses a HelperContext different than DefaultContext to register
> the static Types,
> (please see,
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20743.html),
> then how to make DAS and thus GraphBuiilderMetaData aware of this new
> HelperContext.
> One simple solution will be providing a way through DASImpl to pass the
> helperContext
> to GraphBuilderMetaData, when it is not the DefaultContext.
> BaseCommandImpl,
> can hold ref to HelperContext instance and pass it to GBMD. GBMD will use
> passed
> HelperContext and in its absense will use the default one.
>
> D> Alternative to C> will be mandating user to use DefaultHelperContext?
>
> Please give comments.
>
> Regards,
> Amita
>
> On 7/20/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> > I have started checking the details and will consolidate my findings
> > here.
> >
> > Regards,
> > Amita
> >
> > On 7/20/07, Luciano Resende < [EMAIL PROTECTED]> wrote:
> > >
> > > Hey
> > >
> > >Kelvin gave as some head's up of upcoming changes that might affect
> > > DAS [1] and [2] (Thanks Kelvin). I think there is also a JIRA
> > > regarding integration with latest SDO 2.1 APIs [2] and the usage of
> > > deprecated SDO APIs [4]. It would be great if someone could help on
> > > getting these issues and JIRAs reviewed, and submit patches as needed.
> > >
> > > [1]
> > > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20388.html
> > > [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20369.html
> > >
> > > [3] http://issues.apache.org/jira/browse/TUSCANY-986
> > > [4] http://issues.apache.org/jira/browse/TUSCANY-961
> > >
> > > --
> > > 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] Updated: (TUSCANY-961) DAS: Using deprected SDO method causes Type lookup failure

[Amita Vadhavkar (JIRA)]

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

Amita Vadhavkar updated TUSCANY-961:


Attachment: 961.patch

List of files changed:
*1) DAS
-set/get for helperContext

*2)DasFactory
-2 new createDAS() methods accepting helperContext from caller

*3)GraphBuilderMetaData
-new constructor accepting helperContext
-new SDO methods - createType(), getType(), createProperty(), getProperty(), 
getTypes() 
-using helperContext param improved logic to avoid recreation of existing Types 
and Properties improved logic to avoid numerous TypeHelper creation (old DAS 
has 1 instance/1 read command)

*4)GraphMerger
-new member vars HelperContext and TypeHelper
-new constructor accepting helperContext from caller
-emptyGraph() - uses new SDO methods - createType(), getType(), 
createProperty(), getProperty(), getTypes() using helperContext param

*5)DasFactoryImpl
-impls of 1)

*6)DasImpl
-new member HelperContext, set/get
-DASImpls for 4)
-get/createCommand with setHelperContext() calls.

*7)BaseCommandImpl
-new member helperContext (holds ref from DASImpl), setter/getter
-This approach is followed, so that without DAS, caller can directly set 
helperContext in command.
-This way in a scenario, where say there are multiple database schemas involved 
in a business case and user wants to keep different contexts in SDO/dbms 
schema, he can make sure to pass different context to different commands, based 
on the dbms schemas involved..and so forth.

*8)ReadCommandImpl
-new SDOUtil.createDataGraph()
-new GraphBuilderMetadata() passing helperContext from command

*9)UpdateGenerator
-getUpdateCommand() - used new dataObject.getInstanceProperty()

*10)CompanyTests
-testSimpleStatic() - CompanyFactory registered in context

11)ConverterTests
-CustomerFactory register

*12)ExceptionTests
-CustomerFactory, CompanyFactory register

*13)GraphMergeTests
-diff Type Factory register

*14)TopDown
-diff Type Factory register

*15)SimplestStaticCrud
-testRead() - new way to register context in CustomerFactory

*16)AliaseTests
-added new CustomerData() in setUp() already in JIRA 1464 (under review)

*17)ReadCustomersStaticTypesCommand
-CustomerFactory registered in context in new way

*18)ReadCustomersStaticTypesCommand2 - new test case for passing -HelperContext 
from caller

*19)GeneratedCommandTests.
-testReadCustomersStaticTypes2() for 19)

*20) new Unit Tests - HelperContextTests

*21) DasTest - superclass of all test cases - in setUp() calls 
-HelperProvider.getInstance();
This is required so that each test case gets a clean HelperContext. Otherwise, 
places where column converters are used e.g. there will be a conflict in Type 
of a column (e.g. Customer.ID is int, but in converter test it is long.)
If SDO JIRA-761 is resolved, this approach can be changed and in 
DasTest.setUp(), we can do unregister of required namespaces instead of 
creating new instances of HelperProvider.

*22) AllCommonTests - 
-include HelperContextTests

*23) sample-ajax-das
-DasQueryProcessor.getRSS() , getConverter()- HelperProvider.getInstance() 
added as converters need a clean helper context.

> DAS: Using deprected SDO method causes Type lookup failure
> --
>
> Key: TUSCANY-961
> URL: https://issues.apache.org/jira/browse/TUSCANY-961
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Reporter: Brent Daniel
>Assignee: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
> Attachments: 961.patch
>
>
> The DAS is still using SDOUtil.createTypeHelper() rather than 
> TypeHelper.INSTANCE. This causes the DAS to not have visibility of types 
> defined by TypeHelper or XSDHelper. 

-- 
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: Patch for TUSCANY-1397

[Adriano Crestani]

I've patched the sdo trunk under revision 562325 with the patch Andy
created. All tests ran fine, even though it failed on the tests described on
thread [1], but I these fails have nothing to do with Andy patch, so it's ok
for me ; ). Anyway, I will wait for a new created patch from Andy, once
Fuhwei is saying the actual patch is based on an older version.

[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200708.mbox/browser

Regards,
Adriano Crestani

On 8/2/07, Fuhwei Lwo <[EMAIL PROTECTED]> wrote:
>
> I think the patch is based on an older version of DataObjectUtil.java. Can
> you create a new patch? Thanks.
>
> Adriano Crestani <[EMAIL PROTECTED]> wrote: I may commit it till
> the eod if nobody has no objection ; )
>
> Adriano Crestani
>
> On 8/2/07, Andy Grove  wrote:
> >
> > I've submitted a patch for TUSCANY-1397 and I'd like someone to review
> > this before I apply it since it is my first patch to the Tuscany SDO
> > implementation (I've only been submitting to the CTS until now).
> >
> > The purpose of this patch is to implement on-demand creation of
> > properties in createDataObject().
> >
> > https://issues.apache.org/jira/browse/TUSCANY-1397
> >
> > Thanks,
> >
> > Andy.
> >
>
>

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

[ant elder]

This is a real pity IMHO as it makes the SCDL significantly more
complicated, ugly and error prone, changing this namespace is going to do
nothing to help usability. I know line 2535 in the spec is clear, but the
actual SCA schema supports doing this doesn't it? Could we just ignore line
2535, or propose all the extensions we have as spec proposals, or something,
anything else to avoid this PITA?

At the very least we'll need to hightlight a change like this very clearly
in the release notes and website doc on all the extensions, and ensure
there's a really explicit and helpful error message produced when you get
the namespace wrong.

   ...ant

On 8/2/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> I have reopened the JIRA and will give it a try...
>
> On 8/2/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
> > Folks,
> >
> > I agree with Simon's comment - this resolution violates the SCA spec.
> > You are not supposed to go adding stuff to the SCA namespace that is not
> > approved by the SCA spec process.  In particular, no additions to the
> > sca.xsd or sca-core.xsd are allowed.
> >
> > Yours,  Mike.
> >
> > ant elder (JIRA) wrote:
> > >  [
> https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
> > >
> > > ant elder closed TUSCANY-1053.
> > > --
> > >
> > > Resolution: Fixed
> > >
> > > Closing as it looks like we've standardized on using the SCA namespace
> > >
> > >> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> > >> -
> > >>
> > >> Key: TUSCANY-1053
> > >> URL:
> https://issues.apache.org/jira/browse/TUSCANY-1053
> > >> Project: Tuscany
> > >>  Issue Type: Improvement
> > >>  Components: Java SCA Assembly Model
> > >>Affects Versions: Java-SCA-Next
> > >>Reporter: ant elder
> > >>Assignee: ant elder
> > >> Fix For: Java-SCA-Next
> > >>
> > >>
> > >> Currently Tsucany extensions use SCDL elements is varrious different
> namespaces. There should be a single Tuscany namespace that extensions not
> defined by SCA spec's should use. See
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL 
> PROTECTED]
> > >
> >
> > -
> > 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]
>
>

[jira] Commented: (TUSCANY-1492) Support implemental class not only interface when get a service

[wangfeng (JIRA)]

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

wangfeng commented on TUSCANY-1492:
---

Thank Raymond for applying the patch.

> Support implemental class not only interface when get a service
> ---
>
> Key: TUSCANY-1492
> URL: https://issues.apache.org/jira/browse/TUSCANY-1492
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.91
> Environment: JDK1.5.09,winXP
>Reporter: wangfeng
>Priority: Minor
> Fix For: Java-SCA-0.91
>
> Attachments: patch.txt, TestCase_Calculator.zip
>
>
> when we get a service,we always generate a proxy on the service by using the 
> jdk proxy class, so we must provide a interface to get a service.
> I provide a patch to remove the control. This patch not only support the 
> interface,but also support the implemental class when getting a service.when 
> the class isn't a interface,using the cglib to generate a proxy  and using 
> jdk proxy when the class is a interface. 

-- 
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: Java SDO failing on tests

[Adriano Crestani]

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

the same result, failing on the same tests :(

Adriano Crestani

On 8/2/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> Hi Adriano
>
>Just a thought, could you try and see if it would work with JDK 1.5x.
>
> On 8/2/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > JDK version:
> > java version "1.6.0_02"
> > Java(TM) SE Runtime Environment (build 1.6.0_02-b06)
> > Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing)
> >
> > maven version: 2.0.7
> >
> > and probably the latest sdo code, downloaded 4 hours ago from
> > /tuscany/java/sdo/
> >
> > Regards,
> > Adriano Crestani
> >
> > On 8/2/07, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > On 8/2/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I've downloaded the SDO from the trunk today and got the following
> > > errors
> > > > when running 'mvn' on /tuscany/sdo/ dir:
> > > >
> > > > Results :
> > > >
> > > > Tests in error:
> > > >   testConversionsFromDate(
> > > > org.apache.tuscany.sdo.test.DateConversionTestCase
> > > > )
> > > >   testConversionsFromDateTime(
> > > > org.apache.tuscany.sdo.test.DateConversionTestCase
> > > > )
> > > >   testConversionsFromDuration(
> > > > org.apache.tuscany.sdo.test.DateConversionTestCase
> > > > )
> > > >   testConversionsFromMonth(
> > > > org.apache.tuscany.sdo.test.DateConversionTestCase)
> > > >   testConversionsFromMonthDay(
> > > > org.apache.tuscany.sdo.test.DateConversionTestCase
> > > > )
> > > >   testConversionsFromYear(
> > > > org.apache.tuscany.sdo.test.DateConversionTestCase
> > > > )
> > > >   testConversionsFromYearMonth(
> > > > org.apache.tuscany.sdo.test.DateConversionTestCas
> > > > e)
> > > >   testConversionsFromYearMonthDay(
> > > > org.apache.tuscany.sdo.test.DateConversionTest
> > > > Case)
> > > >
> > > > Tests run: 189, Failures: 0, Errors: 8, Skipped: 0
> > > >
> > > > [INFO]
> > > >
> 
> > > > [ERROR] BUILD FAILURE
> > > > [INFO]
> > > >
> 
> > > > [INFO] There are test failures.
> > > > [INFO]
> > > >
> 
> > > > [INFO] For more information, run Maven with the -e switch
> > > > [INFO]
> > > >
> 
> > > > [INFO] Total time: 6 minutes 42 seconds
> > > > [INFO] Finished at: Thu Aug 02 10:24:50 GMT-04:00 2007
> > > > [INFO] Final Memory: 10M/34M
> > > > [INFO]
> > > >
> 
> > > >
> > > >
> > > >
> > > > Anyone else getting these errors too?
> > > >
> > > > Adriano Crestani
> > > >
> > >
> > > Its building fine for me. As those failures all seem to be date/time
> > > related
> > > i wondered if it was a JDK thing, but i've just tried with several
> JDK's
> > > and
> > > it always works fine. Also building with an empty local mvn repository
> is
> > > working ok for me, so i'm not sure what the problem could be. Are you
> > > definitely on the latest code, and what JDK and mvn version are you
> using?
> > >
> > >...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]
>
>

Re: [VOTE] Release Tuscany Java DAS beta1 (RC3)

[Kevin Williams]

I ran the ComanyWeb and Ajax samples on OS X/Tomcat 6 and both ran
fine.  I think the Ajax example could be changed a bit to be more
intuitive.  For example, it is not clear what is happening with the
OCC example.  The Adhoc query example looks good but the Converter
exercise is confusing; mainly because it is a direct exposure of a
test case that was a bit contrived.

Another possible simplification would be to have the two samples share
the same database.  This would save the user a bit of required
configuration.

Nice job on the release.

+1

On 7/30/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> Please vote to release the beta1 distribution of Tuscany DAS for Java.
> All the major issues reported in RC1 and RC2 should now be fixed.
>
> The Release Candidate RC3 for Tuscany Java DAS beta1 is available at
>
> http://people.apache.org/~lresende/tuscany/das-beta1-rc3/
>
> Release Notes are available at
>
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/distribution/binary/RELEASE_NOTES
>
> The maven repository artifacts are posted in a staging repository and
> is available at
>
> http://people.apache.org/~lresende/tuscany/das-beta1-rc3/maven/
>
> The release audit tool (rat) results are available at
>
> http://people.apache.org/~lresende/tuscany/das-beta1-rc3/das-beta1-rc3-rat.log
>
> The tag for the source code is at
>
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/
>
> Seems OK to me, here is my +1
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

0.91 Memory Footprint

[scyip12]

We recently migrated our version of Tuscany from M2 to 0.91, and we noticed 
that the memory consumption seems to have increased by quite a bit. When doing 
memory profiling, the culprit appeared to be classes related to Xerces DOM 
(DeferredElementNSImpl, several other schema element related classes). When 
profiling the samples (helloworld-ws-sdo-webapp) and our application in M2, 
those classes don't seem to get called. We are going through the jars to 
determine which module is triggering the Xerces parser, but any suggestions 
would be greatly appreciated.

Re: Reference EJB Binding problem

[ant elder]

I suspect a something somewhere is using the wrong class loader, but its
hard to tell precisely where without being able to debug by stepping through
the code. Any chance you could make your code available somewhere (a zip
file in a jira or anywhere?) so we can try it?

   ...ant

On 8/2/07, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have modified the Calculator sample to use an EJB binding for
> addService.
> I have deployed an AddService bean in Geronimo 2.0-SNAPSHOT Tomcat server.
> I am using an EmbeddedSCADomain to run the sample.  I am facing a strange
> problem.  When I run the sample in J2SE environment (I actually modified
> the
> testcase in sca/modules/binding-ejb to run this sample) everything runs
> fine.  I see that the EJB is invoked for AddService.  But when I run this
> sample inside Geronimo using the tuscany-plugin (see
>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integrationfor
> details on the Geronimo Tuscany Integration details), I am getting "
> java.rmi.MarshalException: Unable to create stub for class
> java.lang.Object;
> nested exception is:
> org.omg.CORBA.MARSHAL: Unable to create stub for class java.lang.Object:
> vmcid: Apache minor code: 0x2e completed: No "
>
> Here is the reference ejb binding xml-fragment from
> Calculator-new.composite
>
> 
> 
> 
> 
>
> Here is the session bean definition in ejb-jar.xml:
>   
>  AddService Bean
>  AddServiceBean
>  AddServiceBean
>  calculator.AddServiceHome
>  calculator.AddService
>  calculator.AddServiceLocalHome
>  calculator.AddServiceLocal
>  calculator.AddServiceBean
>  Stateless
>  Container
>   
>
> And the binding in openejb-jar.xml:
>
> 
>   AddServiceBean
>   AddServiceBean
>...
> 
>
>
> Any ideas on what is making the difference in J2SE and J2EE enviroments in
> this context?  Any help in resolving this problem is appreciated.
>
> Thanks and best regards,
> Vamsi
>

[jira] Updated: (TUSCANY-1505) Naming scheme used for variables in code gen factory init() method breaks under specific circumstances

[David T. Adcox (JIRA)]

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

David T. Adcox updated TUSCANY-1505:


Attachment: test1505.zip

Attached is a zip with test materials that will reproduce the problem 
described.  

> Naming scheme used for variables in code gen factory init() method breaks 
> under specific circumstances
> --
>
> Key: TUSCANY-1505
> URL: https://issues.apache.org/jira/browse/TUSCANY-1505
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: test1505.zip
>
>
> A new code gen pattern was recently added to change how dependent packages 
> are initialized in the xxxFactoryImpl.init() method.  Under this new pattern, 
> all dependent packages are initialized via the factoryInterface.INSTANCE 
> method.   An initialization call is made for each dependent gen package.  The 
> getImportedFactoryInterfaceName() is used to retrieve the short name.  This 
> value is mashed with the text 'Instnace' to form a variable name.  If 
> circumstances dictate that multiple packages contain the same factory 
> interface name, the getImportedFactoryInterfaceName() will fully qualify the 
> response instead of using the short name.  This breaks the generated code, 
> due to the use of a '.' in the variable name.

-- 
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-1504) getSequence() returns null with a complexType defined without mixed="true"

[Pete Robbins (JIRA)]

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

Pete Robbins commented on TUSCANY-1504:
---

I believe this is working as per the specification but I will ask for a 
clarification. The spec says:


Element in all, choice, or sequence

<[GROUP] maxOccurs=[G_MAX]>
  


where 
  [GROUP] = all, choice, sequence
•   Element groups and model groups are treated as if they were expanded in 
place.
•   Nested [GROUP]s are expanded.   Property name=[NAME] 
  type=[TYPE] 
  many=true

Type sequenced=true

•   A property is created for every element
•   many=true when E_MAX or G_MAX is > 1
•   sequenced=true if the content allows elements to be interleaved.  (for 
example )
•   sequenced=true if G_MAX > 1 and there is more than one element in this 
group or a contained group.
•   Property declarations are the same whether group is  or  
or 
•   Property behavior ignores group declarations.
•   Validation of DataObjects for the group constraints is external to the 
DataObject interface.
<

The key statements are 
> sequenced=true if the content allows elements to be interleaved.  (for 
> example )
> sequenced=true if G_MAX > 1 and there is more than one element in this group 
> or a contained group.

So in your example neither of these is true as you have a sequence of elements 
with maxOccurs=1 (the default). A "Sequenced DataObject" records the order of 
the settings of the properties when the elements can be interleaved. In your 
example there can only ever be one instance of each property (element) and so 
the sequence in which they were set is not relevent. The properties are defined 
on the Type in the order declared in the sequence so you could access them in 
order by property index.

Cheers,


> getSequence() returns null with a complexType defined without mixed="true"
> --
>
> Key: TUSCANY-1504
> URL: https://issues.apache.org/jira/browse/TUSCANY-1504
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-M3
>Reporter: Matthew Schultz
> Attachments: letter.xsd
>
>
> getSequence returns null if complextType does not have the mixed attribute or 
> the mixed attribute is set to false.  
> Looking at the code, SDOSchemaSAX2Parser::startComplexType and
> SDOSchemaSAX2Parser::defineType appears to be the two places that
> isSequenced is set.  In startComplexType, it appears that both mixed and
> sequence are both treated as an attribute.  I cannot tell if it ever
> reads the child .
> It appears that isSequenced should be set to true on the basis of the
> child  and not on the basis of mixed.

-- 
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-1505) Naming scheme used for variables in code gen factory init() method breaks under specific circumstances

[David T. Adcox (JIRA)]

Naming scheme used for variables in code gen factory init() method breaks under 
specific circumstances
--

 Key: TUSCANY-1505
 URL: https://issues.apache.org/jira/browse/TUSCANY-1505
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
 Environment: n/a
Reporter: David T. Adcox
Priority: Minor
 Fix For: Java-SDO-Next


A new code gen pattern was recently added to change how dependent packages are 
initialized in the xxxFactoryImpl.init() method.  Under this new pattern, all 
dependent packages are initialized via the factoryInterface.INSTANCE method.   
An initialization call is made for each dependent gen package.  The 
getImportedFactoryInterfaceName() is used to retrieve the short name.  This 
value is mashed with the text 'Instnace' to form a variable name.  If 
circumstances dictate that multiple packages contain the same factory interface 
name, the getImportedFactoryInterfaceName() will fully qualify the response 
instead of using the short name.  This breaks the generated code, due to the 
use of a '.' in the variable name.

-- 
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: Patch for TUSCANY-1397

[Fuhwei Lwo]

I think the patch is based on an older version of DataObjectUtil.java. Can you 
create a new patch? Thanks.

Adriano Crestani <[EMAIL PROTECTED]> wrote: I may commit it till the eod if 
nobody has no objection ; )

Adriano Crestani

On 8/2/07, Andy Grove  wrote:
>
> I've submitted a patch for TUSCANY-1397 and I'd like someone to review
> this before I apply it since it is my first patch to the Tuscany SDO
> implementation (I've only been submitting to the CTS until now).
>
> The purpose of this patch is to implement on-demand creation of
> properties in createDataObject().
>
> https://issues.apache.org/jira/browse/TUSCANY-1397
>
> Thanks,
>
> Andy.
>

Re: Build failure in binding-ejb

[Simon Nash]

cglib-nodep is a jar containing all the dependencies of cglib, including
asm.  cglib is a jar that does not include these dependencies.  In all
the other places in Tuscany where cglib is used, the dependency is always
on cglib-nodep, not on cglib.

  Simon

Raymond Feng wrote:

Hi, Simon.

It's strange. I ran a full build and it didn't hit the problem? I aslo 
didn't see a failure report from continuum. It seems to be a bit random. 
BTW, what's the difference between cglib.jar and cglib-nodep.jar? If 
cglib-nodep helps, I'm happy to fix it.


Thanks,
Raymond

- Original Message - From: "Simon Nash" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, August 02, 2007 4:41 AM
Subject: Build failure in binding-ejb



The latest Java SCA trunk doesn't build from a clean checkout because
of a failure building binding-ejb (a NoClassDefFoundError for
org/objectweb/asm/Type).  This was puzzling because there are no
recent changes to binding-ejb.

With a vital clue from Ant, I traced the problem to the recent change
that was made to the pom for implementation-java-runtime as part of
the patch for TUSCANY-1492.  If the recently added dependency in this
file is changed from

cglib
cglib
2.1_3

to

cglib
cglib-nodep
2.1_3

then the build runs OK.

  Simon





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

[jira] Commented: (TUSCANY-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback

[Simon Nash (JIRA)]

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

Simon Nash commented on TUSCANY-1347:
-

The problem is caused by attempting to make a callback through a service 
reference (self-reference).  The current runtime does not support this, and 
needs to be fixed.  In addition to this runtime fix, a change will be needed to 
the test code to use getServiceReference() and setCallback().  I'll post more 
details of this when I have made further progress with the fix.

> IndexOutOfBoundsException thrown when trying to locate a service that 
> includes a callback
> -
>
> Key: TUSCANY-1347
> URL: https://issues.apache.org/jira/browse/TUSCANY-1347
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Embedded Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Assignee: Simon Nash
> Fix For: Java-SCA-Next
>
> Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar
>
>
> More complete description and test case to follow
> Here is the exception thrown...
> [6/14/07 17:59:55:187 MDT] 0020 SystemErr R 
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
>   at java.util.ArrayList.RangeCheck(ArrayList.java:572)
>   at java.util.ArrayList.get(ArrayList.java:347)
>   at 
> org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98)
>   at 
> org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
>   at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

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

[Brady Johnson]

Regarding using LGPL software under ASF licensing:
I understand that the Log4Cxx Apache project uses GNU software, but
doesn't distribute it. So can we just follow their model of not
distributing GNU stuff and requiring users to download it if they want
to run the test suite?


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


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 26, 2007 11:28 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] Test suite

I'm sure this has come up before. I will try and find out what the
resolution was.

On 26/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> As I understand it, the only issue would be if we distribute LPGL 
> software under the ASF licensing. What if we don't distribute CxxTest 
> with Tuscany, but rather request that users download it if they want 
> to run the tests?
>
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
> -Original Message-
> From: Luciano Resende [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 23, 2007 5:01 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] Test suite
>
> I'd recommend checking if there are any issues with it's licensing, a 
> quick look at CxxTest website [1] mention that it's available under 
> LGPL, and that's not ASF friendly.
>
> [1] http://cxxtest.sourceforge.net/
>
> On 7/23/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > I understand that the current TuscanySCA Native test suite is not 
> > maintained. I have tried to use it recently and it doesnt even
> compile.
> > I'd like to start creating a new test suite, starting with the 
> > changes/patches that I've uploaded. Its not real clear what unit 
> > test framework was used, would there be any objections to me using
CxxTest?
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [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]
>
>
> -
> 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]


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

[jira] Updated: (TUSCANY-1462) Consistent use of Parameters in Config

[Luciano Resende (JIRA)]

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

Luciano Resende updated TUSCANY-1462:
-

Fix Version/s: Java-DAS-Next

> Consistent use of Parameters in Config
> --
>
> Key: TUSCANY-1462
> URL: https://issues.apache.org/jira/browse/TUSCANY-1462
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-Next
>Reporter: Amita Vadhavkar
>Assignee: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
>
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19970.html
> Need to followup above mail thread and confirm required changes.

-- 
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-1460) SDO databinding's SDO metadata is scoped in a classloader different from the webapp classloader created by the embedded tomcat (ClassCastException w/ sample-helloworld-s

[Luciano Resende (JIRA)]

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

Luciano Resende updated TUSCANY-1460:
-

Fix Version/s: Java-SCA-Next
 Assignee: Luciano Resende

I'll take a look at this, as I'm working on related area.

> SDO databinding's SDO metadata is scoped in a classloader different from the 
> webapp classloader created by the embedded tomcat (ClassCastException w/ 
> sample-helloworld-sdo)
> 
>
> Key: TUSCANY-1460
> URL: https://issues.apache.org/jira/browse/TUSCANY-1460
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Raymond Feng
>Assignee: Luciano Resende
> Fix For: Java-SCA-Next
>
>
> The embedded Tomcat creates web app classloader for the thread handling the 
> incoming HTTP requests. As a result, the scope for SDO HelperContext is 
> different from the classloader when the SDO metadata is introspected during 
> the contribution processing.
> We probably need a better scoping for SDO metadata than the classloader. 
> Contribution might be used as the key (we can even support import/export).

-- 
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: Java SDO failing on tests

[Luciano Resende]

Hi Adriano

   Just a thought, could you try and see if it would work with JDK 1.5x.

On 8/2/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> JDK version:
> java version "1.6.0_02"
> Java(TM) SE Runtime Environment (build 1.6.0_02-b06)
> Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing)
>
> maven version: 2.0.7
>
> and probably the latest sdo code, downloaded 4 hours ago from
> /tuscany/java/sdo/
>
> Regards,
> Adriano Crestani
>
> On 8/2/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On 8/2/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > I've downloaded the SDO from the trunk today and got the following
> > errors
> > > when running 'mvn' on /tuscany/sdo/ dir:
> > >
> > > Results :
> > >
> > > Tests in error:
> > >   testConversionsFromDate(
> > > org.apache.tuscany.sdo.test.DateConversionTestCase
> > > )
> > >   testConversionsFromDateTime(
> > > org.apache.tuscany.sdo.test.DateConversionTestCase
> > > )
> > >   testConversionsFromDuration(
> > > org.apache.tuscany.sdo.test.DateConversionTestCase
> > > )
> > >   testConversionsFromMonth(
> > > org.apache.tuscany.sdo.test.DateConversionTestCase)
> > >   testConversionsFromMonthDay(
> > > org.apache.tuscany.sdo.test.DateConversionTestCase
> > > )
> > >   testConversionsFromYear(
> > > org.apache.tuscany.sdo.test.DateConversionTestCase
> > > )
> > >   testConversionsFromYearMonth(
> > > org.apache.tuscany.sdo.test.DateConversionTestCas
> > > e)
> > >   testConversionsFromYearMonthDay(
> > > org.apache.tuscany.sdo.test.DateConversionTest
> > > Case)
> > >
> > > Tests run: 189, Failures: 0, Errors: 8, Skipped: 0
> > >
> > > [INFO]
> > > 
> > > [ERROR] BUILD FAILURE
> > > [INFO]
> > > 
> > > [INFO] There are test failures.
> > > [INFO]
> > > 
> > > [INFO] For more information, run Maven with the -e switch
> > > [INFO]
> > > 
> > > [INFO] Total time: 6 minutes 42 seconds
> > > [INFO] Finished at: Thu Aug 02 10:24:50 GMT-04:00 2007
> > > [INFO] Final Memory: 10M/34M
> > > [INFO]
> > > 
> > >
> > >
> > >
> > > Anyone else getting these errors too?
> > >
> > > Adriano Crestani
> > >
> >
> > Its building fine for me. As those failures all seem to be date/time
> > related
> > i wondered if it was a JDK thing, but i've just tried with several JDK's
> > and
> > it always works fine. Also building with an empty local mvn repository is
> > working ok for me, so i'm not sure what the problem could be. Are you
> > definitely on the latest code, and what JDK and mvn version are you using?
> >
> >...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]

Re: Java SDO failing on tests

[Adriano Crestani]

JDK version:
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b06)
Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing)

maven version: 2.0.7

and probably the latest sdo code, downloaded 4 hours ago from
/tuscany/java/sdo/

Regards,
Adriano Crestani

On 8/2/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> On 8/2/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I've downloaded the SDO from the trunk today and got the following
> errors
> > when running 'mvn' on /tuscany/sdo/ dir:
> >
> > Results :
> >
> > Tests in error:
> >   testConversionsFromDate(
> > org.apache.tuscany.sdo.test.DateConversionTestCase
> > )
> >   testConversionsFromDateTime(
> > org.apache.tuscany.sdo.test.DateConversionTestCase
> > )
> >   testConversionsFromDuration(
> > org.apache.tuscany.sdo.test.DateConversionTestCase
> > )
> >   testConversionsFromMonth(
> > org.apache.tuscany.sdo.test.DateConversionTestCase)
> >   testConversionsFromMonthDay(
> > org.apache.tuscany.sdo.test.DateConversionTestCase
> > )
> >   testConversionsFromYear(
> > org.apache.tuscany.sdo.test.DateConversionTestCase
> > )
> >   testConversionsFromYearMonth(
> > org.apache.tuscany.sdo.test.DateConversionTestCas
> > e)
> >   testConversionsFromYearMonthDay(
> > org.apache.tuscany.sdo.test.DateConversionTest
> > Case)
> >
> > Tests run: 189, Failures: 0, Errors: 8, Skipped: 0
> >
> > [INFO]
> > 
> > [ERROR] BUILD FAILURE
> > [INFO]
> > 
> > [INFO] There are test failures.
> > [INFO]
> > 
> > [INFO] For more information, run Maven with the -e switch
> > [INFO]
> > 
> > [INFO] Total time: 6 minutes 42 seconds
> > [INFO] Finished at: Thu Aug 02 10:24:50 GMT-04:00 2007
> > [INFO] Final Memory: 10M/34M
> > [INFO]
> > 
> >
> >
> >
> > Anyone else getting these errors too?
> >
> > Adriano Crestani
> >
>
> Its building fine for me. As those failures all seem to be date/time
> related
> i wondered if it was a JDK thing, but i've just tried with several JDK's
> and
> it always works fine. Also building with an empty local mvn repository is
> working ok for me, so i'm not sure what the problem could be. Are you
> definitely on the latest code, and what JDK and mvn version are you using?
>
>...ant
>

Reference EJB Binding problem

[Vamsavardhana Reddy]

Hi,

I have modified the Calculator sample to use an EJB binding for addService.
I have deployed an AddService bean in Geronimo 2.0-SNAPSHOT Tomcat server.
I am using an EmbeddedSCADomain to run the sample.  I am facing a strange
problem.  When I run the sample in J2SE environment (I actually modified the
testcase in sca/modules/binding-ejb to run this sample) everything runs
fine.  I see that the EJB is invoked for AddService.  But when I run this
sample inside Geronimo using the tuscany-plugin (see
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integrationfor
details on the Geronimo Tuscany Integration details), I am getting "
java.rmi.MarshalException: Unable to create stub for class java.lang.Object;
nested exception is:
org.omg.CORBA.MARSHAL: Unable to create stub for class java.lang.Object:
vmcid: Apache minor code: 0x2e completed: No "

Here is the reference ejb binding xml-fragment from Calculator-new.composite






Here is the session bean definition in ejb-jar.xml:
  
 AddService Bean
 AddServiceBean
 AddServiceBean
 calculator.AddServiceHome
 calculator.AddService
 calculator.AddServiceLocalHome
 calculator.AddServiceLocal
 calculator.AddServiceBean
 Stateless
 Container
  

And the binding in openejb-jar.xml:


  AddServiceBean
  AddServiceBean
   ...



Any ideas on what is making the difference in J2SE and J2EE enviroments in
this context?  Any help in resolving this problem is appreciated.

Thanks and best regards,
Vamsi

Re: Build failure in binding-ejb

[Raymond Feng]

Hi, Simon.

It's strange. I ran a full build and it didn't hit the problem? I aslo 
didn't see a failure report from continuum. It seems to be a bit random. 
BTW, what's the difference between cglib.jar and cglib-nodep.jar? If 
cglib-nodep helps, I'm happy to fix it.


Thanks,
Raymond

- Original Message - 
From: "Simon Nash" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, August 02, 2007 4:41 AM
Subject: Build failure in binding-ejb



The latest Java SCA trunk doesn't build from a clean checkout because
of a failure building binding-ejb (a NoClassDefFoundError for
org/objectweb/asm/Type).  This was puzzling because there are no
recent changes to binding-ejb.

With a vital clue from Ant, I traced the problem to the recent change
that was made to the pom for implementation-java-runtime as part of
the patch for TUSCANY-1492.  If the recently added dependency in this
file is changed from

cglib
cglib
2.1_3

to

cglib
cglib-nodep
2.1_3

then the build runs OK.

  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]

[jira] Updated: (TUSCANY-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback

[Paul Golick (JIRA)]

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

Paul Golick updated TUSCANY-1347:
-

Attachment: sca_itest_echoService.jar

The attached version of the test case code has been modified as suggested by 
Jean-Sebastien's comment.  This version now fails with a NPE in 
RuntimeSCABindingInvoker with this stack trace:
test_asyncEchoService(org.apache.tuscany.sca.test.echoService.EchoServiceTestCase)
  Time elapsed: 0.07 sec  <<< ERROR!
java.lang.NullPointerException
at 
org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41)
at 
org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143)
at 
org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:91)
at $Proxy4.echoResults(Unknown Source)
at 
org.apache.tuscany.sca.test.echoService.AsyncEchoServiceImpl.echo(AsyncEchoServiceImpl.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134)
at 
org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46)
at 
org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41)
at 
org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73)
at $Proxy3.echo(Unknown Source)
at 
org.apache.tuscany.sca.test.echoService.EchoServiceImpl.asyncEcho(EchoServiceImpl.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134)
at 
org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46)
at 
org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41)
at 
org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73)
at $Proxy2.asyncEcho(Unknown Source)
at 
org.apache.tuscany.sca.test.echoService.RelayServiceImpl.asyncEcho(RelayServiceImpl.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134)
at 
org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46)
at 
org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41)
at 
org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73)
at $Proxy2.asyncEcho(Unknown Source)
at 
org.apache.tuscany.sca.test.echoService.EchoServiceTestCase.test_asyncEchoService(EchoServiceTestCase.java:89)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.Test

[jira] Updated: (TUSCANY-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback

[Paul Golick (JIRA)]

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

Paul Golick updated TUSCANY-1347:
-

Attachment: (was: sca_itest_echoService.jar)

> IndexOutOfBoundsException thrown when trying to locate a service that 
> includes a callback
> -
>
> Key: TUSCANY-1347
> URL: https://issues.apache.org/jira/browse/TUSCANY-1347
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Embedded Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Assignee: Simon Nash
> Fix For: Java-SCA-Next
>
> Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar
>
>
> More complete description and test case to follow
> Here is the exception thrown...
> [6/14/07 17:59:55:187 MDT] 0020 SystemErr R 
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
>   at java.util.ArrayList.RangeCheck(ArrayList.java:572)
>   at java.util.ArrayList.get(ArrayList.java:347)
>   at 
> org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98)
>   at 
> org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
>   at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

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

[SCA Native] Samples CppBigBank build.xml

[Brady Johnson]

 
Here's the build.xml for the CppBigBank sample. We'll need to start with
the rest of the samples soon.
 
I'll be freed up this afternoon to start on the M4 items.
 

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




  
  

  

  









  

  
  


  

  



  

  




  

  




  

  



  
   


  


  

  
  


  

  




  

  

  

  






  

  

  
  



  

  


  


  


  

  




  

  


  

  
  



  


  

  


  

  
  


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

[jira] Resolved: (TUSCANY-1492) Support implemental class not only interface when get a service

[Raymond Feng (JIRA)]

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

Raymond Feng resolved TUSCANY-1492.
---

Resolution: Fixed

Patch applied. Thank you so much.

> Support implemental class not only interface when get a service
> ---
>
> Key: TUSCANY-1492
> URL: https://issues.apache.org/jira/browse/TUSCANY-1492
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.91
> Environment: JDK1.5.09,winXP
>Reporter: wangfeng
>Priority: Minor
> Fix For: Java-SCA-0.91
>
> Attachments: patch.txt, TestCase_Calculator.zip
>
>
> when we get a service,we always generate a proxy on the service by using the 
> jdk proxy class, so we must provide a interface to get a service.
> I provide a patch to remove the control. This patch not only support the 
> interface,but also support the implemental class when getting a service.when 
> the class isn't a interface,using the cglib to generate a proxy  and using 
> jdk proxy when the class is a interface. 

-- 
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: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

[Luciano Resende]

I have reopened the JIRA and will give it a try...

On 8/2/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
> Folks,
>
> I agree with Simon's comment - this resolution violates the SCA spec.
> You are not supposed to go adding stuff to the SCA namespace that is not
> approved by the SCA spec process.  In particular, no additions to the
> sca.xsd or sca-core.xsd are allowed.
>
> Yours,  Mike.
>
> ant elder (JIRA) wrote:
> >  [ 
> > https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> >  ]
> >
> > ant elder closed TUSCANY-1053.
> > --
> >
> > Resolution: Fixed
> >
> > Closing as it looks like we've standardized on using the SCA namespace
> >
> >> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> >> -
> >>
> >> Key: TUSCANY-1053
> >> URL: https://issues.apache.org/jira/browse/TUSCANY-1053
> >> Project: Tuscany
> >>  Issue Type: Improvement
> >>  Components: Java SCA Assembly Model
> >>Affects Versions: Java-SCA-Next
> >>Reporter: ant elder
> >>Assignee: ant elder
> >> Fix For: Java-SCA-Next
> >>
> >>
> >> Currently Tsucany extensions use SCDL elements is varrious different 
> >> namespaces. There should be a single Tuscany namespace that extensions not 
> >> defined by SCA spec's should use. See 
> >> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL 
> >> PROTECTED]
> >
>
> -
> 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]

[jira] Reopened: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

[Luciano Resende (JIRA)]

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

Luciano Resende reopened TUSCANY-1053:
--

  Assignee: Luciano Resende  (was: ant elder)

Reopening per latest discussion comments :
"...this resolution violates the SCA spec.
You are not supposed to go adding stuff to the SCA namespace that is not
approved by the SCA spec process.  In particular, no additions to the
sca.xsd or sca-core.xsd are allowed."

> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> -
>
> Key: TUSCANY-1053
> URL: https://issues.apache.org/jira/browse/TUSCANY-1053
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-Next
>Reporter: ant elder
>Assignee: Luciano Resende
> Fix For: Java-SCA-Next
>
>
> Currently Tsucany extensions use SCDL elements is varrious different 
> namespaces. There should be a single Tuscany namespace that extensions not 
> defined by SCA spec's should use. See 
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL 
> PROTECTED]

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


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

Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks

[Jean-Sebastien Delfino]

Simon Nash wrote:


Simon Nash wrote:


(cut)

Instead of trying to establish callback wires all over the place, 
which will not fly anyway as soon as 2 references with callback are 
wired to a single service, flow the endpoint reference of the 
callback service representing the client in the SCA request message 
and use it to direct the callback "in context" as suggested by 
Raymond in thread [1].


These callback wires are already being established and AFAIK this 
does work

in the case you describe.  The callback wire is selected based on the
forward wire that was used.  I'll write an itest to verify that this is
working correctly.

I created this itest and verified that it runs correctly.  I have 
attached

it to TUSCANY-1503 as a patch.

  Simon



Ok, this works now, but this JIRA is talking about a different design where:
- callbacks will be represented as (almost) regular services and references
- there will be no special processing anymore for callback wires in the 
core runtime.


That's why I said in my comment "will not fly" instead of "does not fly" 
:) Will this particular configuration still work with the new design, 
and without all the special processing we currently have for callback wires?


In particular, with the new proposed design, a service with a callback 
will be represented as a reference, if the service was wired to by 
multiple clients, the reference representing the callback will have to 
be wired to these multiple clients (and on them the services that 
represent callbacks). This looks like a reference with multiplicity > 0, 
and it doesn't look to me like the proper way to represent this wiring. 
At least that alone won't allow us to select the correct client to callback.


So I think we should at least evaluate both options (establish regular 
wires vs flowing endpoint references) in the context of this new design.


--
Jean-Sebastien


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

[jira] Updated: (TUSCANY-1504) getSequence() returns null with a complexType defined without mixed="true"

[Matthew Schultz (JIRA)]

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

Matthew Schultz updated TUSCANY-1504:
-

Attachment: letter.xsd

Here's an example xsd.  If you try to run getSequence on the root data object, 
getSequence returns null.  If you add mixed="true" to complextType, getSequence 
returns an object.  

> getSequence() returns null with a complexType defined without mixed="true"
> --
>
> Key: TUSCANY-1504
> URL: https://issues.apache.org/jira/browse/TUSCANY-1504
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-M3
>Reporter: Matthew Schultz
> Attachments: letter.xsd
>
>
> getSequence returns null if complextType does not have the mixed attribute or 
> the mixed attribute is set to false.  
> Looking at the code, SDOSchemaSAX2Parser::startComplexType and
> SDOSchemaSAX2Parser::defineType appears to be the two places that
> isSequenced is set.  In startComplexType, it appears that both mixed and
> sequence are both treated as an attribute.  I cannot tell if it ever
> reads the child .
> It appears that isSequenced should be set to true on the basis of the
> child  and not on the basis of mixed.

-- 
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] Issue Comment Edited: (TUSCANY-1504) getSequence() returns null with a complexType defined without mixed="true"

[Matthew Schultz (JIRA)]

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

Matthew Schultz edited comment on TUSCANY-1504 at 8/2/07 8:07 AM:
--

Here's an example xsd.  If you try to run getSequence on the root data object, 
getSequence returns null.  If you add mixed="true" to complexType, getSequence 
returns an object.  


 was:
Here's an example xsd.  If you try to run getSequence on the root data object, 
getSequence returns null.  If you add mixed="true" to complextType, getSequence 
returns an object.  

> getSequence() returns null with a complexType defined without mixed="true"
> --
>
> Key: TUSCANY-1504
> URL: https://issues.apache.org/jira/browse/TUSCANY-1504
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-M3
>Reporter: Matthew Schultz
> Attachments: letter.xsd
>
>
> getSequence returns null if complextType does not have the mixed attribute or 
> the mixed attribute is set to false.  
> Looking at the code, SDOSchemaSAX2Parser::startComplexType and
> SDOSchemaSAX2Parser::defineType appears to be the two places that
> isSequenced is set.  In startComplexType, it appears that both mixed and
> sequence are both treated as an attribute.  I cannot tell if it ever
> reads the child .
> It appears that isSequenced should be set to true on the basis of the
> child  and not on the basis of mixed.

-- 
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: Java SDO failing on tests

[ant elder]

On 8/2/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've downloaded the SDO from the trunk today and got the following errors
> when running 'mvn' on /tuscany/sdo/ dir:
>
> Results :
>
> Tests in error:
>   testConversionsFromDate(
> org.apache.tuscany.sdo.test.DateConversionTestCase
> )
>   testConversionsFromDateTime(
> org.apache.tuscany.sdo.test.DateConversionTestCase
> )
>   testConversionsFromDuration(
> org.apache.tuscany.sdo.test.DateConversionTestCase
> )
>   testConversionsFromMonth(
> org.apache.tuscany.sdo.test.DateConversionTestCase)
>   testConversionsFromMonthDay(
> org.apache.tuscany.sdo.test.DateConversionTestCase
> )
>   testConversionsFromYear(
> org.apache.tuscany.sdo.test.DateConversionTestCase
> )
>   testConversionsFromYearMonth(
> org.apache.tuscany.sdo.test.DateConversionTestCas
> e)
>   testConversionsFromYearMonthDay(
> org.apache.tuscany.sdo.test.DateConversionTest
> Case)
>
> Tests run: 189, Failures: 0, Errors: 8, Skipped: 0
>
> [INFO]
> 
> [ERROR] BUILD FAILURE
> [INFO]
> 
> [INFO] There are test failures.
> [INFO]
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> 
> [INFO] Total time: 6 minutes 42 seconds
> [INFO] Finished at: Thu Aug 02 10:24:50 GMT-04:00 2007
> [INFO] Final Memory: 10M/34M
> [INFO]
> 
>
>
>
> Anyone else getting these errors too?
>
> Adriano Crestani
>

Its building fine for me. As those failures all seem to be date/time related
i wondered if it was a JDK thing, but i've just tried with several JDK's and
it always works fine. Also building with an empty local mvn repository is
working ok for me, so i'm not sure what the problem could be. Are you
definitely on the latest code, and what JDK and mvn version are you using?

   ...ant

[jira] Created: (TUSCANY-1504) getSequence() returns null with a complexType defined without mixed="true"

[Matthew Schultz (JIRA)]

getSequence() returns null with a complexType defined without mixed="true"
--

 Key: TUSCANY-1504
 URL: https://issues.apache.org/jira/browse/TUSCANY-1504
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-M3
Reporter: Matthew Schultz


getSequence returns null if complextType does not have the mixed attribute or 
the mixed attribute is set to false.  

Looking at the code, SDOSchemaSAX2Parser::startComplexType and
SDOSchemaSAX2Parser::defineType appears to be the two places that
isSequenced is set.  In startComplexType, it appears that both mixed and
sequence are both treated as an attribute.  I cannot tell if it ever
reads the child .

It appears that isSequenced should be set to true on the basis of the
child  and not on the basis of mixed.

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

Java SDO failing on tests

[Adriano Crestani]

Hi,

I've downloaded the SDO from the trunk today and got the following errors
when running 'mvn' on /tuscany/sdo/ dir:

Results :

Tests in error:
  testConversionsFromDate(org.apache.tuscany.sdo.test.DateConversionTestCase
)
  testConversionsFromDateTime(
org.apache.tuscany.sdo.test.DateConversionTestCase
)
  testConversionsFromDuration(
org.apache.tuscany.sdo.test.DateConversionTestCase
)
  testConversionsFromMonth(
org.apache.tuscany.sdo.test.DateConversionTestCase)
  testConversionsFromMonthDay(
org.apache.tuscany.sdo.test.DateConversionTestCase
)
  testConversionsFromYear(org.apache.tuscany.sdo.test.DateConversionTestCase
)
  testConversionsFromYearMonth(
org.apache.tuscany.sdo.test.DateConversionTestCas
e)
  testConversionsFromYearMonthDay(
org.apache.tuscany.sdo.test.DateConversionTest
Case)

Tests run: 189, Failures: 0, Errors: 8, Skipped: 0

[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] There are test failures.
[INFO]

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

[INFO] Total time: 6 minutes 42 seconds
[INFO] Finished at: Thu Aug 02 10:24:50 GMT-04:00 2007
[INFO] Final Memory: 10M/34M
[INFO]




Anyone else getting these errors too?

Adriano Crestani

Re: Patch for TUSCANY-1397

[Adriano Crestani]

I may commit it till the eod if nobody has no objection ; )

Adriano Crestani

On 8/2/07, Andy Grove <[EMAIL PROTECTED]> wrote:
>
> I've submitted a patch for TUSCANY-1397 and I'd like someone to review
> this before I apply it since it is my first patch to the Tuscany SDO
> implementation (I've only been submitting to the CTS until now).
>
> The purpose of this patch is to implement on-demand creation of
> properties in createDataObject().
>
> https://issues.apache.org/jira/browse/TUSCANY-1397
>
> Thanks,
>
> Andy.
>

Build failure in binding-ejb

[Simon Nash]

The latest Java SCA trunk doesn't build from a clean checkout because
of a failure building binding-ejb (a NoClassDefFoundError for
org/objectweb/asm/Type).  This was puzzling because there are no
recent changes to binding-ejb.

With a vital clue from Ant, I traced the problem to the recent change
that was made to the pom for implementation-java-runtime as part of
the patch for TUSCANY-1492.  If the recently added dependency in this
file is changed from

cglib
cglib
2.1_3

to

cglib
cglib-nodep
2.1_3

then the build runs OK.

  Simon


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

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

[Mike Edwards]

Folks,

I agree with Simon's comment - this resolution violates the SCA spec. 
You are not supposed to go adding stuff to the SCA namespace that is not 
approved by the SCA spec process.  In particular, no additions to the 
sca.xsd or sca-core.xsd are allowed.


Yours,  Mike.

ant elder (JIRA) wrote:

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

ant elder closed TUSCANY-1053.
--

Resolution: Fixed

Closing as it looks like we've standardized on using the SCA namespace


Use a Tuscany namespace for all non-spec'd Tuscany extensions
-

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


Currently Tsucany extensions use SCDL elements is varrious different 
namespaces. There should be a single Tuscany namespace that extensions not 
defined by SCA spec's should use. See 
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL 
PROTECTED]




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

Patch for TUSCANY-1397

[Andy Grove]

I've submitted a patch for TUSCANY-1397 and I'd like someone to review
this before I apply it since it is my first patch to the Tuscany SDO
implementation (I've only been submitting to the CTS until now).
 
The purpose of this patch is to implement on-demand creation of
properties in createDataObject().
 
https://issues.apache.org/jira/browse/TUSCANY-1397
 
Thanks,
 
Andy.

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

[Andy Grove (JIRA)]

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

Andy Grove updated TUSCANY-1397:


Attachment: tuscany1397.patch

This patch implements supoport for on-demand creation of properties when 
calling createDataObject(). The patch also contains a test case.

> 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
> Attachments: tuscany1397.patch
>
>
> 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] Updated: (TUSCANY-1397) createDataObject() throws NPE if property does not exist

[Andy Grove (JIRA)]

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

Andy Grove updated TUSCANY-1397:


Patch Info: [Patch Available]

> 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
> Attachments: tuscany1397.patch
>
>
> 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] Commented: (TUSCANY-1397) createDataObject() throws NPE if property does not exist

[Andy Grove (JIRA)]

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

Andy Grove commented on TUSCANY-1397:
-

We discussed this issue in last week's SDO spec. call and decided that for now 
(SDO 2.1.1) we will leave this behaviour unspecified but there seemed to be 
general concensus that the correct behaviour (to be clarified for SDO 3.0) 
would be to on-demand create the property for consistency with other set() 
methods. 



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

Re: [RDB DAS] Consistent use of Parameters in Config

[Amita Vadhavkar]

JPQL, Hibernate ,... have support for named parameters.

Why is RDB DAS going in the other way? If there is a reason for switching
off named parameters, please elaborate, else is it OK to go for JIRA-1462?

Regards,
Amita

On 7/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
>
> 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
> ())
> http:///org.apache.tuscany.das.rdb/config.xsd";>
>
>   
>   
>   
>   
>   
>
> 
>
> This is informative because we have 
> 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)
> 
> 
> 
>
> 
>
> 
>
> 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 Nam

[jira] Commented: (TUSCANY-1464) Wrong query results when SELECT misses PKs

[Adriano Crestani (JIRA)]

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

Adriano Crestani commented on TUSCANY-1464:
---

1- OK
2 - commented on ML
3-
As ID column being considered primary key is a Convention Over Configuration 
issue, I think the user shouldn't need to declare it anywhere, cause DAS should 
recognize it anyway. What do you think?

Regards,
Adriano Crestani

> Wrong query results when SELECT misses PKs
> --
>
> Key: TUSCANY-1464
> URL: https://issues.apache.org/jira/browse/TUSCANY-1464
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-Next
>Reporter: Amita Vadhavkar
>Assignee: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
> Attachments: 1464.patch
>
>
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20322.html
> Fix the bug uncovered in above mail discussion.

-- 
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] Wrong Query Result when SELECT misses PKs

[Adriano Crestani]

Yes, I think it should fail, once DAS shouldn't omit a data  from the user.
Cause, if the pk has null pk, it means it doesn't have an id and cannot be
guaranteed its uniqueness. I think maybe DAS should not throw the exception,
but needs to warn the user when any row is omitted, however I don't think it
is a good approach at all. My suggestion is that it should fail whenever is
found a null pk.

Regards,
Adriano Crestani

On 8/2/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
>
> There is a bit of confusion around the RecursiveTests.testReadEngineParts
> ()
> , in the context of this fix.
>
> Below is the data for tables, queries etc.
>
> sql return:-
> *1 Engine 1 -   2 Block  1 1  -
> - - -
> *1 Engine 1 -   3 Cam Soft 2 1  - -
> - -
> 1 Engine 1 -4 Piston 8 1  5 Piston
> Ring 2 4
>
> table data:-
> id name qty parent id
> 1 Engine1   -
> 2 Block 1   1
> 3 Cam Soft2   1
> 4 Piston8   1
> 5 Piston Ring 2   4
>
> query:-
> SELECT
>P1.ID,
>P1.NAME,
>P1.QUANTITY,
>P1.PARENT_ID,
>P2.ID,
>P2.NAME,
>P2.QUANTITY,
>P2.PARENT_ID,
>P3.ID,
>P3.NAME,
>P3.QUANTITY,
>P3.PARENT_ID
> FROM
>APP.PART AS P1 LEFT OUTER JOIN APP.PART AS P2
>   ON P1.ID = P2.PARENT_ID
>LEFT OUTER JOIN APP.PART AS P3
>   ON P2.ID = P3.PARENT_ID
> WHERE
>P1.ID = 1
>
> See the recursiveTests. here the recursion occurs 3 times on the same
> (part)
> table and total 5 DOs should be formed in mem. (pre-existing case). Now
> see
> ResultSetProcessor.addRowToGraph(). if we take null data in pk as
> exception,
> the rows from
> sql return above marked with *, will cause the whole query to fail and so
> the recursiveTests
> will fail.
>
> But if we do some adjustments to allow this case to succeed, there can be
> other situations
> where not throwing exception for null data in PK for any row can cause
> problem (incomplete/wrong results). So, is it better to make
> RecursiveTests
> fail? Suggestions?
>
> Regards,
> Amita
>
> On 7/28/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> >
> > It seems ok Amita ; )
> >
> > Adriano Crestani
> >
> > On 7/27/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Adriano,
> > > Yes, so in summary , trying to do following -
> > >
> > > 1) select missing complete or partial PK for any of the tables
> involved-
> > > exception
> > > 2) if any table in select has no PK in config and no ID column in
> > > config/select - exception
> > > 3) if any table in select has no PK in config and has ID column in
> > config
> > > -
> > > exception
> > > 4) if any table in select has no PK in config but has ID column in
> > SELECT
> > > -
> > > success
> > >
> > > Regards,
> > > Amita
> > >
> > > On 7/27/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I had the same problem on DAS C++, now it's throwing an exception
> when
> > > it
> > > > finds a row that does not contain all the pk columns.
> > > >
> > > > I'm not used to the DAS Java, but I will explain how I did it on DAS
> > > C++,
> > > > maybe this can help you ; )
> > > >
> > > > It reads the ResultSet metadata to find the pk columns. If the PK is
> > > > defined
> > > > on the config, so it look for the columns defined as pk on the
> config.
> > > In
> > > > case it does not find the pk column(or columns if it is a compound
> > pk),
> > > it
> > > > looks for the ID columns according to DAS Convention Over
> > Configuration
> > > > rules. Otherwise it throws the exception.
> > > >
> > > > Does it help? : )
> > > >
> > > > Regards,
> > > > Adriano Crestani
> > > >
> > > > On 7/27/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Further on this,
> > > > > Need to consider single and compound PKs case.
> > > > > When select does not include complete PK (all PK columns from
> > compound
> > > > PK)
> > > > > ,
> > > > > DAS needs to throw exception.
> > > > >
> > > > > As a fix proposing below changes:-
> > > > >
> > > > > A>In ResultMetadata - introduce new HashMap tableToPrimaryKeys ,
> > fill
> > > it
> > > > > during constuctor
> > > > > and provide get method - getAllPKsForTable(tableName).
> > > > >
> > > > > B> In ResultSetRow - add method
> > > > > checkResultSetMissesPK(allTableNamesFromQueryResultSet)
> > > > > which will take each table and check if all PKs are there in
> result
> > > set.
> > > > > If
> > > > > not it will mark that TableData with hasValidPKs=FALSE.
> > > > >
> > > > > C> There is already another check in TableData.addData(), which
> > marks
> > > > this
> > > > > flag FALSE, if any PK in result set has NULL data.
> > > > >
> > > > > B> and C> together will provide complete check
> > > > >
> > > > > D>In ResultSetRow, call,
> > > > > checkResultSetMissesPK(allTableNamesFromQueryResultSet) from
> > > > processRow()
> > > > > and proc