date:20070710


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

Amita Vadhavkar updated TUSCANY-1419:
-

Attachment: (was: readme.htm.sample-ajax-das)

> Java DAS RDB beta1 RC2 - minor issues
> -
>
> Key: TUSCANY-1419
> URL: https://issues.apache.org/jira/browse/TUSCANY-1419
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Amita Vadhavkar
> Attachments: readme.htm.companyweb, readme.htm.sample-ajax-das, 
> Readme.htm.samplesReadme, RELEASE_NOTES
>
>
> This patch is created to provide some minor corrections to below files
> 1) RELEASE NOTES
> 2) companyweb/readme
> 3) sample-ajax-das-readme

-- 
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-1419) Java DAS RDB beta1 RC2 - minor issues


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

Amita Vadhavkar updated TUSCANY-1419:
-

Attachment: (was: readme.htm.companyweb)

> Java DAS RDB beta1 RC2 - minor issues
> -
>
> Key: TUSCANY-1419
> URL: https://issues.apache.org/jira/browse/TUSCANY-1419
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Amita Vadhavkar
> Attachments: readme.htm.companyweb, readme.htm.sample-ajax-das, 
> readme.htm.sample-ajax-das, Readme.htm.samplesReadme, RELEASE_NOTES
>
>
> This patch is created to provide some minor corrections to below files
> 1) RELEASE NOTES
> 2) companyweb/readme
> 3) sample-ajax-das-readme

-- 
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-1419) Java DAS RDB beta1 RC2 - minor issues


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

Amita Vadhavkar updated TUSCANY-1419:
-

Attachment: readme.htm.sample-ajax-das
readme.htm.companyweb

Below is the summary for changes that I did on the top of existing readmes,
based on all the comments obtained so far.

It will be very helpful if these can be reviewed here and further
comments given , so that the finalilized readmes can be used in RC.

companyweb
__
1) title changed to 'RDB DAS CompanyWeb Sample'
2) rephrased section 'Running from Tomcat configured by the build' to indicate 
that
   this approach is relevant from source destribution only.
3) changes related to database setup using dbConfig (removed canned db mention 
etc.)
4) changed Sample distribution -> Binary distribution wherever applicable
5) corrected database url 

sample-ajax-das
___
1) dbsetup -> dbConfig
2) rephrased section 'Running from Tomcat configured by the build' to indicate 
that
   this approach is relevant from source destribution only.
3) changed Sample distribution -> Binary distribution wherever applicable
4) changes related to database setup using dbConfig (removed canned db mention 
etc.)
5) corrected lib location based on Tomcat version

> Java DAS RDB beta1 RC2 - minor issues
> -
>
> Key: TUSCANY-1419
> URL: https://issues.apache.org/jira/browse/TUSCANY-1419
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Amita Vadhavkar
> Attachments: readme.htm.companyweb, readme.htm.sample-ajax-das, 
> readme.htm.sample-ajax-das, Readme.htm.samplesReadme, RELEASE_NOTES
>
>
> This patch is created to provide some minor corrections to below files
> 1) RELEASE NOTES
> 2) companyweb/readme
> 3) sample-ajax-das-readme

-- 
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-1317) Provide a way to set default XML load options to be used during Java deserialization


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

Amita Vadhavkar commented on TUSCANY-1317:
--

Hi All, Please let me know if  any comments/feedbacks are pending and when  I 
can do all
comments clean up. Thank you.

> Provide a way to set default XML load options to be used during Java 
> deserialization
> 
>
> Key: TUSCANY-1317
> URL: https://issues.apache.org/jira/browse/TUSCANY-1317
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1, Java-SDO-1.0
>Reporter: Daniel Peter
> Fix For: Java-SDO-1.0
>
> Attachments: 1317.patch, 1317.patch, 1317.patch, 1317.patch, 
> 1317.patch, 1317.patch, JIRA1317Design.txt, JIRA1317Design.txt, 
> JIRA1317Design.txt, JIRA1317Design.txt, JIRA_1317_June21.txt, 
> JIRA_1317_June25_Amita.txt
>
>
> XML load options can be passed when calling the XMLHelper.load(...) methods. 
> But there is currently no way to pass such load options to be used during 
> Java deserialization.
> Thus a way to set default load options should be provided, e.g. 
> SDOUtil.setDefaultXMLOptions(HelperContext, Object options)
> These default options could then be picked up during Java deserialization, 
> i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl.
> Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be 
> exposed in Tuscany SDO.

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


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

Amita Vadhavkar commented on TUSCANY-1391:
--

Hi, Please let me know if any review/.feedback is pending, and when I can do 
all code comments 
cleanup etc. 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, 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]

[jira] Resolved: (TUSCANY-1412) NPE in DataBindingRuntimeWireProcessor in null output boundary case (and null input?)

2007-07-10 Thread Raymond Feng (JIRA)


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

Raymond Feng resolved TUSCANY-1412.
---

   Resolution: Fixed
Fix Version/s: Java-SCA-Next

Fixed at the level r555163. 

> NPE in DataBindingRuntimeWireProcessor in null output boundary case (and null 
> input?)
> -
>
> Key: TUSCANY-1412
> URL: https://issues.apache.org/jira/browse/TUSCANY-1412
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-M2
> Environment: r540027
>Reporter: Scott Kurz
>Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> Haven't checked the latest code...but... 
> I have a Java method with signature:void myMethod(whatever...)
> and the WSDL output wrapper elem is defined as:
>   
>
>  
>
>   
> I hit the following NPE when activating the Composite 
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:51)
>   at 
> org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:72)
>   at 
> org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:99)
>   at 
> org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.process(DataBindingRuntimeWireProcessor.java:116)
> The source DataType is:
>class java.lang.Object org.apache.axiom.om.OMElement Element: 
> {http://blah}myMethodResponse Type: null
> But the target DataType corresponding to the 'void' is simply 

-- 
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-1341) Callback over WS Binding is not functioning various issues

2007-07-10 Thread Raymond Feng (JIRA)


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

Raymond Feng commented on TUSCANY-1341:
---

The patch was applied under r555362.

> Callback over WS Binding is not functioning various issues
> --
>
> Key: TUSCANY-1341
> URL: https://issues.apache.org/jira/browse/TUSCANY-1341
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Misc Binding Extensions
>Affects Versions: Java-SCA-0.90
>Reporter: Lou Amodeo
>Assignee: Simon Nash
> Attachments: jira1341-patch1, jira1341-patch2, jira1341-patch3, 
> jira1341-patch4, jira1341-patch5, jira1341-patch7, 
> jira1341-take2-newfiles.zip, jira1341-take2-patch1, jira1341-take2-patch2, 
> jira1341-take2-patch3, simple-callback-ws.zip
>
>
> The callback function using WS bindings doesnt appear to be operation.  So 
> far I have :
> 1) WebServiceBindingProcessor.java 
> -  The resolve() method does not setup the callbackInterface on its 
> InterfaceContract resulting in NPE.
> (i.e. interfaceContract.setCallbackInterface(wsdlCallbackInterface); )
> [6/11/07 13:33:02:220 EDT] 0025 SystemOut O   ... 87 more
> [6/11/07 13:33:02:220 EDT] 0025 SystemOut O Caused by: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.map(InterfaceContractMapperImpl.java:246)
>   at 
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createWires(CompositeActivatorImpl.java:337)
>   at 
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createRuntimeWires(CompositeActivatorImpl.java:269)
>   at 
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:580)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain$DomainCompositeHelper.addComposite(EmbeddedSCADomain.java:124)
>   at 
> com.ibm.ws.sca2.tuscany.util.TuscanyInterfaceImpl.startModule(TuscanyInterfaceImpl.java:223)
>   at 
> com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:82)
>   at 
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:366)
>   at 
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.stateChanged(SCARuntimeImpl.java:286)
>   at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.stateChanged(ApplicationMgrImpl.java:1264)
>   at 
> com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectEvent(DeployedApplicationImpl.java:1112)
>   at 
> com.ibm.ws.runtime.component.DeployedModuleImpl.setState(DeployedModuleImpl.java:206)
>   at 
> com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:566)
>   at 
> com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:814)
>   at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:965)
>   at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl$1.run(ApplicationMgrImpl.java:1495)
>   at 
> com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:3924)
>   at 
> com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:4001)
>   at 
> com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:245)
>   at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:1500)
>   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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:62)
>   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:615)
>   at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:265)
>   at 
> javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1089)
>   at 
> javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:971)
>   at 
> com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:231)
>   at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802)
>   at 
> com.ibm.ws.management.AdminServiceImpl$1.run(AdminService

[jira] Updated: (TUSCANY-1237) DAS should support JDK 1.4 runtime

2007-07-10 Thread Ron Gavlin (JIRA)


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

Ron Gavlin updated TUSCANY-1237:


Summary: DAS should support JDK 1.4 runtime  (was: DAS should support JDK 
1.4)

> DAS should support JDK 1.4 runtime
> --
>
> Key: TUSCANY-1237
> URL: https://issues.apache.org/jira/browse/TUSCANY-1237
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
> Environment: Windows, Sun JDK 1.4.2_11
>Reporter: Ron Gavlin
> Fix For: Java-DAS-Next
>
> Attachments: das-TUSCANY-1237.2.patch, das-TUSCANY-1237.patch
>
>
> Tuscany DAS should support JDK 1.4. Since Tuscany DAS leverages SDO, it would 
> seem to make sense for the DAS
> JDK requirements to be sync'd with the Tuscany SDO JDK requirements. Tuscany 
> SDO currently supports JDK 1.4+. After browsing the DAS source code, there 
> appear to be only a few places that leverage JDK 1.5 features. These could 
> easily be replaced with JDK 1.4 functions. Please consider supporting JDK 1.4 
> until SDO 3 is released at which time I presume SDO will require JDK 1.5.

-- 
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: Update from board regarding our oversight of WS project.

2007-07-10 Thread Davanum Srinivas


Folks,

4 Projects have no volunteers yet...Axis/Axis2/JaxMe/XMLRPC

http://wiki.apache.org/ws/FrontPage/BoardReports

The board meeting is on 18th this month.

Please update info on your project here:
http://wiki.apache.org/ws/ReportForJul2007

thanks,
dims

On 7/3/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:

Folks,

The matrix is still sparse :) Please sign up!!!
http://wiki.apache.org/ws/FrontPage/BoardReports

-- dims

On 7/3/07, Kaushalye Kapuruge <[EMAIL PROTECTED]> wrote:
> Hi Dims,
> I volunteer for Apache Rampart-C project.
> Cheers,
> Kaushalye
>
> Kaushalye Kapuruge wrote:
> > Hi Dims,
> > I volunteer for Apache Rampart-C project.
> > Cheers,
> > Kaushalye
> >
> > Davanum Srinivas wrote:
> >> Team,
> >>
> >> The board would like WS reports to move towards the style and
> >> development that the Jakarta and Incubator reports are done (i.e.,
> >> owners for subprojects developing their parts, and the overall chair
> >> acting as editor). For Inspiration, See [1]
> >>
> >> So, Firstly, Please volunteer (take ownership!!) to take charge for
> >> reports for your subproject. If i don't hear from anyone on a specific
> >> subproject, i will assume that no one is interested in that subproject
> >> anymore and we can start the process of pruning that subproject. FYI,
> >> the Spring cleaning is done [2]
> >>
> >> Secondly, If there are folks who are not on the ws pmc, but who should
> >> be, then please bring up their nomination on private AT ws.apache.org
> >>
> >> I really hope the exisiting PMC members and the new ones will
> >> rejuvenate our board reporting duty and continued oversight of the
> >> "umbrella" WS project. It may be time to do some spring cleaning of
> >> the pmc too as there are quite a few folks who are not active anymore.
> >> One option is to change them to Emeritus status. If anyone falls into
> >> this category, please let chime in.
> >>
> >> BTW, i was a bit late in submission, we have to do another board
> >> report for this month. I've started a page here:
> >> http://wiki.apache.org/ws/ReportForJul2007
> >>
> >> thanks,
> >> dims
> >>
> >> [1] http://wiki.apache.org/incubator/June2007
> >> [2]
> >> http://mail-archives.apache.org/mod_mbox/ws-general/200703.mbox/[EMAIL 
PROTECTED]
> >>
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Davanum Srinivas :: http://davanum.wordpress.com




--
Davanum Srinivas :: http://davanum.wordpress.com

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

[jira] Commented: (TUSCANY-1237) DAS should support JDK 1.4

2007-07-10 Thread Ron Gavlin (JIRA)


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

Ron Gavlin commented on TUSCANY-1237:
-

Amita,

The intention of this patch is to support JDK 1.4+ as a RUNTIME and not to 
support the JDK 1.4+ compiler itself. The pom.xml in this patch still uses the 
JDK 5 compiler however it is now configured to generate JDK 1.4-compatible 
class files. The SDO build is configured identically. This patch just brings 
the DAS build into alignment with the current SDO build which is sufficient for 
my purposes.

It would be pretty straightforward to take the DAS build a step further and 
support the JDK 1.4 compiler. The SDO build would require more work since one 
or two non-runtime classes have real dependencies on JDK 5 features. 

A potential enhancement to both the SDO and DAS builds would be to configure 
their tests to run using a JDK 1.4+ runtime. It might make sense to open 
another JIRA to track that enhancement if you think it makes sense.

Let me know if you have add'l questions.

- Ron


> DAS should support JDK 1.4
> --
>
> Key: TUSCANY-1237
> URL: https://issues.apache.org/jira/browse/TUSCANY-1237
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
> Environment: Windows, Sun JDK 1.4.2_11
>Reporter: Ron Gavlin
> Fix For: Java-DAS-Next
>
> Attachments: das-TUSCANY-1237.2.patch, das-TUSCANY-1237.patch
>
>
> Tuscany DAS should support JDK 1.4. Since Tuscany DAS leverages SDO, it would 
> seem to make sense for the DAS
> JDK requirements to be sync'd with the Tuscany SDO JDK requirements. Tuscany 
> SDO currently supports JDK 1.4+. After browsing the DAS source code, there 
> appear to be only a few places that leverage JDK 1.5 features. These could 
> easily be replaced with JDK 1.4 functions. Please consider supporting JDK 1.4 
> until SDO 3 is released at which time I presume SDO will require JDK 1.5.

-- 
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: Problems using WSDL interfaces together with DataBinding (DB) framework

2007-07-10 Thread Scott Kurz


No, it looks like the InterfaceImpl types no longer implement Cloneable
though I remember the old version of this function did support clone().
Scott.

On 7/6/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I think the clone() has already been supported.

Thanks,
Raymond

- Original Message -
From: "Scott Kurz" <[EMAIL PROTECTED]>
To: 
Sent: Friday, July 06, 2007 8:41 AM
Subject: Re: Problems using WSDL interfaces together with DataBinding (DB)
framework


> After thinking on this a bit, I wonder if I was confusing things by
> wrongly
> coupling the question of Java vs. WSDL interface with the choice of
> DataBinding.
>
> Say I wanted the java.lang.Object DB for my binding.I could still
set
> this up on the binding-level operation objects, whether I had a Java or
> WSDL
> interface.
>
> It's not as if by using a WSDL interface I'm tied to using something
like
> an
> AXIOM DB.
>
> Right?
>
> So I guess this is still a simple pattern binding impls could use.
>
> A separate issue though is the question of whether we should be able to
> clone (2) at the level of (3) instead of writing to the same
object.I
> think these used
> to be clonable...
>
> Scott
>
>
> On 7/6/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>>
>> On 7/6/07, Scott Kurz <[EMAIL PROTECTED]> wrote:
>> >
>> > Raymond,
>> >
>> > Your proposal makes sense to me.
>> >
>> > It seems like a nice simplification to view the component-level intf
>> > (2)
>> > as
>> > existing only for testing
>> > wire-mappability of interfaces and to view the "componentType intf",
>> > (or
>> > impl-level intf)  (1) and
>> > the binding intf (3) as the interfaces with databindings associated
>> > with
>> > them.
>> >
>> > Would you agree one consequence of such a change, though, would be
that
>> > binding impl like the default binding impl whose method impl:
>> >
>> > RuntimeSCABindingProvider.getBindingInterfaceContract()
>> >
>> > merely delegates to the
>> >
>> > RuntimeComponentReference.getInterfaceContract()
>> >
>> > would have to be reconsidered?
>> >
>> > This code setting up interface (3) on the binding might prefer to
copy
>> > interface (1) rather than (2), maybe for the specific purpose of
>> > wanting
>> > to
>> > use a Java, not a WSDL interface.
>> >
>> > Actually the code as written today does not always do the job of
>> > setting
>> > up
>> > a Java interface (if that is the goal), as the component could have a
>> > Composite impl with WSDL interface on the Composite-level
ref/service.
>> > The
>> > code setting up the binding intf (3) might really want a Java atomic
>> > component impl's Java intf to percolate up to be set on the binding.
>> > (Maybe a WSDL->Java conversion is the right thing to do here then).
>> >
>> > Anyway, I'm expanding the discussion a bit ...
>> >
>> > I need to think a bit to articulate in more detail some questions I
>> still
>> > have  ... so I'll stop here.
>> > Thanks,
>> > Scott
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > You've thought about this more than I have.. but
>> >
>> >
>> >
>> > On 7/5/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> > >
>> > > Hi, Scott.
>> > >
>> > > Thank you for bringing up this issue. I have been thinking about
this
>> > for
>> > > a
>> > > while:-).
>> > >
>> > > There are three interfaces in the picture:
>> > >
>> > > 1) [componentType.reference.interface]: The java interface of the
>> > > reference
>> > > defined by the component type, which is introspected from the
>> @Reference
>> > > annotation on the java class
>> > > (GreetingComponentImpl). This is the effective interface what the
>> > outbound
>> > > call made. For example,
>> > >
>> > > Reference declaration:
>> > > @Reference
>> > > protected HelloWorld helloWorldService;
>> > >
>> > > Reference usage:
>> > > helloWorldService.hello(...);
>> > >
>> > > 2) [component.reference.interface]: The wsdl interface that
overrides
>> > the
>> > > reference for "MyComponent". This interface is for purpose of
wiring.
>> In
>> > > most cases, the interface for
>> > > the reference on the component is the same as the one for the
>> reference
>> > on
>> > > the component type.
>> > >
>> > > 3) [component.reference.binding.interface] The wsdl interface that
>> > > the
>> > WS
>> > > binding uses, i.e., the portType for
>> > HelloWorldService/HelloWorldSoapPort.
>> > > This is the effective interface that binding layer expects to
receive
>> > > data.
>> > >
>> > > The data transformation should happen between the interface 1 and
>> > > interface
>> > > 3 (instead of 2 and 3).
>> > >
>> > > The same happens to the service side. If we have a java component,
>> > > the
>> > > interface for the service on the component type is a java
>> > interface/class.
>> > > When the component service is further typed with interface.wsdl,
then
>> > the
>> > > interface for the service on the component is a WSDL interface. But
>> the
>> > > one
>> > > for the component type should be used for data transformation
>> purposes.
>> >

Re: Website ACL

2007-07-10 Thread haleh mahbod


I'd like write access please. I have a CLA in place. Thank you.

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


Thanks Simon, this is exactly what I had in mind. Members of the
Tuscany comunity, that are not committers (yet)  but have a CLA in
place would be granted access to the Tuscany website "on request".


On 7/10/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> +1 on Simon's suggestion.
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Simon Nash" <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, July 10, 2007 12:37 PM
> Subject: Re: Website ACL
>
>
> > This ia a really huge list.  Most of these people have no connection
> > with Tuscany.  Perhaps write access could be "on request" for people
> > who have a CLA in place.
> >
> >   Simon
> >
> > P.S. I'll be sending my CLA to Apache asap :-)
> >
> > Luciano Resende 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
> >>
> >
> >
> >
> > -
> > 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]
>
>


--
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-1385) Duplicate namespace was serialized when SDO QName property value containing existing namespace

2007-07-10 Thread Fuhwei Lwo (JIRA)


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

Fuhwei Lwo updated TUSCANY-1385:


Attachment: 1385.patch

I added code to handle xsd:QName/SDO URI data format transformation based on 
the spec 2.1 for the XMLStreamHelper serialization. Although XMLStreamHelper 
does not belong to SDO 2.1 spec, I thought at least to make it functional 
without throwing exception. Please review. Thanks.

> Duplicate namespace was serialized when SDO QName property value containing 
> existing namespace
> --
>
> Key: TUSCANY-1385
> URL: https://issues.apache.org/jira/browse/TUSCANY-1385
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Fix For: Java-SDO-1.0
>
> Attachments: 1385.patch, 1385.patch, 1385.patch
>
>
> If SDO QName property has value like 
> "http://www.w3.org/2001/XMLSchema-instance#anyURI";, the serialized XML would 
> have duplicate xmlns:xsi - one from existing XML stream and the other one was 
> newly created.
> http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";

-- 
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: [TuscanySCA CPP] problems trying to load services from multiple directories at once

 
Mike,

I dug a bit more and found that the system composite is behaving as you
mentioned. Its just a container for composites found on the systemRoot
path. Each composite found on the systemRoot path is "included" in the
system composite by calling Composite::addInclude(), which also pulls
the components from the composite and adds them to the system composite.


Basically there are two options to be able to have multiple systems in
one runtime:

1. Just have one system composite that contains the composites for every
service or application.
PROS: Its all in one place, no need to know details of system
composite names.
Existing calls to SCARuntime::getSystem() will not
change (makes more sense with next option).
CONS: All composites are "mixed" together. Not sure if this
would cause any problems.

2. Make a map of system composites on the SCARuntime, moving getSystem()
to getSystem( std::string )
PROS: All composites wont be "mixed" together.
CONS: What would the map key be? And everywhere that
SCARuntime::getSystem() is called, would there
be access to that key?

Thoughts?


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


-Original Message-
From: Mike Micucci [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 3:55 PM
To: tuscany-dev@ws.apache.org
Subject: RE: [TuscanySCA CPP] problems trying to load services from
multiple directories at once

Brady,

Instead of having the system paths be set up as a colon-delimited list,
could we instead have it set up as a "root" directory, underneath which
all other dirs would be pulled in as apps?  For example, instead of
"apps/services/service1:apps/services/service2:..." could we just use
"apps/services" as a root and then each composite under that would be
pulled in as a "system"?

I can see a problem in that some composite files may include
sub-composite files, in which case we do NOT want to pull in those
sub-composite files (since they would already be read in from the main
file).  I dunno, maybe the colon delimited list is better, but it's
worth a thought, I guess.  It just seems like a colon-delimited list can
get bothersome with a large number of loaded apps.

Also, the spec says that the "system" composite isn't a real entity from
a file on disk (which suggests that the current behavior of having a
"root" composite file for all apps may need to change), but rather it
should be a "repository" which all loaded composites should reside "as
if ... containing an ".  This seems to say that we should
load up a single system object, but we can then search for composites
(either though the colon-delimited list or whatever), and then we load
them up into the system composite as "includes".  Then after than we can
resolve that composite as if it existed on disk with all of those
include directives.

This would allow us to keep a single composite for the "system" and not
have to worry about mapping multiple system composite objects.

What are your thoughts?

Thanks!

-- Michael Micucci
-- Project Team Lead - HydraSCA Agent Core Project
-- Roguewave Software - [EMAIL PROTECTED]
 
-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 10, 2007 3:22 PM
To: tuscany-dev@ws.apache.org
Subject: RE: [TuscanySCA CPP] problems trying to load services from
multiple directories at once


After reading through the 0.96 Assembly Model spec, a system is not any
one entity, but rather, to quote the spec:

"The SCA System has no single file which represents its contents. The
SCA System is a notional
entity, built from the set of composite files which are deployed into
it. The set of files is
indentified by the files being placed into a specific location ("the
system directory") in the
filesystem or repository which is used to support the SCA system. The
system directory acts as
if it is a composite containing an  element for each of the
composite files
contributed."

So what I am doing is trying to represent multiple "systems" in the same
TuscanySCA runtime, which I believe was originally intended to represent
only one system.

So the use cases as I see it are as follows:
- Single System in a single TuscanySCA runtime (existing behaviour)
- Multiple Systems in a single TuscanySCA runtime

In order to support the second use case (Multiple Systems in a single
TuscanySCA runtime) I would like to propose the following changes:
- If the systemRoot used to instantiate the runtime has colons, then
each colon seperated 
  path will be an individual system, and systemPath will have no affect.
- If systemRoot does not have colons, then the behaviour will be as is
now, and systemPath 
  may affect loading if present.
- SCARuntime can now have multiple systems, so getSystem() will be
replaced by getSystem( std::string name )
  where name is the composite/name element of the top level composite.
(How intrusive will this be?

Re: Website ACL


Thanks Simon, this is exactly what I had in mind. Members of the
Tuscany comunity, that are not committers (yet)  but have a CLA in
place would be granted access to the Tuscany website "on request".


On 7/10/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

+1 on Simon's suggestion.

Thanks,
Raymond

- Original Message -
From: "Simon Nash" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, July 10, 2007 12:37 PM
Subject: Re: Website ACL


> This ia a really huge list.  Most of these people have no connection
> with Tuscany.  Perhaps write access could be "on request" for people
> who have a CLA in place.
>
>   Simon
>
> P.S. I'll be sending my CLA to Apache asap :-)
>
> Luciano Resende 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
>>
>
>
>
> -
> 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]





--
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: [TuscanySCA CPP] problems trying to load services from multiple directories at once

2007-07-10 Thread Mike Micucci

Brady,

Instead of having the system paths be set up as a colon-delimited list,
could we instead have it set up as a "root" directory, underneath which
all other dirs would be pulled in as apps?  For example, instead of
"apps/services/service1:apps/services/service2:..." could we just use
"apps/services" as a root and then each composite under that would be
pulled in as a "system"?

I can see a problem in that some composite files may include
sub-composite files, in which case we do NOT want to pull in those
sub-composite files (since they would already be read in from the main
file).  I dunno, maybe the colon delimited list is better, but it's
worth a thought, I guess.  It just seems like a colon-delimited list can
get bothersome with a large number of loaded apps.

Also, the spec says that the "system" composite isn't a real entity from
a file on disk (which suggests that the current behavior of having a
"root" composite file for all apps may need to change), but rather it
should be a "repository" which all loaded composites should reside "as
if ... containing an ".  This seems to say that we should
load up a single system object, but we can then search for composites
(either though the colon-delimited list or whatever), and then we load
them up into the system composite as "includes".  Then after than we can
resolve that composite as if it existed on disk with all of those
include directives.

This would allow us to keep a single composite for the "system" and not
have to worry about mapping multiple system composite objects.

What are your thoughts?

Thanks!

-- Michael Micucci
-- Project Team Lead - HydraSCA Agent Core Project
-- Roguewave Software - [EMAIL PROTECTED]
 
-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 3:22 PM
To: tuscany-dev@ws.apache.org
Subject: RE: [TuscanySCA CPP] problems trying to load services from
multiple directories at once


After reading through the 0.96 Assembly Model spec, a system is not any
one entity, but rather, to quote the spec:

"The SCA System has no single file which represents its contents. The
SCA System is a notional
entity, built from the set of composite files which are deployed into
it. The set of files is
indentified by the files being placed into a specific location ("the
system directory") in the
filesystem or repository which is used to support the SCA system. The
system directory acts as
if it is a composite containing an  element for each of the
composite files
contributed."

So what I am doing is trying to represent multiple "systems" in the same
TuscanySCA runtime, which I believe was originally intended to represent
only one system.

So the use cases as I see it are as follows:
- Single System in a single TuscanySCA runtime (existing behaviour)
- Multiple Systems in a single TuscanySCA runtime

In order to support the second use case (Multiple Systems in a single
TuscanySCA runtime) I would like to propose the following changes:
- If the systemRoot used to instantiate the runtime has colons, then
each colon seperated 
  path will be an individual system, and systemPath will have no affect.
- If systemRoot does not have colons, then the behaviour will be as is
now, and systemPath 
  may affect loading if present.
- SCARuntime can now have multiple systems, so getSystem() will be
replaced by getSystem( std::string name )
  where name is the composite/name element of the top level composite.
(How intrusive will this be???)
- There will also have to be a new method to get the system names:
std::list SCARuntime::getSystemNames()


Thoughts anyone?


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


-Original Message-
From: Mike Micucci [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 11:35 AM
To: tuscany-dev@ws.apache.org
Subject: RE: [TuscanySCA CPP] problems trying to load services from
multiple directories at once

Brady,

I'm a little unclear on how system composites are supposed to work.
When I first went through the composite loading code I got the
impression that a system composite was meant to list all the services
for an entire server (i.e. a "root" composite).  Is that the case?  Or
is a "system composite" meant for a particular service (hence we'd
expect to see multiple "system composites" in a particular Tuscany
setup)?

With the latter, I think your proposal makes sense.  Personally, I'd
rather see the loading of the composites done via a stronger API than
setting up an environment variable (an API or a direct option mechanism
has the advantage of being checked and having better error
messages/diagnostics), but this way may be simpler and more
straightforward.  In this case, it sounds like we can maybe even
eliminate the need for a separate environment variable.

If a system composite is meant for an entire server then we may have to
slightly alter the composite loading mechanism if we want to allow
multiple dif

RE: [TuscanySCA CPP] problems trying to load services from multiple directories at once


After reading through the 0.96 Assembly Model spec, a system is not any
one entity, but rather, to quote the spec:

"The SCA System has no single file which represents its contents. The
SCA System is a notional
entity, built from the set of composite files which are deployed into
it. The set of files is
indentified by the files being placed into a specific location ("the
system directory") in the
filesystem or repository which is used to support the SCA system. The
system directory acts as
if it is a composite containing an  element for each of the
composite files
contributed."

So what I am doing is trying to represent multiple "systems" in the same
TuscanySCA runtime, which I believe was originally intended to represent
only one system.

So the use cases as I see it are as follows:
- Single System in a single TuscanySCA runtime (existing behaviour)
- Multiple Systems in a single TuscanySCA runtime

In order to support the second use case (Multiple Systems in a single
TuscanySCA runtime) I would like to propose the following changes:
- If the systemRoot used to instantiate the runtime has colons, then
each colon seperated 
  path will be an individual system, and systemPath will have no affect.
- If systemRoot does not have colons, then the behaviour will be as is
now, and systemPath 
  may affect loading if present.
- SCARuntime can now have multiple systems, so getSystem() will be
replaced by getSystem( std::string name )
  where name is the composite/name element of the top level composite.
(How intrusive will this be???)
- There will also have to be a new method to get the system names:
std::list SCARuntime::getSystemNames()


Thoughts anyone?


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


-Original Message-
From: Mike Micucci [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 11:35 AM
To: tuscany-dev@ws.apache.org
Subject: RE: [TuscanySCA CPP] problems trying to load services from
multiple directories at once

Brady,

I'm a little unclear on how system composites are supposed to work.
When I first went through the composite loading code I got the
impression that a system composite was meant to list all the services
for an entire server (i.e. a "root" composite).  Is that the case?  Or
is a "system composite" meant for a particular service (hence we'd
expect to see multiple "system composites" in a particular Tuscany
setup)?

With the latter, I think your proposal makes sense.  Personally, I'd
rather see the loading of the composites done via a stronger API than
setting up an environment variable (an API or a direct option mechanism
has the advantage of being checked and having better error
messages/diagnostics), but this way may be simpler and more
straightforward.  In this case, it sounds like we can maybe even
eliminate the need for a separate environment variable.

If a system composite is meant for an entire server then we may have to
slightly alter the composite loading mechanism if we want to allow
multiple different services to be available.  From what little bit I
know though, this sounds unlikely so hopefully your change will work
out.

Thanks!

-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 10, 2007 10:26 AM
To: tuscany-dev@ws.apache.org
Subject: RE: [TuscanySCA CPP] problems trying to load services from
multiple directories at once


I think I figured out how to make this work, but I don't think it's the
intended usage.

If I set TUSCANY_SCACPP_SYSTEM_ROOT to:
"~/tuscany/services/serviceA:~/tuscany/services/serviceB"
And leave TUSCANY_SCACPP_SYSTEM_PATH blank, then I get all of the
services loaded. Its not loaded as intended though, since what it does
is populate the SCARuntime::system composite with the system composites
from serviceA and serviceB. Does that seem correct?


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


-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 10:17 AM
To: tuscany-dev@ws.apache.org
Subject: RE: [TuscanySCA CPP] problems trying to load services from
multiple directories at once


I have since updated the JIRA with a clarification of what I am trying
to do and have included it here in  tags.



Just to clarify one piece of information about this problem:

serviceA and serviceB are totally unrelated. The system composites are
located as follows:

~/tuscany/services/
 |
 +->serviceA/serviceA.composite
 |
 +->serviceB/serviceB.composite  



Seems like the problem is that the SCARuntime was designed towards just
having one service loaded at a time. And what I am trying to do is to be
able to load several unrelated services.



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

-Original Message-
From:

Re: Website ACL

2007-07-10 Thread Raymond Feng

+1 on Simon's suggestion.

Thanks,
Raymond

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

To: 
Sent: Tuesday, July 10, 2007 12:37 PM
Subject: Re: Website ACL

This ia a really huge list.  Most of these people have no connection
with Tuscany.  Perhaps write access could be "on request" for people
who have a CLA in place.

  Simon

P.S. I'll be sending my CLA to Apache asap :-)

Luciano Resende 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

-
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: Runtime access to sdoJava:package

2007-07-10 Thread Pinaki Poddar

Hi Frank,
  Here is what I am after:
1. Input: XML Definition of SDO types
2. Create+Populate a DataGraph X compliant to the SDO Types
3. Get a 'SDO-enabled' JPA EntityManager, em
4. em.persist(X)
5. All the data should be persisted in a RDBMS

More about this in
http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/07/persisting_ser
v.html

To do this, I need Java classes corresponding to SDO Types, because JPA
works well with strongy-typed Java classes. These Java classes are
generated on-the-fly by a byte code generation library. While it is not
*important* for the dynamically generated Java classes to have package
names, it just a Java-habit to add a package name:) 
I understand the non-kosher nature of things and according to your
advice, encapsulated the package name extraction such that it does not
statically depend on EMF. If possible it will get me a package name
otherwise dynamically generated Java classes will remain in default
name-less package. 

 Thanks to you and this user group for help --


Pinaki Poddar
972.834.2865

-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 1:25 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Runtime access to sdoJava:package

Hi Pinaki,

As you said, what you're doing isn't very kosher. First, you shouldn't
rely on EMF behavior, because it's subject to change and second, the
EPackage name isn't always the same as the Java package, even though it
is when sdoJava:package is specified. I don't really understand why you
want this value anyway. It's only purpose (see SDO spec) is for the code
generator to determine the java package for generated interfaces. It's
meaningless information if you don't generate static SDOs, and if you do
generate them, then getInstanceClass() will be non-null and you can get
the value from it.

Frank

"Pinaki Poddar" <[EMAIL PROTECTED]> wrote on 07/10/2007 12:43:04 PM:

> Hi,
>  Thanks for your help.
> 
>  When the only input is a XML Schema, and SDO types are defined via: 
>   List types = XSDHelper.INSTANCE.define(xsdInputStream,
> schemaLocation);
>  The resultant types have non-null getInstanceClass() only when 
> type.isDataType()==true.
> 
>  However, I have figured a way to access the sdoJava:package. May not 
> be kosher but here it is:
> 
> 
>  Runtime class of commonj.sdo.Type is
> org.apache.tuscany.sdo.impl.ClassImpl.
>  This runtime class will reveal the underlying EMF implementaion's 
> Epackage.
> 
> 
> 
>  For example, if 'po.xsd' defines a type named 'USAddress' and 
> declares sdoJava:package="com.acme.foo", then following test will
pass:
> 
>public void testPackageNameIsAvailableViaDowncast() {
>   Type addressType = getType("USAddress");
>   assertTrue(addressType instanceof ClassImpl);
> 
> assertEquals("com.acme.foo",((ClassImpl)addressType).getEPackage().get
> Na
> me());
>}
> 
> And following tests will pass too: 
> 
>public void testInstanceClassIsNullForUserType() {
>   Type addressType = getType("USAddress");
>   assertFalse(addressType.isDataType());
>   assertNull(addressType.getInstanceClass());
>}
> 
>public void testInstanceClassIsNotNullForDataType() {
>   Type skuType = getType("SKU");
>   assertTrue(skuType.isDataType());
>   assertNotNull(skuType.getInstanceClass());
>}
> 
> 
> Pinaki Poddar
> 972.834.2865
> 
> -Original Message-
> From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 10, 2007 7:55 AM
> To: tuscany-dev@ws.apache.org
> Subject: RE: Runtime access to sdoJava:package
> 
> Given a Type, you can call type.getInstanceClass() and if it's not 
> null, the package name can be retrieved from the Class. If the 
> instanceClass is null, there is no static class, and hence no package
for the type.
> 
> Frank.
> 
> "Pinaki Poddar" <[EMAIL PROTECTED]> wrote on 07/09/2007 05:53:21 PM:
> 
> > Thanks Fuhwei.
> > 
> > But the underlying EMF Ecore allowed a path to do the same -- at 
> > least
> 
> > as far I can see in my debugger.
> > 
> > In a implementation that is based upon another impl -- it often 
> > helps to make the underlying impl available via 'public Object 
> > getDelegate();' or some such method. Is there any such 
> > under-the-hood way to get hold of EMF impl classes in Tuscany's SDO 
> > impl -- even it does require me to cast to specific impl from the 
> > commonj.sdo API
> instances.
> > 
> > 
> > Pinaki Poddar
> > 972.834.2865
> > 
> > -Original Message-
> > From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 09, 2007 4:46 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: Runtime access to sdoJava:package
> > 
> > Hi Pinaki,
> > 
> > sdoJava:package is only used by the users to control what Java 
> > package
> 
> > name should be generated during the generation of static SDO APIs. I

> > don't think its info can be accessed from the standard SDO APIs.
> > 
> > Fuhwei
> > 
> > Pinaki Poddar <[EMAIL PROTECTED]> wrote: Hello, a

Re: Website ACL

2007-07-10 Thread Simon Nash


This ia a really huge list.  Most of these people have no connection
with Tuscany.  Perhaps write access could be "on request" for people
who have a CLA in place.

  Simon

P.S. I'll be sending my CLA to Apache asap :-)

Luciano Resende 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





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

RE: Runtime access to sdoJava:package

2007-07-10 Thread Frank Budinsky

Hi Pinaki,

As you said, what you're doing isn't very kosher. First, you shouldn't 
rely on EMF behavior, because it's subject to change and second, the 
EPackage name isn't always the same as the Java package, even though it is 
when sdoJava:package is specified. I don't really understand why you want 
this value anyway. It's only purpose (see SDO spec) is for the code 
generator to determine the java package for generated interfaces. It's 
meaningless information if you don't generate static SDOs, and if you do 
generate them, then getInstanceClass() will be non-null and you can get 
the value from it.

Frank

"Pinaki Poddar" <[EMAIL PROTECTED]> wrote on 07/10/2007 12:43:04 PM:

> Hi,
>  Thanks for your help.
> 
>  When the only input is a XML Schema, and SDO types are defined via: 
>   List types = XSDHelper.INSTANCE.define(xsdInputStream,
> schemaLocation); 
>  The resultant types have non-null getInstanceClass() only when
> type.isDataType()==true. 
> 
>  However, I have figured a way to access the sdoJava:package. May not be
> kosher but here it is:
> 
> 
>  Runtime class of commonj.sdo.Type is
> org.apache.tuscany.sdo.impl.ClassImpl.
>  This runtime class will reveal the underlying EMF implementaion's
> Epackage.
> 
> 
> 
>  For example, if 'po.xsd' defines a type named 'USAddress' and declares
> sdoJava:package="com.acme.foo", then following test will pass:
> 
>public void testPackageNameIsAvailableViaDowncast() {
>   Type addressType = getType("USAddress");
>   assertTrue(addressType instanceof ClassImpl);
> 
> assertEquals("com.acme.foo",((ClassImpl)addressType).getEPackage().getNa
> me());
>}
> 
> And following tests will pass too: 
> 
>public void testInstanceClassIsNullForUserType() {
>   Type addressType = getType("USAddress");
>   assertFalse(addressType.isDataType());
>   assertNull(addressType.getInstanceClass());
>}
> 
>public void testInstanceClassIsNotNullForDataType() {
>   Type skuType = getType("SKU");
>   assertTrue(skuType.isDataType());
>   assertNotNull(skuType.getInstanceClass());
>}
> 
> 
> Pinaki Poddar
> 972.834.2865
> 
> -Original Message-
> From: Frank Budinsky [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, July 10, 2007 7:55 AM
> To: tuscany-dev@ws.apache.org
> Subject: RE: Runtime access to sdoJava:package
> 
> Given a Type, you can call type.getInstanceClass() and if it's not null,
> the package name can be retrieved from the Class. If the instanceClass
> is null, there is no static class, and hence no package for the type.
> 
> Frank.
> 
> "Pinaki Poddar" <[EMAIL PROTECTED]> wrote on 07/09/2007 05:53:21 PM:
> 
> > Thanks Fuhwei.
> > 
> > But the underlying EMF Ecore allowed a path to do the same -- at least
> 
> > as far I can see in my debugger.
> > 
> > In a implementation that is based upon another impl -- it often helps 
> > to make the underlying impl available via 'public Object 
> > getDelegate();' or some such method. Is there any such under-the-hood 
> > way to get hold of EMF impl classes in Tuscany's SDO impl -- even it 
> > does require me to cast to specific impl from the commonj.sdo API
> instances.
> > 
> > 
> > Pinaki Poddar
> > 972.834.2865
> > 
> > -Original Message-
> > From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 09, 2007 4:46 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: Runtime access to sdoJava:package
> > 
> > Hi Pinaki,
> > 
> > sdoJava:package is only used by the users to control what Java package
> 
> > name should be generated during the generation of static SDO APIs. I 
> > don't think its info can be accessed from the standard SDO APIs.
> > 
> > Fuhwei
> > 
> > Pinaki Poddar <[EMAIL PROTECTED]> wrote: Hello, a newbie question:
> > 1. *.xsd has declared 
> >  sdoJava:package="com.acme.mydomain" 
> > 
> > 2. With XSDHelper.INSTANCE (or with some other helper)
> >how does one programatically access the package name 
> > "com.acme.mydomain"?
> > 
> > A more general question,
> > does SDO Type has a 'package' notion or such notion is only valid if 
> > SDO Type is converted to Java Class?
> > 
> > Thanks
> > 
> > 
> > Pinaki Poddar
> > 972.834.2865
> > 
> > 
> > Notice:  This email message, together with any attachments, may 
> > contain information  of  BEA Systems,  Inc.,  its subsidiaries  and 
> > affiliated entities,  that may be confidential,  proprietary, 
> > copyrighted  and/or legally privileged, and is intended solely for the
> 
> > use of the individual or entity named in this message. If you are not 
> > the intended recipient, and have received this message in error, 
> > please immediately return this by email and then delete it.
> > 
> > Notice:  This email message, together with any attachments, may 
> > contain information  of  BEA Systems,  Inc.,  its subsidiaries  and 
> > affiliated entities,  that may be confidential,  proprietary, 
> > copyrighted  and/or legally privileged, and is intended solely for the
> 
> > use of

[jira] Commented: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization

2007-07-10 Thread Fuhwei Lwo (JIRA)


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

Fuhwei Lwo commented on TUSCANY-1317:
-

Once we are ready, we need to remove JIRA-1317 comments in the patch. We need 
to close down this one as quickly as possible because it involves changes on 
many files. Let me know how I can help. Thanks.

> Provide a way to set default XML load options to be used during Java 
> deserialization
> 
>
> Key: TUSCANY-1317
> URL: https://issues.apache.org/jira/browse/TUSCANY-1317
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1, Java-SDO-1.0
>Reporter: Daniel Peter
> Fix For: Java-SDO-1.0
>
> Attachments: 1317.patch, 1317.patch, 1317.patch, 1317.patch, 
> 1317.patch, 1317.patch, JIRA1317Design.txt, JIRA1317Design.txt, 
> JIRA1317Design.txt, JIRA1317Design.txt, JIRA_1317_June21.txt, 
> JIRA_1317_June25_Amita.txt
>
>
> XML load options can be passed when calling the XMLHelper.load(...) methods. 
> But there is currently no way to pass such load options to be used during 
> Java deserialization.
> Thus a way to set default load options should be provided, e.g. 
> SDOUtil.setDefaultXMLOptions(HelperContext, Object options)
> These default options could then be picked up during Java deserialization, 
> i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl.
> Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be 
> exposed in Tuscany SDO.

-- 
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-1317) Provide a way to set default XML load options to be used during Java deserialization

2007-07-10 Thread Fuhwei Lwo (JIRA)


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

Fuhwei Lwo updated TUSCANY-1317:


Attachment: 1317.patch

I cleaned up Amita's latest 1317.patch and re-uploaded it. Please review. 
Thanks.

> Provide a way to set default XML load options to be used during Java 
> deserialization
> 
>
> Key: TUSCANY-1317
> URL: https://issues.apache.org/jira/browse/TUSCANY-1317
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1, Java-SDO-1.0
>Reporter: Daniel Peter
> Fix For: Java-SDO-1.0
>
> Attachments: 1317.patch, 1317.patch, 1317.patch, 1317.patch, 
> 1317.patch, 1317.patch, JIRA1317Design.txt, JIRA1317Design.txt, 
> JIRA1317Design.txt, JIRA1317Design.txt, JIRA_1317_June21.txt, 
> JIRA_1317_June25_Amita.txt
>
>
> XML load options can be passed when calling the XMLHelper.load(...) methods. 
> But there is currently no way to pass such load options to be used during 
> Java deserialization.
> Thus a way to set default load options should be provided, e.g. 
> SDOUtil.setDefaultXMLOptions(HelperContext, Object options)
> These default options could then be picked up during Java deserialization, 
> i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl.
> Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be 
> exposed in Tuscany SDO.

-- 
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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback

2007-07-10 Thread 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
> 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]

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

2007-07-10 Thread 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

corrected some comments in the test case code

> 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
> 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: [VOTE] Release Tuscany Java DAS beta1 (RC2)

Thanks, some comments inline.

On 7/10/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

Hi,

Here are my observations on this RC.

1) The source builds successfully from a clean maven repo
- Notice, Disclaimer and License files missing from source 'rdb' module.

These files are in the jar meta-inf.

2) Trying the samples
a) I see that the source has two additional directories 'testing' and
'dbconfig' which are not there in binary distro. Maybe we must make it
clear that this applies only if one is using the source distro.

What's your suggestion here ? Also, for clarification, dbConfig is the
utility embedded on some DAS sample apps (web-inf\lib) to create the
canned databases. The testing\tomcat project is what we have as DAS
Integration test using Tomcat.

b) RDB DAS Sample (companyweb)
- should we change that title to RDB DAS CompanyWeb Sample.
- Readme
- the section "Running from Tomcat configured by the 
build" has
information that cannot be related to with the binary distro.  There
is a mention of 'testing' module within samples and also the paths
seem to be related to the svn structure.
(java/das/samples/testing/tomcat/readme.htm)
- the section "Deploying the CompanyWeb WAR into a 
Tomcat you
configure yourself" talks about a 'sample distribution' - and I don't
think we have one. Do we ?

No, it's now under the binary distro.

- furtheron there is mention about copying 
derby.jar but
I see it in the war as well.
- and then in "Install the canned Derby database to 
Tomcat", i
really cannot figure out where datatest directory is.

This was noted by Amita too, this step is obsolet.

- I really think this readme needs a overhaul or I am 
grossly
missing something.
c) RDB DAS Customer Sample runs clean as mentioned in the readme
- Section "Running from Tomcat configured by the build" may 
need to
mention that it applies only to src distro
- there is a mention of 'sample distribution' which we don't 
have
- about copying derby.jar to tomcat lib I guess its common/lib 
for
tomcat 5.x and just 'lib' for tomcat 6.x
- I was able to deploy to the war to tomcat, I copied over the
derby-10.1.2.1.jar that I found in the war to the lib directory and
was able to run the sample successfully.  I tried the adhoc queries
and they seemed to work fine for me.

3) License and Notice : I find licenses are in place.  In the notice
there is mention of using software developed by OSOA.  Did not quite
find anything from osoa.

SDO Spec jar is based on the OSOA license. I might need to add the jar
file as the line below.

License for the Service Data Objects JavaDoc and Interface Definition
files. (sdo-api-r2.0.1-1.0-incubator-M2.jar)

So, overall its about the READMEs for the samples that need some
fixing.  Even there the customer and ajax samples can be worked out
with the current READMEs - with the Ajax sample really give a feel
that DAS works.  So I really cannot see a blocker with this.

Here is my +1.

Thanks.

- Venkat

On 7/10/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 should now be fixed.
>
> The Release Candidate RC2 for Tuscany Java DAS beta1 is available at
>
>   http://people.apache.org/~lresende/tuscany/das-beta1-rc2/
>
> Release Notes are available at
>   
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc2/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-rc2/maven/
>
> The release audit tool (rat) results are available at
>
>   
http://people.apache.org/~lresende/tuscany/das-beta1-rc2/das-beta1-rc2-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-rc2/
>
> 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]

--
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: [TuscanySCA CPP] problems trying to load services from multiple directories at once

2007-07-10 Thread Mike Micucci

Brady,

I'm a little unclear on how system composites are supposed to work.
When I first went through the composite loading code I got the
impression that a system composite was meant to list all the services
for an entire server (i.e. a "root" composite).  Is that the case?  Or
is a "system composite" meant for a particular service (hence we'd
expect to see multiple "system composites" in a particular Tuscany
setup)?

With the latter, I think your proposal makes sense.  Personally, I'd
rather see the loading of the composites done via a stronger API than
setting up an environment variable (an API or a direct option mechanism
has the advantage of being checked and having better error
messages/diagnostics), but this way may be simpler and more
straightforward.  In this case, it sounds like we can maybe even
eliminate the need for a separate environment variable.

If a system composite is meant for an entire server then we may have to
slightly alter the composite loading mechanism if we want to allow
multiple different services to be available.  From what little bit I
know though, this sounds unlikely so hopefully your change will work
out.

Thanks!

-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 10:26 AM
To: tuscany-dev@ws.apache.org
Subject: RE: [TuscanySCA CPP] problems trying to load services from
multiple directories at once

I think I figured out how to make this work, but I don't think it's the
intended usage.

If I set TUSCANY_SCACPP_SYSTEM_ROOT to:
"~/tuscany/services/serviceA:~/tuscany/services/serviceB"
And leave TUSCANY_SCACPP_SYSTEM_PATH blank, then I get all of the
services loaded. Its not loaded as intended though, since what it does
is populate the SCARuntime::system composite with the system composites
from serviceA and serviceB. Does that seem correct?

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

-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 10:17 AM
To: tuscany-dev@ws.apache.org
Subject: RE: [TuscanySCA CPP] problems trying to load services from
multiple directories at once

I have since updated the JIRA with a clarification of what I am trying
to do and have included it here in  tags.

Just to clarify one piece of information about this problem:

serviceA and serviceB are totally unrelated. The system composites are
located as follows:

~/tuscany/services/
 |
 +->serviceA/serviceA.composite
 |
 +->serviceB/serviceB.composite  

Seems like the problem is that the SCARuntime was designed towards just
having one service loaded at a time. And what I am trying to do is to be
able to load several unrelated services.

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

-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 10, 2007 9:42 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [TuscanySCA CPP] problems trying to load services from
multiple directories at once

I think that them intent is for any composites under the
TUSCANY_SCACPP_SYSTEM_ROOT to be loaded so I think it may be an error to
specify a _PATH that includes or is a subdirectory of the SYSTEM_ROOT.
Maybe we could police this or change the loader to ignore duplicates
from the same location.??

On 10/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I created a JIRA for this issue:
>https://issues.apache.org/jira/browse/TUSCANY-1418
>
>  Im trying to start the Tuscany SCA runtime so that it loads several 
> service directories at once. Im assuming that this should be achieved 
> by using the systemPath argument of the
> SCARuntime::initializeSharedRuntime() method. Im also assuming that 
> the systemPath should be a ":" (colon) or ";" (semi-colon) seperated 
> list of directories, each of which is a separate SCA service 
> directory.
>
> If my assumptions are correct, then what purpose does the systemRoot 
> paramater serve when systemPath is specified?
> In the call to ModelLoader::load(), if systemPath is specified, then 
> the following call is made:
>ModelLoader::loadComposites(systemRoot + PATH_SEPARATOR + 
> systemPath);
>
> So lets assume that systemRoot is "~/tuscany/services" and systemPath 
> is "~/tuscany/services/serviceA:~/tuscany/services/serviceB"
> Then ModelLoader::loadComposites() will be called with this string:
>
> "~/tuscany/services:~/tuscany/services/serviceA:~/tuscany/services/ser
> vi
> ceB"
> Since the Files() constructor in loadComposites has the subdirectories

> parameter set to true, the directories will be traversed as follows:
> 1. everything under "~/tuscany/services" (including serviceA and
> serviceB)
> 2. everything under "~/tuscany/services/serviceA"
> 3. everything under "~/tuscany/services/serviceB"
>
> This is problematic since the services ge

RE: Runtime access to sdoJava:package

2007-07-10 Thread Pinaki Poddar

Hi,
 Thanks for your help.

 When the only input is a XML Schema, and SDO types are defined via: 
  List types = XSDHelper.INSTANCE.define(xsdInputStream,
schemaLocation); 
 The resultant types have non-null getInstanceClass() only when
type.isDataType()==true. 
 
 However, I have figured a way to access the sdoJava:package. May not be
kosher but here it is:


 Runtime class of commonj.sdo.Type is
org.apache.tuscany.sdo.impl.ClassImpl.
 This runtime class will reveal the underlying EMF implementaion's
Epackage.

 

 For example, if 'po.xsd' defines a type named 'USAddress' and declares
sdoJava:package="com.acme.foo", then following test will pass:

public void testPackageNameIsAvailableViaDowncast() {
Type addressType = getType("USAddress");
assertTrue(addressType instanceof ClassImpl);

assertEquals("com.acme.foo",((ClassImpl)addressType).getEPackage().getNa
me());
}

And following tests will pass too: 

public void testInstanceClassIsNullForUserType() {
Type addressType = getType("USAddress");
assertFalse(addressType.isDataType());
assertNull(addressType.getInstanceClass());
}

public void testInstanceClassIsNotNullForDataType() {
Type skuType = getType("SKU");
assertTrue(skuType.isDataType());
assertNotNull(skuType.getInstanceClass());
}
   

Pinaki Poddar
972.834.2865

-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 7:55 AM
To: tuscany-dev@ws.apache.org
Subject: RE: Runtime access to sdoJava:package

Given a Type, you can call type.getInstanceClass() and if it's not null,
the package name can be retrieved from the Class. If the instanceClass
is null, there is no static class, and hence no package for the type.

Frank.

"Pinaki Poddar" <[EMAIL PROTECTED]> wrote on 07/09/2007 05:53:21 PM:

> Thanks Fuhwei.
> 
> But the underlying EMF Ecore allowed a path to do the same -- at least

> as far I can see in my debugger.
> 
> In a implementation that is based upon another impl -- it often helps 
> to make the underlying impl available via 'public Object 
> getDelegate();' or some such method. Is there any such under-the-hood 
> way to get hold of EMF impl classes in Tuscany's SDO impl -- even it 
> does require me to cast to specific impl from the commonj.sdo API
instances.
> 
> 
> Pinaki Poddar
> 972.834.2865
> 
> -Original Message-
> From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 09, 2007 4:46 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Runtime access to sdoJava:package
> 
> Hi Pinaki,
> 
> sdoJava:package is only used by the users to control what Java package

> name should be generated during the generation of static SDO APIs. I 
> don't think its info can be accessed from the standard SDO APIs.
> 
> Fuhwei
> 
> Pinaki Poddar <[EMAIL PROTECTED]> wrote: Hello, a newbie question:
> 1. *.xsd has declared 
>  sdoJava:package="com.acme.mydomain" 
> 
> 2. With XSDHelper.INSTANCE (or with some other helper)
>how does one programatically access the package name 
> "com.acme.mydomain"?
> 
> A more general question,
> does SDO Type has a 'package' notion or such notion is only valid if 
> SDO Type is converted to Java Class?
> 
> Thanks
> 
> 
> Pinaki Poddar
> 972.834.2865
> 
> 
> Notice:  This email message, together with any attachments, may 
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
> affiliated entities,  that may be confidential,  proprietary,  
> copyrighted  and/or legally privileged, and is intended solely for the

> use of the individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in error, 
> please immediately return this by email and then delete it.
> 
> Notice:  This email message, together with any attachments, may 
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and 
> affiliated entities,  that may be confidential,  proprietary, 
> copyrighted  and/or legally privileged, and is intended solely for the

> use of the individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in error, 
> please immediately return this by email and then delete it.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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


Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the indiv

Re: Build problems


You might be hitting the same issue as reported by Simon Laws [1]. But
I'm not sure what is the solution at the moment. Maybe remove the
package from your local repo or try to mvn -U.

[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19676.html

On 7/10/07, Graham Charters <[EMAIL PROTECTED]> wrote:

Hi Raymond,

Thanks for the quick response.  I tried "mvn clean install" and I'm
still seeing the problem caused by the bad codegen-ecore-2.2.3.jar. It
results in lots of errors to do with missing package
org.eclipse.emf.codegen.ecore.genmodel.

Regards, Graham.

On 10/07/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Please run "mvn clean install".
>
> Thanks,
> Raymond
> - Original Message -
> From: "Graham Charters" <[EMAIL PROTECTED]>
> To: "tuscany-dev" 
> Sent: Tuesday, July 10, 2007 8:56 AM
> Subject: Build problems
>
>
> > Hi,
> >
> > I'm trying to build Tuscany Java and have hit a couple of problems.
> > I've started with a clean repository, and checked out the latest from
> > svn (a few times throughout July 9th/10th).  When I do mvn at the top
> > level, I get a test case failure with the following exception:
> >
> > 
testTransformation(org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase)
> > Time elapsed: 0.031 sec  <<< ERROR!
> > java.lang.IncompatibleClassChangeError:
> > 
org/apache/tuscany/sca/databinding/impl/SimpleTypeMapperImpl.getXMLType(Ljava/lang/Class;)Lorg/apach
> > e/tuscany/sca/interfacedef/util/TypeInfo;
> >at
> > 
org.apache.tuscany.sca.databinding.xml.BeanUtil.isSimpleType(BeanUtil.java:49)
> >at
> > 
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:100)
> >at
> > 
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:184)
> >at
> > 
org.apache.tuscany.sca.databinding.javabeans.JavaBean2XMLStreamReader.transform(JavaBean2XMLStreamReader.java:35)
> >at
> > 
org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase.testTransformation(JavaBean2XMLStreamReaderTestCase.java:
> > 43)
> >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.TestCase.runTest(TestCase.java:168)
> >at junit.framework.TestCase.runBare(TestCase.java:134)
> >at junit.framework.TestResult$1.protect(TestResult.java:110)
> >at junit.framework.TestResult.runProtected(TestResult.java:128)
> >at junit.framework.TestResult.run(TestResult.java:113)
> >at junit.framework.TestCase.run(TestCase.java:124)
> >at junit.framework.TestSuite.runTest(TestSuite.java:232)
> >at junit.framework.TestSuite.run(TestSuite.java:227)
> >at
> > 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
> >at
> > 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> >at
> > 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
> >at
> > 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
> >at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
> >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >at
> > 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> >at
> > 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >at java.lang.reflect.Method.invoke(Method.java:615)
> >at
> > 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
> >at
> > 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
> >
> > When I try to build Eclipse projects using "mvn -Peclipse
> > eclipse:eclipse" I get the following exception:
> >
> > [INFO] [tuscany-sdo:generate {execution: generate-po-sdo}]
> > [INFO] Generating SDO interfaces from
> > 
C:\temp\LAMP\Eclipse-3.2.1\eclipse\workspaces\osgi\Tuscany\sca\modules\databinding-sdo\src\test\resour
> > ces\ipo.xsd
> > [INFO] 

> > [ERROR] FATAL ERROR
> > [INFO] 

> > [INFO] org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
> > [INFO] 

> > [INFO] Trace
> > java.lang.NoClassDefFoundError:
> > org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
> >at
> > 
org.apache.tuscany.sdo.generate.JavaGenerator.ecore2GenModel(JavaGenerator.java:540)
> >at
> > 
org.apache.tuscany.sdo.ge

Re: Please apply reworked patch for TUSCANY-1341

2007-07-10 Thread Raymond Feng


Hi,

Sorry for the delay. I'll try to apply it today.

Thanks,
Raymond

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

To: 
Sent: Monday, July 09, 2007 6:08 AM
Subject: Re: Please apply reworked patch for TUSCANY-1341



Could someone take a look at this patch, please?  I'd like to
continue on with the next part of the callback work (using the
correct WS-Addressing pattern) but I don't think it makes sense
for me to do this until the first stage (the current patch) is
in place in the trunk.  I'd be pleased to answer any questions
about the details of the changes that I made.

  Simon

Simon Nash wrote:


Please review and apply the reworked patch for TUSCANY-1341.  This
patch does not include any breaking SPI changes.  I have attached the
patch to the JIRA in 4 parts as follows.

jira1341-take2-newfiles.zip contains 3 new interfaces:

sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/CallbackBinding.java 
sca/modules/core-spi/src/main/java/org/apache/tuscany/sca/provider/ReferenceBindingProvider2.java 
sca/modules/core-spi/src/main/java/org/apache/tuscany/sca/provider/ServiceBindingProvider2.java 
These files must be added before applying jira1341-take2-patch1.

These files must be added before applying jira1341-take2-patch1.

jira1341-take2-patch1 contains changes to the core runtime to enable
callback support. Before applying this patch, the new files in
jira1341-take2-newfiles.zip must be added. This patch must be applied
before applying jira1341-take2-patch2.

jira1341-take2-patch2 contains changes to the Axis2 Web Service binding
to enable callback support. Before applying this patch,
jira1341-take2-patch1 must be applied. This patch must be applied before
applying jira1341-take2-patch3.

jira1341-take2-patch3 updates the samples pom.xml and README to include
the simple-callback-ws sample in the build. This sample shows how to use
callbacks across the Web Service binding. Before applying this patch,
jira1341-take2-patch2 must be applied.

  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]

Website ACL


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: Build problems

2007-07-10 Thread Graham Charters


Hi Raymond,

Thanks for the quick response.  I tried "mvn clean install" and I'm
still seeing the problem caused by the bad codegen-ecore-2.2.3.jar. It
results in lots of errors to do with missing package
org.eclipse.emf.codegen.ecore.genmodel.

Regards, Graham.

On 10/07/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi,

Please run "mvn clean install".

Thanks,
Raymond
- Original Message -
From: "Graham Charters" <[EMAIL PROTECTED]>
To: "tuscany-dev" 
Sent: Tuesday, July 10, 2007 8:56 AM
Subject: Build problems


> Hi,
>
> I'm trying to build Tuscany Java and have hit a couple of problems.
> I've started with a clean repository, and checked out the latest from
> svn (a few times throughout July 9th/10th).  When I do mvn at the top
> level, I get a test case failure with the following exception:
>
> 
testTransformation(org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase)
> Time elapsed: 0.031 sec  <<< ERROR!
> java.lang.IncompatibleClassChangeError:
> 
org/apache/tuscany/sca/databinding/impl/SimpleTypeMapperImpl.getXMLType(Ljava/lang/Class;)Lorg/apach
> e/tuscany/sca/interfacedef/util/TypeInfo;
>at
> org.apache.tuscany.sca.databinding.xml.BeanUtil.isSimpleType(BeanUtil.java:49)
>at
> 
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:100)
>at
> 
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:184)
>at
> 
org.apache.tuscany.sca.databinding.javabeans.JavaBean2XMLStreamReader.transform(JavaBean2XMLStreamReader.java:35)
>at
> 
org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase.testTransformation(JavaBean2XMLStreamReaderTestCase.java:
> 43)
>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.TestCase.runTest(TestCase.java:168)
>at junit.framework.TestCase.runBare(TestCase.java:134)
>at junit.framework.TestResult$1.protect(TestResult.java:110)
>at junit.framework.TestResult.runProtected(TestResult.java:128)
>at junit.framework.TestResult.run(TestResult.java:113)
>at junit.framework.TestCase.run(TestCase.java:124)
>at junit.framework.TestSuite.runTest(TestSuite.java:232)
>at junit.framework.TestSuite.run(TestSuite.java:227)
>at
> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>at
> 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
>at
> 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
>at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>at
> 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:615)
>at
> 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
>at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
>
> When I try to build Eclipse projects using "mvn -Peclipse
> eclipse:eclipse" I get the following exception:
>
> [INFO] [tuscany-sdo:generate {execution: generate-po-sdo}]
> [INFO] Generating SDO interfaces from
> 
C:\temp\LAMP\Eclipse-3.2.1\eclipse\workspaces\osgi\Tuscany\sca\modules\databinding-sdo\src\test\resour
> ces\ipo.xsd
> [INFO] 

> [ERROR] FATAL ERROR
> [INFO] 

> [INFO] org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
> [INFO] 

> [INFO] Trace
> java.lang.NoClassDefFoundError:
> org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
>at
> 
org.apache.tuscany.sdo.generate.JavaGenerator.ecore2GenModel(JavaGenerator.java:540)
>at
> 
org.apache.tuscany.sdo.generate.JavaGenerator.createGenPackages(JavaGenerator.java:438)
>at
> 
org.apache.tuscany.sdo.generate.JavaGenerator.generatePackages(JavaGenerator.java:394)
>at
> 
org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:187)
>at
> 
org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:153)
>at
> org.apache.tuscany.sdo.plugin.GeneratorMojo.execute(GeneratorMojo.java:270)
>a

RE: [TuscanySCA CPP] problems trying to load services from multiple directories at once


I think I figured out how to make this work, but I don't think it's the
intended usage.

If I set TUSCANY_SCACPP_SYSTEM_ROOT to:
"~/tuscany/services/serviceA:~/tuscany/services/serviceB"
And leave TUSCANY_SCACPP_SYSTEM_PATH blank, then I get all of the
services loaded. Its not loaded as intended though, since what it does
is populate the SCARuntime::system composite with the system composites
from serviceA and serviceB. Does that seem correct?


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


-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 10:17 AM
To: tuscany-dev@ws.apache.org
Subject: RE: [TuscanySCA CPP] problems trying to load services from
multiple directories at once


I have since updated the JIRA with a clarification of what I am trying
to do and have included it here in  tags.



Just to clarify one piece of information about this problem:

serviceA and serviceB are totally unrelated. The system composites are
located as follows:

~/tuscany/services/
 |
 +->serviceA/serviceA.composite
 |
 +->serviceB/serviceB.composite  



Seems like the problem is that the SCARuntime was designed towards just
having one service loaded at a time. And what I am trying to do is to be
able to load several unrelated services.



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

-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 10, 2007 9:42 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [TuscanySCA CPP] problems trying to load services from
multiple directories at once

I think that them intent is for any composites under the
TUSCANY_SCACPP_SYSTEM_ROOT to be loaded so I think it may be an error to
specify a _PATH that includes or is a subdirectory of the SYSTEM_ROOT.
Maybe we could police this or change the loader to ignore duplicates
from the same location.??

On 10/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I created a JIRA for this issue:
>https://issues.apache.org/jira/browse/TUSCANY-1418
>
>  Im trying to start the Tuscany SCA runtime so that it loads several 
> service directories at once. Im assuming that this should be achieved 
> by using the systemPath argument of the
> SCARuntime::initializeSharedRuntime() method. Im also assuming that 
> the systemPath should be a ":" (colon) or ";" (semi-colon) seperated 
> list of directories, each of which is a separate SCA service 
> directory.
>
> If my assumptions are correct, then what purpose does the systemRoot 
> paramater serve when systemPath is specified?
> In the call to ModelLoader::load(), if systemPath is specified, then 
> the following call is made:
>ModelLoader::loadComposites(systemRoot + PATH_SEPARATOR + 
> systemPath);
>
> So lets assume that systemRoot is "~/tuscany/services" and systemPath 
> is "~/tuscany/services/serviceA:~/tuscany/services/serviceB"
> Then ModelLoader::loadComposites() will be called with this string:
>
> "~/tuscany/services:~/tuscany/services/serviceA:~/tuscany/services/ser
> vi
> ceB"
> Since the Files() constructor in loadComposites has the subdirectories

> parameter set to true, the directories will be traversed as follows:
> 1. everything under "~/tuscany/services" (including serviceA and
> serviceB)
> 2. everything under "~/tuscany/services/serviceA"
> 3. everything under "~/tuscany/services/serviceB"
>
> This is problematic since the services get loaded/parsed multiple
times.
>
>
> When systemPath is set, changing the call do loadComposites() to this:
>ModelLoader::loadComposites(systemPath);
> Avoids the multiple loading of the services. There is still some sort 
> of error when loading multiple services when loadComposites() is 
> called this way. It appears that the systemComposite is being 
> overwritten somehow and ends up empty.
>
> Before digging into the second problem further, I would like to make 
> sure that my previous assumptions are accurate. It may be that Im not 
> invoking the runtime correctly.
>
> 
> 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]


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

RE: [TuscanySCA CPP] problems trying to load services from multiple directories at once


I have since updated the JIRA with a clarification of what I am trying
to do and have included it here in  tags.



Just to clarify one piece of information about this problem:

serviceA and serviceB are totally unrelated. The system composites are
located as follows:

~/tuscany/services/
 |
 +->serviceA/serviceA.composite
 |
 +->serviceB/serviceB.composite  



Seems like the problem is that the SCARuntime was designed towards just
having one service loaded at a time. And what I am trying to do is to be
able to load several unrelated services.



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

-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 10, 2007 9:42 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [TuscanySCA CPP] problems trying to load services from
multiple directories at once

I think that them intent is for any composites under the
TUSCANY_SCACPP_SYSTEM_ROOT to be loaded so I think it may be an error to
specify a _PATH that includes or is a subdirectory of the SYSTEM_ROOT.
Maybe we could police this or change the loader to ignore duplicates
from the same location.??

On 10/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I created a JIRA for this issue:
>https://issues.apache.org/jira/browse/TUSCANY-1418
>
>  Im trying to start the Tuscany SCA runtime so that it loads several 
> service directories at once. Im assuming that this should be achieved 
> by using the systemPath argument of the
> SCARuntime::initializeSharedRuntime() method. Im also assuming that 
> the systemPath should be a ":" (colon) or ";" (semi-colon) seperated 
> list of directories, each of which is a separate SCA service 
> directory.
>
> If my assumptions are correct, then what purpose does the systemRoot 
> paramater serve when systemPath is specified?
> In the call to ModelLoader::load(), if systemPath is specified, then 
> the following call is made:
>ModelLoader::loadComposites(systemRoot + PATH_SEPARATOR + 
> systemPath);
>
> So lets assume that systemRoot is "~/tuscany/services" and systemPath 
> is "~/tuscany/services/serviceA:~/tuscany/services/serviceB"
> Then ModelLoader::loadComposites() will be called with this string:
>
> "~/tuscany/services:~/tuscany/services/serviceA:~/tuscany/services/ser
> vi
> ceB"
> Since the Files() constructor in loadComposites has the subdirectories

> parameter set to true, the directories will be traversed as follows:
> 1. everything under "~/tuscany/services" (including serviceA and
> serviceB)
> 2. everything under "~/tuscany/services/serviceA"
> 3. everything under "~/tuscany/services/serviceB"
>
> This is problematic since the services get loaded/parsed multiple
times.
>
>
> When systemPath is set, changing the call do loadComposites() to this:
>ModelLoader::loadComposites(systemPath);
> Avoids the multiple loading of the services. There is still some sort 
> of error when loading multiple services when loadComposites() is 
> called this way. It appears that the systemComposite is being 
> overwritten somehow and ends up empty.
>
> Before digging into the second problem further, I would like to make 
> sure that my previous assumptions are accurate. It may be that Im not 
> invoking the runtime correctly.
>
> 
> 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: Build problems

2007-07-10 Thread Raymond Feng


Hi,

Please run "mvn clean install".

Thanks,
Raymond
- Original Message - 
From: "Graham Charters" <[EMAIL PROTECTED]>

To: "tuscany-dev" 
Sent: Tuesday, July 10, 2007 8:56 AM
Subject: Build problems



Hi,

I'm trying to build Tuscany Java and have hit a couple of problems.
I've started with a clean repository, and checked out the latest from
svn (a few times throughout July 9th/10th).  When I do mvn at the top
level, I get a test case failure with the following exception:

testTransformation(org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase)
Time elapsed: 0.031 sec  <<< ERROR!
java.lang.IncompatibleClassChangeError:
org/apache/tuscany/sca/databinding/impl/SimpleTypeMapperImpl.getXMLType(Ljava/lang/Class;)Lorg/apach
e/tuscany/sca/interfacedef/util/TypeInfo;
   at 
org.apache.tuscany.sca.databinding.xml.BeanUtil.isSimpleType(BeanUtil.java:49)
   at 
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:100)
   at 
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:184)
   at 
org.apache.tuscany.sca.databinding.javabeans.JavaBean2XMLStreamReader.transform(JavaBean2XMLStreamReader.java:35)
   at 
org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase.testTransformation(JavaBean2XMLStreamReaderTestCase.java:

43)
   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.TestCase.runTest(TestCase.java:168)
   at junit.framework.TestCase.runBare(TestCase.java:134)
   at junit.framework.TestResult$1.protect(TestResult.java:110)
   at junit.framework.TestResult.runProtected(TestResult.java:128)
   at junit.framework.TestResult.run(TestResult.java:113)
   at junit.framework.TestCase.run(TestCase.java:124)
   at junit.framework.TestSuite.runTest(TestSuite.java:232)
   at junit.framework.TestSuite.run(TestSuite.java:227)
   at 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
   at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
   at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
   at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)

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

   at java.lang.reflect.Method.invoke(Method.java:615)
   at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
   at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)


When I try to build Eclipse projects using "mvn -Peclipse
eclipse:eclipse" I get the following exception:

[INFO] [tuscany-sdo:generate {execution: generate-po-sdo}]
[INFO] Generating SDO interfaces from
C:\temp\LAMP\Eclipse-3.2.1\eclipse\workspaces\osgi\Tuscany\sca\modules\databinding-sdo\src\test\resour
ces\ipo.xsd
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
[INFO] 
[INFO] Trace
java.lang.NoClassDefFoundError:
org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
   at 
org.apache.tuscany.sdo.generate.JavaGenerator.ecore2GenModel(JavaGenerator.java:540)
   at 
org.apache.tuscany.sdo.generate.JavaGenerator.createGenPackages(JavaGenerator.java:438)
   at 
org.apache.tuscany.sdo.generate.JavaGenerator.generatePackages(JavaGenerator.java:394)
   at 
org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:187)
   at 
org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:153)
   at 
org.apache.tuscany.sdo.plugin.GeneratorMojo.execute(GeneratorMojo.java:270)
   at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:896)
   at 
org.apache.maven.lif

Build problems

2007-07-10 Thread Graham Charters


Hi,

I'm trying to build Tuscany Java and have hit a couple of problems.
I've started with a clean repository, and checked out the latest from
svn (a few times throughout July 9th/10th).  When I do mvn at the top
level, I get a test case failure with the following exception:

testTransformation(org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase)
Time elapsed: 0.031 sec  <<< ERROR!
java.lang.IncompatibleClassChangeError:
org/apache/tuscany/sca/databinding/impl/SimpleTypeMapperImpl.getXMLType(Ljava/lang/Class;)Lorg/apach
e/tuscany/sca/interfacedef/util/TypeInfo;
   at 
org.apache.tuscany.sca.databinding.xml.BeanUtil.isSimpleType(BeanUtil.java:49)
   at 
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:100)
   at 
org.apache.tuscany.sca.databinding.xml.BeanUtil.getXMLStreamReader(BeanUtil.java:184)
   at 
org.apache.tuscany.sca.databinding.javabeans.JavaBean2XMLStreamReader.transform(JavaBean2XMLStreamReader.java:35)
   at 
org.apache.tuscany.sca.databinding.xml.JavaBean2XMLStreamReaderTestCase.testTransformation(JavaBean2XMLStreamReaderTestCase.java:
43)
   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.TestCase.runTest(TestCase.java:168)
   at junit.framework.TestCase.runBare(TestCase.java:134)
   at junit.framework.TestResult$1.protect(TestResult.java:110)
   at junit.framework.TestResult.runProtected(TestResult.java:128)
   at junit.framework.TestResult.run(TestResult.java:113)
   at junit.framework.TestCase.run(TestCase.java:124)
   at junit.framework.TestSuite.runTest(TestSuite.java:232)
   at junit.framework.TestSuite.run(TestSuite.java:227)
   at 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
   at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
   at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
   at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
   at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)

When I try to build Eclipse projects using "mvn -Peclipse
eclipse:eclipse" I get the following exception:

[INFO] [tuscany-sdo:generate {execution: generate-po-sdo}]
[INFO] Generating SDO interfaces from
C:\temp\LAMP\Eclipse-3.2.1\eclipse\workspaces\osgi\Tuscany\sca\modules\databinding-sdo\src\test\resour
ces\ipo.xsd
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
[INFO] 
[INFO] Trace
java.lang.NoClassDefFoundError:
org.eclipse.emf.codegen.ecore.genmodel.GenModelFactory
   at 
org.apache.tuscany.sdo.generate.JavaGenerator.ecore2GenModel(JavaGenerator.java:540)
   at 
org.apache.tuscany.sdo.generate.JavaGenerator.createGenPackages(JavaGenerator.java:438)
   at 
org.apache.tuscany.sdo.generate.JavaGenerator.generatePackages(JavaGenerator.java:394)
   at 
org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:187)
   at 
org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:153)
   at 
org.apache.tuscany.sdo.plugin.GeneratorMojo.execute(GeneratorMojo.java:270)
   at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:896)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:739)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:510)
   at 
org.apache.mav

Re: [TuscanySCA CPP] problems trying to load services from multiple directories at once

2007-07-10 Thread Pete Robbins


I think that them intent is for any composites under the
TUSCANY_SCACPP_SYSTEM_ROOT to be loaded so I think it may be an error
to specify a _PATH that includes or is a subdirectory of the
SYSTEM_ROOT. Maybe we could police this or change the loader to ignore
duplicates from the same location.??

On 10/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


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

 Im trying to start the Tuscany SCA runtime so that it loads several
service directories at once. Im assuming that this
should be achieved by using the systemPath argument of the
SCARuntime::initializeSharedRuntime() method. Im also
assuming that the systemPath should be a ":" (colon) or ";" (semi-colon)
seperated list of directories, each of which is a
separate SCA service directory.

If my assumptions are correct, then what purpose does the systemRoot
paramater serve when systemPath is specified?
In the call to ModelLoader::load(), if systemPath is specified, then the
following call is made:
   ModelLoader::loadComposites(systemRoot + PATH_SEPARATOR +
systemPath);

So lets assume that systemRoot is "~/tuscany/services" and systemPath is
"~/tuscany/services/serviceA:~/tuscany/services/serviceB"
Then ModelLoader::loadComposites() will be called with this string:

"~/tuscany/services:~/tuscany/services/serviceA:~/tuscany/services/servi
ceB"
Since the Files() constructor in loadComposites has the subdirectories
parameter set to true, the directories will be traversed as follows:
1. everything under "~/tuscany/services" (including serviceA and
serviceB)
2. everything under "~/tuscany/services/serviceA"
3. everything under "~/tuscany/services/serviceB"

This is problematic since the services get loaded/parsed multiple times.


When systemPath is set, changing the call do loadComposites() to this:
   ModelLoader::loadComposites(systemPath);
Avoids the multiple loading of the services. There is still some sort of
error when loading multiple services when loadComposites() is
called this way. It appears that the systemComposite is being
overwritten somehow and ends up empty.

Before digging into the second problem further, I would like to make
sure that my previous assumptions are accurate. It may be that Im
not invoking the runtime correctly.


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

2007-07-10 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson updated TUSCANY-1421:


  Component/s: Java SDO Implementation
Affects Version/s: Java-SDO-beta1

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

2007-07-10 Thread Kelvin Goodson (JIRA)

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

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

2007-07-10 Thread Venkata Krishnan

Hi,

Here are my observations on this RC.

1) The source builds successfully from a clean maven repo
- Notice, Disclaimer and License files missing from source 'rdb' module.
2) Trying the samples
a) I see that the source has two additional directories 'testing' and
'dbconfig' which are not there in binary distro. Maybe we must make it
clear that this applies only if one is using the source distro.
b) RDB DAS Sample (companyweb)
- should we change that title to RDB DAS CompanyWeb Sample.
- Readme
- the section "Running from Tomcat configured by the
build" has
information that cannot be related to with the binary distro. There
is a mention of 'testing' module within samples and also the paths
seem to be related to the svn structure.
(java/das/samples/testing/tomcat/readme.htm)
- the section "Deploying the CompanyWeb WAR into a
Tomcat you
configure yourself" talks about a 'sample distribution' - and I don't
think we have one. Do we ?
- furtheron there is mention about copying
derby.jar but
I see it in the war as well.
- and then in "Install the canned Derby database to
Tomcat", i
really cannot figure out where datatest directory is.
- I really think this readme needs a overhaul or I am
grossly
missing something.
c) RDB DAS Customer Sample runs clean as mentioned in the readme
- Section "Running from Tomcat configured by the build" may
need to
mention that it applies only to src distro
- there is a mention of 'sample distribution' which we don't
have
- about copying derby.jar to tomcat lib I guess its common/lib
for
tomcat 5.x and just 'lib' for tomcat 6.x
- I was able to deploy to the war to tomcat, I copied over the
derby-10.1.2.1.jar that I found in the war to the lib directory and
was able to run the sample successfully. I tried the adhoc queries
and they seemed to work fine for me.

3) License and Notice : I find licenses are in place. In the notice
there is mention of using software developed by OSOA. Did not quite
find anything from osoa.

So, overall its about the READMEs for the samples that need some
fixing. Even there the customer and ajax samples can be worked out
with the current READMEs - with the Ajax sample really give a feel
that DAS works. So I really cannot see a blocker with this.

Here is my +1.

Thanks.

- Venkat

On 7/10/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 should now be fixed.

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

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

Release Notes are available at

https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc2/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-rc2/maven/

The release audit tool (rat) results are available at

http://people.apache.org/~lresende/tuscany/das-beta1-rc2/das-beta1-rc2-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-rc2/

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]

[jira] Updated: (TUSCANY-1419) Java DAS RDB beta1 RC2 - minor issues


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

Amita Vadhavkar updated TUSCANY-1419:
-

Attachment: readme.htm.sample-ajax-das
readme.htm.companyweb

see ML for the comments for companyweb and sample-ajax-das readmes
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19785.html

> Java DAS RDB beta1 RC2 - minor issues
> -
>
> Key: TUSCANY-1419
> URL: https://issues.apache.org/jira/browse/TUSCANY-1419
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Amita Vadhavkar
> Attachments: readme.htm.companyweb, readme.htm.sample-ajax-das, 
> Readme.htm.samplesReadme, RELEASE_NOTES
>
>
> This patch is created to provide some minor corrections to below files
> 1) RELEASE NOTES
> 2) companyweb/readme
> 3) sample-ajax-das-readme

-- 
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: [VOTE] Release Tuscany Java DAS beta1 (RC2)

2007-07-10 Thread Amita Vadhavkar

I somehow missed tuscany-dev in last reply...

On 7/10/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

Hi,

Suggestions:-
Note: I have created JIRA-1419 to upload files wherever I could see a few
issues, mentioned below. Please review the uploads (1 hr from now) and
comment

RELEASE NOTES -
1) Under DAS Samples 3rd point , we say Integration with dbConfig, but in
1st point we do not name the database utility, so is a bit confusing - what
is dbConfig?
Can we say the first point
  - Introduced database utility (dbConfig) to create, populate and refresh
canned sample dbs

2) in sample readmes -
   1> companyweb readme is still stale - talks about canned db steps which
are irrelevant now.
   2> sample-ajax-das reademe is a bit stale - name of utility is
mentioned as "dbsetup" - should be dbConfig.
   3> Samples - (top level) readme - Concurrently -> needs Concurrency

   In both 1> and 3>, the db url for server.xml does not mention
;create=true , without
   this the samples will never work.
   e.g. url="jdbc:derby:c:\apache-tomcat-5.5.20\Databases/ajaxdastest
;create=true"

Other than the above, I tried bin and src destros, build, test, samples,
and have not come across any issues. So, as such the samples war will deploy
and user using these will face no issues, but following samples readmes will
be confusing for users.

So, here's my -1 (non-binding).

Regards,
Amita

On 7/10/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 should now be fixed.
>
> The Release Candidate RC2 for Tuscany Java DAS beta1 is available at
>
>
http://people.apache.org/~lresende/tuscany/das-beta1-rc2/
>
> Release Notes are available at
>   
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc2/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-rc2/maven/
>
> The release audit tool (rat) results are available at
>
>
> 
http://people.apache.org/~lresende/tuscany/das-beta1-rc2/das-beta1-rc2-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-rc2/
>
> 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]
>
>

[jira] Updated: (TUSCANY-1419) Java DAS RDB beta1 RC2 - minor issues


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

Amita Vadhavkar updated TUSCANY-1419:
-

Attachment: Readme.htm.samplesReadme

samples/Readme - Concurrently -> Concurrency

> Java DAS RDB beta1 RC2 - minor issues
> -
>
> Key: TUSCANY-1419
> URL: https://issues.apache.org/jira/browse/TUSCANY-1419
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Amita Vadhavkar
> Attachments: Readme.htm.samplesReadme, RELEASE_NOTES
>
>
> This patch is created to provide some minor corrections to below files
> 1) RELEASE NOTES
> 2) companyweb/readme
> 3) sample-ajax-das-readme

-- 
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-1419) Java DAS RDB beta1 RC2 - minor issues


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

Amita Vadhavkar updated TUSCANY-1419:
-

Attachment: RELEASE_NOTES

- Introduced database utility *(dbConfig)* to create, populate and refresh 
canned sample dbs
- Optimistic Concurrently Control (OCC) - > - Optimistic Concurrency Control 
(OCC)

> Java DAS RDB beta1 RC2 - minor issues
> -
>
> Key: TUSCANY-1419
> URL: https://issues.apache.org/jira/browse/TUSCANY-1419
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Amita Vadhavkar
> Attachments: RELEASE_NOTES
>
>
> This patch is created to provide some minor corrections to below files
> 1) RELEASE NOTES
> 2) companyweb/readme
> 3) sample-ajax-das-readme

-- 
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: StackOverflowException when mutual reference exist

2007-07-10 Thread Mike Edwards


Huang,


Huang Kai wrote:

I mean that composite A has a component which uses composite B as
an implementation and that composite B has a component which uses
 composite A as an implementation .
I think this use case is fairly common, eg. [Employee] has a property refer to 
[Company] and [Company] has a property refer to it's [Employee]s. And when 
these two java components are in different composites, I'll have to define 
mutual referenced composite files above.



Aaargh - this is the case that I was worrying about.

OK - what you need to understand here is that using a composite to 
implement a component within a higher level composite is *NOT* a 
reference property.


Using something as an implementation is a STRUCTURAL relationship.  It 
means that the implementation is "part of" the containing composite. 
Now if you view it that way, then it does *NOT* make sense for a Company 
to be "built from" employees and then for the employees to be "built 
from" a company.  That is what your use case is like.


It's OK for a "Company" component to have a reference to an "Employee" 
component - but a reference is not the implementation of a component - 
it is a dependency that one component has on another.



Does that make sense?


Yours,  Mike.

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

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

2007-07-10 Thread Simon Nash

I have created TUSCANY-1420 for the README problems.

  Simon

haleh mahbod wrote:

All the raised minor issues related to samples readme that could be
confusing to new users (minus the spelling issues) can be put into one Jira
and referenced from Erata. This keeps users informed and also is a reminder
that these need to be fixed in the next release.

Just a thought..

On 7/9/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi,

I have reviewed the content and it looks pretty good to me. The source
distro can be built from an empty local maven repo successfully. I can 
run
the samples and demos using ant script with the binary distro. The 
LICENSE

and NOTICE files are in place.

+1.

Thanks,
Raymond

- Original Message -
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: 
Sent: Friday, July 06, 2007 4:01 AM
Subject: [VOTE] Release Tuscany Java SCA 0.91-incubating RC2

> Hi,
>
> Please review and vote on the 0.91 release artifacts of Tuscany SCA for
> Java.
>
> The artifacts are available for review at:
> http://people.apache.org/~svkrish/tuscany/0.91-rc2/
>
> 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-rc2-incubating/ 

>
> All comments raised for RC1 -
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19416.html -
> have been fixed.
>
> Looks ok to me - so here's my +1.
>
> Thanks
>
> - Venkat
>

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

[jira] Created: (TUSCANY-1420) Various problems with README files in SCA Java 0.91 RC2

2007-07-10 Thread Simon Nash (JIRA)

Various problems with README files in SCA Java 0.91 RC2
---

Key: TUSCANY-1420
URL: https://issues.apache.org/jira/browse/TUSCANY-1420
Project: Tuscany
Issue Type: Bug
Components: Java SCA Samples
Affects Versions: Java-SCA-0.91
Environment: Windows XP
Reporter: Simon Nash
Assignee: Simon Nash
Fix For: Java-SCA-Next

The numbers don't start at 1 because this text was cut and pasted from this
post to the dev list::
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19743.html

4. The README for samples/binding-echo has an error in line 51:
EchoYestCase.Java should be EchoBindingTestCase.java.
5. The README for samples/binding-echo has incorrect mvn output.
The correct output is:
Running echo.EchoBindingTestCase
Returned message: foo
Returned message: bar
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.811 sec

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
6. The README for samples/binding-echo-extension has incorrect mvn output.
The correct output is:
Running echo.EchoServiceTestCase
Returned message: foo
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.011 sec
Running echo.EchoReferenceTestCase
Returned message: foo
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
7. The README for samples/calculator-rmi-reference is incorrect
in the wording of the message at line 92. It says the message is
[java] Calculator RMI Service bound to RMI Registry at port 8099...
but the actual message displayed is
[java] Starting of the SCA Calculator Application exposed as RMI
Services...
8. The README for samples/calculator-rmi-service is incorrect in the
wording of the message at line 104. It says the message is
[java] Calculator RMI Service bound to RMI Registry at port 8099...
but the actual message displayed is
[java] Starting of the SCA Calculator Application exposed as RMI
Services...
9. In the README for samples/calculator-script, the output for ant run
displayed
at line 80 and following omits the following message that I get when
I run this:
[java] *sys-package-mgr*: can't create package cache dir,
'H:\tuscany-0.91-rc2\tuscany-sca-0.91-incubating\lib\jython-2.2-beta2.jar\cachedir\packages'
I get a similar message from mvn, which gives the output:
Running calculator.CalculatorTestCase
*sys-package-mgr*: can't create package cache dir, 'C:\Documents and
Settings\na

sh\.m2\repository\org\python\jython\2.2-beta2\jython-2.2-beta2.jar\cachedir\pack
ages'
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.727 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
Is this message normal? If so, it should be mentioned in the README.
10. The README for samples/calculator-webapp does not show the test output that
running mvn produces before building the war, as follows:
Running calculator.CalculatorTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.852 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
11. The README for samples/chat-webapp does not mention the chat.html file
in the webapp directory.
12. The README for samples/chat-webapp has typos in line 13 ("you" for "your")
and line 25 ("forwads" for "forwards").
13. The README for samples/databinding-echo does not mention the file

src/main/resources/META-INF/services/org.apache.tuscany.sca.core.ModuleActivator
14. The README for samples/databinding-echo has an error for the mvn output in
line 119. This line should be
Running dbecho.EchoDataBindingTestCase
instead of
Running echo.EchoDataBindingTestCase
15. The README for samples/helloworld-dojo does not mention the
build-dojo.xml file or explain its purpose.
16. The README for samples/helloworld-dojo has a typo in line 31:
helloworl-dojo instead or helloworld-dojo.
17. the README for samples/helloworld-dojo mentions a dojo directory under
webapp in line 41, but this directory is not present in the
binary distro.
18. The README for samples/helloworld-dojo has a Sample Overview (lines
26 to 29) with a few typos and glitches. The current text is:
The sample provides a single service which with an operation that reflects
a greeting back to the called. The service is exposed using the JSONRPC
binding. The web app provided shows how the service can be called either
via
via the SCA provided JSON client or by using the DOJO toolkit.
This should be changed to:
The sample provides a single service with an operation that reflects
a g

RE: Runtime access to sdoJava:package

2007-07-10 Thread Frank Budinsky

Given a Type, you can call type.getInstanceClass() and if it's not null, 
the package name can be retrieved from the Class. If the instanceClass is 
null, there is no static class, and hence no package for the type.

Frank.

"Pinaki Poddar" <[EMAIL PROTECTED]> wrote on 07/09/2007 05:53:21 PM:

> Thanks Fuhwei.
> 
> But the underlying EMF Ecore allowed a path to do the same -- at least
> as far I can see in my debugger. 
> 
> In a implementation that is based upon another impl -- it often helps to
> make the underlying impl available via 'public Object getDelegate();' or
> some such method. Is there any such under-the-hood way to get hold of
> EMF impl classes in Tuscany's SDO impl -- even it does require me to
> cast to specific impl from the commonj.sdo API instances. 
> 
> 
> Pinaki Poddar
> 972.834.2865
> 
> -Original Message-
> From: Fuhwei Lwo [mailto:[EMAIL PROTECTED] 
> Sent: Monday, July 09, 2007 4:46 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Runtime access to sdoJava:package 
> 
> Hi Pinaki,
> 
> sdoJava:package is only used by the users to control what Java package
> name should be generated during the generation of static SDO APIs. I
> don't think its info can be accessed from the standard SDO APIs.
> 
> Fuhwei
> 
> Pinaki Poddar <[EMAIL PROTECTED]> wrote: Hello, a newbie question:
> 1. *.xsd has declared 
>  sdoJava:package="com.acme.mydomain" 
> 
> 2. With XSDHelper.INSTANCE (or with some other helper)
>how does one programatically access the package name
> "com.acme.mydomain"?
> 
> A more general question,
> does SDO Type has a 'package' notion or such notion is only valid if SDO
> Type is converted to Java Class?
> 
> Thanks 
> 
> 
> Pinaki Poddar
> 972.834.2865
> 
> 
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
> 
> Notice:  This email message, together with any attachments, may 
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and 
> affiliated entities,  that may be confidential,  proprietary, 
> copyrighted  and/or legally privileged, and is intended solely for 
> the use of the individual or entity named in this message. If you 
> are not the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

[jira] Created: (TUSCANY-1419) Java DAS RDB beta1 RC2 - minor issues

Java DAS RDB beta1 RC2 - minor issues
-

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


This patch is created to provide some minor corrections to below files
1) RELEASE NOTES
2) companyweb/readme
3) sample-ajax-das-readme

-- 
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 - 0.92 release - People provide your views/ideas

2007-07-10 Thread Sam Tam


Hello All,

Am a student from an University - India. So am not a big expert in this
domain.

I was looking at things to be done for SCA 0.92 release [1].

I want to contribute more by learning  [esp  WS improvements].

But am kind of lost on where to start and which one to start with.

So share your ideas  and kindly provide some lead on this  .



Sam
---
Msc Software Engg
Psg College of Technology
India



-

[1] -
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents

[jira] Commented: (TUSCANY-1237) DAS should support JDK 1.4

2007-07-10 Thread Ron Gavlin (JIRA)


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

Ron Gavlin commented on TUSCANY-1237:
-

Hi Amita,

Yes, the ConnectionImpl.java change is the only "real" change in this patch 
from the first. Thanks for reviewing and applying this patch for me.

- Ron

> DAS should support JDK 1.4
> --
>
> Key: TUSCANY-1237
> URL: https://issues.apache.org/jira/browse/TUSCANY-1237
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
> Environment: Windows, Sun JDK 1.4.2_11
>Reporter: Ron Gavlin
> Fix For: Java-DAS-Next
>
> Attachments: das-TUSCANY-1237.2.patch, das-TUSCANY-1237.patch
>
>
> Tuscany DAS should support JDK 1.4. Since Tuscany DAS leverages SDO, it would 
> seem to make sense for the DAS
> JDK requirements to be sync'd with the Tuscany SDO JDK requirements. Tuscany 
> SDO currently supports JDK 1.4+. After browsing the DAS source code, there 
> appear to be only a few places that leverage JDK 1.5 features. These could 
> easily be replaced with JDK 1.4 functions. Please consider supporting JDK 1.4 
> until SDO 3 is released at which time I presume SDO will require JDK 1.5.

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


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

Amita Vadhavkar updated TUSCANY-1391:
-

Attachment: 1391.patch

renamed method to getUnknownProperties() as well as renamed the testCase to 
be consistent.
Regards,
Amita

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

[VOTE] Release Tuscany Java DAS beta1 (RC2)


Please vote to release the beta1 distribution of Tuscany DAS for Java.
All the major issues reported in RC1 should now be fixed.

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

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

Release Notes are available at
 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc2/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-rc2/maven/

The release audit tool (rat) results are available at

 http://people.apache.org/~lresende/tuscany/das-beta1-rc2/das-beta1-rc2-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-rc2/

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]

[RESULT] was Re: [VOTE] Release Tuscany Java SCA 0.91-incubating RC2

2007-07-10 Thread Venkata Krishnan


Release vote for Tuscany Java SCA 0.91-incubating RC2 has passed with
5 binding +1, 1 non-binding +1 and no -1s.

Votes from :
Venkatakrishnan
Simon Laws
Anthony Elder
Luciano Resende
Raymond Feng
Simon Nash (non-binding)


Thanks.

- Venkat

On 7/6/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

Hi,

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

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

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-rc2-incubating/

All comments raised for RC1 -
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19416.html -
have been fixed.

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: Flexibility in supporting JDBC's Statement.RETURN_GENERATED_KEYS in RDB DAS (JIRA-1417)