Re: Cleaning up some of the new sample modules

[Jean-Sebastien Delfino]

[snip]
Simon Nash wrote:


I would like to keep the "split" structure as it currently is
rather than make a last minute change just before the 0.90 RC
without opportunity for discussion. (I'm on a plane tomorrow so
I won't have any email access all day.) I am fine with the
proposed renaming of the samples as suggested:
- echo-binding to echo-binding-extension
- echo-binding-appl to echo-binding
- implementation-crud to implementation-crud-extension
- implementation-crud-client to implementation-crud
Adding the "extension" suffix to the extension samples makes the
purpose of these samples clearer and solves the awkwardness over
how to describe the non-extension code.

Done under revision r547139.

[snip]


Testing that our sample client doesn't fail with an exception is 
useful to us and may deserve a test in our integration test suite (if 
we think that having a proper unit test case testing the bits and 
pieces in that module is not good enough), but I don't thing that 
it's interesting to keep it in the sample itself, as it's not going 
to teach anything to an application developer looking at the sample, 
and doesn't look like a "normal" unit test case.



Yes, agreed that this does not really belong in the samples. I would be
inclined to put this test code in itest/samples, just to have the build
confirm automatically that all the sample clients actually do run. It's
good to have equivalent unit tests as well, but the samples are so 
visible

that I think it's worth testing them explicitly.


[snip]

This is still open. +1 to that suggestion, we do not pollute the samples 
themselves with this kind of testing, we need to add new tests under 
sca/itest/samples that verify that the samples' main methods do not fail.


--
Jean-Sebastien


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

IDE-specific files in svn

[Frank Budinsky]

Hi,

I remember about a year ago discussing whether or not it is 
acceptable/appropriate to check-in IDE specific files (e.g., Eclipse 
.project files) into svn, and we decided to not do it. Does anyone 
remember if this was really an Apache policy, or just a decision we made 
for Tuscany? If the latter, I wonder if we should reconsider. Personally, 
I think it would be very convenient if we had the Eclipse .project and 
.classfile in the projects, so that people could just check out Tuscany 
projects directly into Eclipse. For people not using Eclipse, having these 
superfluous files around really doesn't seem like a big deal. I also 
wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files 
that Eclipse users (like me) would just ignore.

What do others think about this?

Thanks,
Frank.

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

RE: Does Tuscany SDO C++ support open content properties?

[Andy Grove]

Pete,

Thanks for that information. The main use case I am currently looking at is the 
ability to parse an XML document where types have not been defined. From 
memory, whenever I have attempted this the XMLDocument.getRootDataObject() 
method returns NULL. 

Thanks,

Andy.


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wed 13/06/2007 12:57
To: tuscany-dev@ws.apache.org
Subject: Re: Does Tuscany SDO C++ support open content properties?
 
Open content properties are supported in the SDO C++ implementation. I'm not
sure if support is quite up to "spec" level but it's fairly close.

Deserializing an xml document to SDO without schema is probably "not quite
there" and the XMLHelper and parser code would need looking at to make this
work as per the SDO spec... but I think it could be reasonably simple to
support.

Do you have a particular scenario that you need to work?

Cheers,


On 13/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:
>
> I understand that Tuscany SDO C++ requires types to be defined before
> parsing xml documents. Would I be correct in assuming that this is because
> open content properties are not yet supported? If so, are there any plans
> for implementing this support?
>
> Thanks,
>
> Andy.
>



-- 
Pete

Th

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

Re: Serving web content from embedded Tomcat and Jetty

[Jean-Sebastien Delfino]

ant elder wrote:

On 6/13/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


In multiple instances I've run into an annoying limitation of our
embedded Tomcat and Jetty support... We cannot serve Web content, HTML
pages, scripts etc. when we run Tomcat or Jetty embedded in a J2SE
program. This makes it more difficult than it should be to test SCA
applications that use our JSON-RPC binding in particular, as you need to
package these applications in WARs, deploy them to a standalone Tomcat
or Jetty, use remote debugging to step through them etc... as opposed to
simply running them from a J2SE program's main()...

I'd like to leverage a small variation of our Crud/resource
implementation type sample to fix that, and simply use a component to
serve web content out of a directory inside an application.

Here's how the helloworld-jsonrpc sample composite will look with that
component implementation (see the BEGIN/END new-stuff section):

http://www.osoa.org/xmlns/sca/1.0";
  targetNamespace="http://sample";
  xmlns:sample="http://sample";
   name="helloworldjsonrpc">



 
 














With that simple change, we will be able to run directly from J2SE and
serve Web content out of the configured directory... so we won't have to
always package the whole app in a WAR and deploy it to a standalone Web
container.

Thoughts?

If there's no objection, I'd like to start adding that support later
this week.



Sounds cool, and it would be really good for apps to work with the
standalone http hosts.

But what exactly does implementation.webResource do? Doesn't there 
need to
be some sort of binding on the MyHelloWorldContent component to expose 
it as

an http resource?

  ...ant



Yes, a simplified HTTP binding, which just registers the default file 
servlet, configured with the binding's uri and the location specified on 
the webResource, with the servlet host.


Since it's going to be pretty limited I'm not planning to expose it as a 
new module separate from the implementation module, unless other Tuscans 
are interested in it and want to pick it up.


in general application developers won't even have to know about it.

The following declaration:

   
   
   

will turn into a component declaring a default service with that default 
HTTP binding configured to map uri="myfiles" to a file servlet serving 
files in folder "myfiles".


If people really really really wanted to tweak the binding they would 
write something like that:

   
   
   http://localhost:1234/myuri"/>
   
   
   

but I'm thinking about not implementing that XML support initially, and 
wait until people actually ask for it before over-engineering this.


--
Jean-Sebastien


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

Re: Serving web content from embedded Tomcat and Jetty

[ant elder]

On 6/13/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


In multiple instances I've run into an annoying limitation of our
embedded Tomcat and Jetty support... We cannot serve Web content, HTML
pages, scripts etc. when we run Tomcat or Jetty embedded in a J2SE
program. This makes it more difficult than it should be to test SCA
applications that use our JSON-RPC binding in particular, as you need to
package these applications in WARs, deploy them to a standalone Tomcat
or Jetty, use remote debugging to step through them etc... as opposed to
simply running them from a J2SE program's main()...

I'd like to leverage a small variation of our Crud/resource
implementation type sample to fix that, and simply use a component to
serve web content out of a directory inside an application.

Here's how the helloworld-jsonrpc sample composite will look with that
component implementation (see the BEGIN/END new-stuff section):

http://www.osoa.org/xmlns/sca/1.0";
  targetNamespace="http://sample";
  xmlns:sample="http://sample";
   name="helloworldjsonrpc">



 
 














With that simple change, we will be able to run directly from J2SE and
serve Web content out of the configured directory... so we won't have to
always package the whole app in a WAR and deploy it to a standalone Web
container.

Thoughts?

If there's no objection, I'd like to start adding that support later
this week.



Sounds cool, and it would be really good for apps to work with the
standalone http hosts.

But what exactly does implementation.webResource do? Doesn't there need to
be some sort of binding on the MyHelloWorldContent component to expose it as
an http resource?

  ...ant

Re: [DAS] TUSCANY-866: Default OCC policy

[Brent Daniel]

Hi Amita,

 Unfortunately I had to drop this rather suddenly, so it would be
great if you could pick this up. The code I have, if I can find it,
probably isn't even relevant anymore.

 At a high level, my goals for recovery were to ensure that all
information on the failure was available and that users could easily
employ a strategy to recover. For the first goal, the user should know
which DataObject resulted in the OCC failure, and should have the
current and original values for that DO. For the second goal, I was
headed down the path of having a utility that would allow you to
"force" the changes (ignoring OCC failures), read the current DB
values to either illustrate what field is causing the collision or
just update the graph with the current state of that DO, or roll back
the changes to the current DataObject.

I think the important first step here is making sure the information
is available. I had planned on having an OCCException that would get
thrown after a collision which would contain this information (in
accordance with DAS design goals, this would have to extend
RuntimeException).

Brent

On 6/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

Please let me know what is there in code base at present/in-progress for OCC
recovery? Will you please elaborate the approach and if there is any item I
can pick up for next release?

Regards,
Amita


On 10/18/06, Brent Daniel <[EMAIL PROTECTED]> wrote:
>
> I've been working on some function to recover from collisions (since
> at the moment we have none :) ). One of the recovery mechanisms I'm
> planning to put in is a means to "force" the update. Though it would
> require an extra step, this should take care of this case.
>
> Brent
>
> On 10/17/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
> > I have talked to clients that want their data slammed into the database
> > no matter what.  But, this is an edge case.  We can wait for someone to
> > ask for it ... or contribute it.
> >
> > Brent Daniel wrote:
> >
> > > Kevin,
> > >
> > >  We can do that, but it will be our fourth different way to specify
> > > OCC behavior (default, version column, managed version column, and
> > > none.) Is there a good use case for this? It seems like the only time
> > > you would want to go without concurrency control is when you have
> > > read-only tables, and in that case this behavior would never be
> > > reached anyway.
> > >
> > > Brent
> > >
> > > On 10/17/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
> > >
> > >> Brent,
> > >> This sounds reasonable but we probably want some mechanism to provide
> > >> our previous default policy which is "no collision checking".  Maybe
> > >> a piece of config. What do you think?
> > >> --
> > >> Kevin
> > >>
> > >>
> > >>
> > >> [DAS] Use overqualified update by default
> > >> -
> > >>
> > >> Key: TUSCANY-866
> > >> URL: http://issues.apache.org/jira/browse/TUSCANY-866
> > >> Project: Tuscany
> > >>  Issue Type: New Feature
> > >>  Components: Java DAS RDB
> > >>Reporter: Brent Daniel
> > >>
> > >>
> > >> Currently in the DAS we either use a user-defined version column or
> > >> do not use any concurrency control. We have enough information to
> > >> build an overqualified update in cases where a version column is not
> > >> defined. For example, if a field "name" is changed from "Bob" to
> > >> "John", we would generate a query such as:
> > >>
> > >> UPDATE CUSTOMER SET NAME = 'John' WHERE ID = 1 AND NAME = 'Bob'
> > >>
> > >> If the statement does not update any rows in the database, the DAS
> > >> will throw a concurrency control exception.
> > >>
> > >> This scheme will not work in case of LONG VARCHAR, BLOB, or CLOB
> > >> columns, so an exception should be thrown in that case indicating
> > >> that a version column must be defined.
> > >>
> > >>
> > >>
> > >> -
> > >> 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]
> >
> >
>
> -
> 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]

Serving web content from embedded Tomcat and Jetty

[Jean-Sebastien Delfino]

In multiple instances I've run into an annoying limitation of our 
embedded Tomcat and Jetty support... We cannot serve Web content, HTML 
pages, scripts etc. when we run Tomcat or Jetty embedded in a J2SE 
program. This makes it more difficult than it should be to test SCA 
applications that use our JSON-RPC binding in particular, as you need to 
package these applications in WARs, deploy them to a standalone Tomcat 
or Jetty, use remote debugging to step through them etc... as opposed to 
simply running them from a J2SE program's main()...


I'd like to leverage a small variation of our Crud/resource 
implementation type sample to fix that, and simply use a component to 
serve web content out of a directory inside an application.


Here's how the helloworld-jsonrpc sample composite will look with that 
component implementation (see the BEGIN/END new-stuff section):


http://www.osoa.org/xmlns/sca/1.0";
 targetNamespace="http://sample";
 xmlns:sample="http://sample";
  name="helloworldjsonrpc">
 
   

   
interface="helloworldjsonrpc.HelloWorldService"/>


 
   class="helloworldjsonrpc.HelloWorldServiceImpl"/>

   

   

   
   

   

   



With that simple change, we will be able to run directly from J2SE and 
serve Web content out of the configured directory... so we won't have to 
always package the whole app in a WAR and deploy it to a standalone Web 
container.


Thoughts?

If there's no objection, I'd like to start adding that support later 
this week.


--
Jean-Sebastien


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

[jira] Created: (TUSCANY-1343) java.io.FileNotFoundException: org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLDocumentProcessor$WSDLLocatorImpl.getImportInputSource(WSDLDocumentProcessor.java:86)

[Yang Lei (JIRA)]

java.io.FileNotFoundException: 
org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLDocumentProcessor$WSDLLocatorImpl.getImportInputSource(WSDLDocumentProcessor.java:86)
-

 Key: TUSCANY-1343
 URL: https://issues.apache.org/jira/browse/TUSCANY-1343
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-0.91
 Environment: windows XP
Reporter: Yang Lei


WSDLDocumentP <  getBaseURI Exit
 PriceQuoteService.wsdl

[6/13/07 15:20:11:293 CDT] 0016 WSDLDocumentP >  getImportInputSource Entry
 c:/PriceQuoteService.wsdl
 PriceQuoteService_schema1.xsd
I created a PackageProcessor (FOLDER type) to place the default one. The logic 
of this processor is to be able to return certain file from a location 
different from the contribution's location. One kind of this file is WSDL file. 
Then I got the following error when the wsdl file contains :

   http://priceQuoteSession";   
schemaLocation="PriceQuoteService_schema1.xsd"/>

As the xsd file is in a different location of the wsdl file, shouldnot 
WSDLDocumentProcessor$WSDLLocatorImpl use the PackageProcessor's resolved 
artifact URL for loading xsd?

 java.io.FileNotFoundException: 
../PriceQuoteService_schema1.xsd (No such file or directory)
at java.io.FileInputStream.(FileInputStream.java:135)
at java.io.FileInputStream.(FileInputStream.java:95)
at 
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:85)
at 
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:176)
at java.net.URL.openStream(URL.java:1041)
at 
org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLDocumentProcessor$WSDLLocatorImpl.getImportInputSource(WSDLDocumentProcessor.java:86)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseTypes(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at 
org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLDocumentProcessor.read(WSDLDocumentProcessor.java:141)
at 
org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLDocumentProcessor.read(WSDLDocumentProcessor.java:52)
at 
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.read(ExtensibleURLArtifactProcessor.java:63)
at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:290)
at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:251)
at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:119)
at 
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain$DomainCompositeHelper.addContribution(EmbeddedSCADomain.java:79)


-- 
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: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus

[haleh mahbod]

Can you please also outline what  are the steps that a contributor can
follow to provide updates to the website through this wiki?

Thanks,
Haleh

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


Hi,

I have created the Tuscany Wiki space now on confluence -
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Index.

Mike, I need help with copying the pages over from TUSCANY and then
stubbing
the autoexport for TUSCANYWIKI.  Right now I just about see export and
import of spaces.  Thanks

- Venkat

On 6/13/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
>
> Venkat,
>
> +1 from me.
>
> How to migrate content?  I assume that you mean how do we control the
> process?  The steps in actually moving content are reasonably
> straightforward - but the process for deciding to do it must mirror that
> for placing code into trunk, as mentioned on some other emails...
>
>
> Yours,  Mike.
>
> Venkata Krishnan wrote:
> > Hi, I have the admin access now.  I am able to see the 'Create Space'
> > option
> > on the dashboard now.  Before I go ahead let me conform the following
> >
> > - We are going to create a space named 'Tuscany Wiki' with key
> > 'TUSCANYWIKI'
> > - All contents of the present wiki space 'TUSCANY' will be copied over
> to
> > this new space
> > - We will disable the html autoexport for TUSCANYWIKI as we really
don't
> > need this.
> > - TUSCANYWIKI will be open to all confluence users.
> >
> > Please let me know if any of you have concerns about all of
this.  Also,
> > are
> > we clear about how we are going to migrate content submitted on
> TUSCANYWIKI
> > over to TUSCANY?
> >
> > Thanks
> >
> > - Venkat
> >
> > On 6/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> Ok, thanks Venkat for looking into this.
> >>
> >> Simon
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Does Tuscany SDO C++ support open content properties?

[Pete Robbins]

Open content properties are supported in the SDO C++ implementation. I'm not
sure if support is quite up to "spec" level but it's fairly close.

Deserializing an xml document to SDO without schema is probably "not quite
there" and the XMLHelper and parser code would need looking at to make this
work as per the SDO spec... but I think it could be reasonably simple to
support.

Do you have a particular scenario that you need to work?

Cheers,


On 13/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:


I understand that Tuscany SDO C++ requires types to be defined before
parsing xml documents. Would I be correct in assuming that this is because
open content properties are not yet supported? If so, are there any plans
for implementing this support?

Thanks,

Andy.





--
Pete

Does Tuscany SDO C++ support open content properties?

[Andy Grove]

I understand that Tuscany SDO C++ requires types to be defined before parsing 
xml documents. Would I be correct in assuming that this is because open content 
properties are not yet supported? If so, are there any plans for implementing 
this support?

Thanks,

Andy.

Re: Fixed alert-aggregator/pom.xml, was: svn commit: r546141

[Jean-Sebastien Delfino]

Jean-Sebastien Delfino wrote:

Jean-Sebastien Delfino wrote:
The alert aggregator demo module was not compiling. I fixed it by 
changing a dependency scope from "runtime" to "compile" in pom.xml 
under revision r546698.


Also removed some tabs in pom.xml and fixed the svn:ignore properties 
under the root of the module and src/main/webapp.





One more change: Other demos name their artifact id demo-*. If there's 
no objection I'll change the artifact id from alert-aggregator to 
demo-alert-aggregator.




Done under revision r546962.

--
Jean-Sebastien


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

Re: Build Failure( - Compilation failure) [ \script\ScriptInvoker.java:[52,66] unreported exception java.lang.NoSuchMethodException ]

[ant elder]

Which JDK version are you using - are you using JDK6 by any chance? (and if
so could you try using 5?)

 ...ant

On 6/13/07, sam tam <[EMAIL PROTECTED]> wrote:


Hello,
Am getting some compilation failure during the build !

Does any one have any solution for this !



__



[INFO] Building Apache Tuscany Implementation Script
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://people.apache.org/repo/m2-incubating-repository/groovy/groov
y-all/1.0/groovy-all-1.0.pom
Downloading:
http://repo1.maven.org/maven2/groovy/groovy-all/1.0/groovy-all-1.0.
pom
[INFO] [compiler:compile]
[INFO] Compiling 5 source files to
D:\Tuscany\sca\modules\implementation-script\
target\classes
[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] Compilation failure

D:\Tuscany\sca\modules\implementation-script\src\main\java\org\apache\tuscany\sc
a\implementation\script\ScriptInvoker.java:[52,66] unreported exception
java.lan
g.NoSuchMethodException; must be caught or declared to be thrown




D:\Tuscany\sca\modules\implementation-script\src\main\java\org\apache\tuscany\sc
a\implementation\script\ScriptInvoker.java:[52,66] unreported exception
java.lan
g.NoSuchMethodException; must be caught or declared to be thrown


[INFO]

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

[INFO] Total time: 1 minute 29 seconds
[INFO] Finished at: Wed Jun 13 18:37:16 IST 2007


__




Also i have cleaned the repo and tried again, yet the same error !

Kindly help me out !

Thanks in advance,

Sam...

Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus

[Venkata Krishnan]

Hi,

I have created the Tuscany Wiki space now on confluence -
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Index.

Mike, I need help with copying the pages over from TUSCANY and then stubbing
the autoexport for TUSCANYWIKI.  Right now I just about see export and
import of spaces.  Thanks

- Venkat

On 6/13/07, Mike Edwards <[EMAIL PROTECTED]> wrote:


Venkat,

+1 from me.

How to migrate content?  I assume that you mean how do we control the
process?  The steps in actually moving content are reasonably
straightforward - but the process for deciding to do it must mirror that
for placing code into trunk, as mentioned on some other emails...


Yours,  Mike.

Venkata Krishnan wrote:
> Hi, I have the admin access now.  I am able to see the 'Create Space'
> option
> on the dashboard now.  Before I go ahead let me conform the following
>
> - We are going to create a space named 'Tuscany Wiki' with key
> 'TUSCANYWIKI'
> - All contents of the present wiki space 'TUSCANY' will be copied over
to
> this new space
> - We will disable the html autoexport for TUSCANYWIKI as we really don't
> need this.
> - TUSCANYWIKI will be open to all confluence users.
>
> Please let me know if any of you have concerns about all of this.  Also,
> are
> we clear about how we are going to migrate content submitted on
TUSCANYWIKI
> over to TUSCANY?
>
> Thanks
>
> - Venkat
>
> On 6/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>>
>> Ok, thanks Venkat for looking into this.
>>
>> Simon
>>
>

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

[jira] Created: (TUSCANY-1342) Component-level not supported

[Scott Kurz (JIRA)]

Component-level  not supported
--

 Key: TUSCANY-1342
 URL: https://issues.apache.org/jira/browse/TUSCANY-1342
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.90
Reporter: Scott Kurz


See thread:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18780.html

Something like this does not work:

 



< binding.ws wsdlElement="..."/>

 

-- 
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: Wiki Access issues ? **HELP**

[Venkata Krishnan]

HI Mike,

I have already added you id as 'confluence administrator' which I've
mentioned on another thread on the ML.  Could you please try and let me know
if it works.  Thanks.

- Venkat

On 6/13/07, Mike Edwards <[EMAIL PROTECTED]> wrote:


Folks,

So what's with the Edit access to the Tuscany Wiki??

I don't seem to have edit access at the moment, despite being a
committer.  Who has admin rights for the Wiki?  Can one of the admins
please grant me edit access, please?

Also, I know that there was a discussion about broadening the admin
access for the Wiki.  Has anything been done about that?  My offer to
play admin for the Tuscany Wiki remains open - I have plenty of
experience based on my ownership of the www.osoa.org Wiki, which is also
based on Confluence.

Yours,  Mike.

Simon Laws wrote:
> So I expect this is just the product of edit access being restricted to
> committers. Please comment on Luciano's post here [1] so that  a new
space
> can be provisioned (assuming that this is what is agreed) ASAP.
>
> Simon
>
> [1]
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18622.html
>

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

Re: Website - Consistent navigation menus

[Venkata Krishnan]

Hi Mike, I have added your id in as 'confluence-administrators'.

- Venkat

On 6/13/07, Mike Edwards <[EMAIL PROTECTED]> wrote:


Luciano,

Only just spotted your request in the emails

My user ID is edwardsmj

Do I need to send this directly to infra, or will you handle it?

Yours,  Mike.

Luciano Resende wrote:
> Venkat, Mike, infra is asking for your confluence user ids, could you
> please provide this info.
>
> On 6/8/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>> Conversation seems to have stopped so, from the previous comments...
>>
>> * Confluence admins:
>>
>> Venkat, Luciano, Mike Edwards [1] have been proposed to cover the
>> timezones
>> we operate in. Venkat are you progressing this?
>>
>> * http://cwiki.apache.org/confluence/display/TUSCANY space access:
>>
>> As this is now feeding our main (http://incubator.apache.org/tuscany/)
>> website we have been advised to restrict access to committers to
>> prevent our
>> shop front acquiring dubious content. I have removed "create" access
from
>> confluence users as I think we have been sailing close to the wind on
>> this
>> and it would be a shame to have our web site messed up, particularly as
>> we've recently put out releases and we hope people are looking at them.
>>
>> There are alternative approaches to this blanket change, for example,
>> we may
>> be able to mark all of the web site pages in the /TUSCANY spaces as
>> restricted but this would take some effort and complicate the
management
>> task We could also stop the automatic generation of the site and do it
on
>> demand manually but the idea of linking up the wiki to generate the
>> web site
>> was to avoid this.
>>
>> The main option that is on the table is to go with the committer only
>> access
>> to the TUSCANY space and create other spaces for whatever else we
>> need, for
>> example, a generally accessible wiki. Luciano has started a
conversation
>> about this [2] but I don't see much feedback. If you feel strongly can
>> you
>> go and comment so that we can move this forward quickly now we are
>> restricting create access to /TUSCANY
>>
>> * Contributions to the web site
>>
>> We need to describe a mechanism where non-committers can contribute
>> content
>> to the web site. Looking at the comments here it seems that this will
>> have
>> to be through attaching text, cwiki markup or whatever other resources
>> are
>> required (png, jpg etc) to JIRA so that a committer can update the
site.
>> Logically this is no different from the situation we had when the site
>> was
>> maintained out of svn except of course that we could use diffs then.
>>
>> Regards
>>
>> Simon
>>
>> [1]
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18665.html
>> [2]
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18641.html
>>
>
>

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

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

[Fuhwei Lwo]

I may have missed the reasoning behind refactoring EMF's package name to 
org.apache.tuscany.sdo.emf.*.  Can anyone tell me the benefit by doing that?  
Thanks.

Fuhwei

ant elder <[EMAIL PROTECTED]> wrote: I guess there's various ways it could be 
done, i was thinking of an
sdo-complete jar containing all the sdo classes (org.apache.tuscany.sdo.**)
and all the emf classes renamed from org.eclipse.emf.** to be
org.apache.tuscany.sdo.emf.**.

   ...ant

On 6/13/07, kelvin goodson  wrote:
>
> Ant,  this all sounds good,
> +1 to the spec project move,
> and certainly +1 to aggregating jars if we can
>
> but just to push back one more time, as I can see scope for your response
> to Frank being open to misinterpretation.  Can I check on what you mean by
> renaming the packages,  and whether there are any legal issues there please?
>
>
> Kelvin
>
> On 13/06/07, ant elder  wrote:
> >
> > On 6/13/07, Frank Budinsky  wrote:
> > >
> > > Ant,
> > >
> > > You said this:
> > >
> > > > While building that it could also rename the
> > > > emf packages to start with org.apache.tuscany to avoid any version
> > > problems
> > > > when using Tuscany SDO with existing EMF code.
> > >
> > > We have discussed doing this for quite some time. It would certainly
> > > eliminate the EMF version problems, but I never knew if the Eclipse
> > and
> > > Apache licenses actually allow us to do this. Are you sure that this
> > is
> > > allowed?
> >
> >
> > Pretty sure yes. Its fine for us to distribute the emf binaries as they
> > are
> > "Category B: Binary Licenses Only" as defined in
> > http://www.apache.org/legal/3party.html, and AFAICS there's nothing in
> > the
> > EPL that prevents us doing this.
> >
> >...ant
> >
>
>

Re: 0.91 release?

[Venkata Krishnan]

Thanks for the faith and encouragement.  This is going to be my first
experience and I am sure of getting all the help from you folks to pull this
off successfully.

So, to start with, I propose to cut a branch around June 20th, 2007.  If
people are ok with this, then all that we'd like to be a part of 0.91 should
get in by then (June 20th, 2007).  Does that work fine with everybody?

Also, I'd also like to list down the significant additions / enhancements
over 0.90 for the Release Notes.  You can state the item here on this thread
and I will take care of recording it.

- Venkat

On 6/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:


+1 from me too.  I'm sure Venkat will do a fine job.

   Simon

Jean-Sebastien Delfino wrote:

> Simon Laws wrote:
>
>> Yeah, Venkat did loads on the last release. +1 from me for Venkat as
>> 0.91 RM
>>
>> Simon
>>
>
> +1 from me
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



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

Re: Website - Consistent navigation menus

[Mike Edwards]

Luciano,

Only just spotted your request in the emails

My user ID is edwardsmj

Do I need to send this directly to infra, or will you handle it?

Yours,  Mike.

Luciano Resende wrote:

Venkat, Mike, infra is asking for your confluence user ids, could you
please provide this info.

On 6/8/07, Simon Laws <[EMAIL PROTECTED]> wrote:


Conversation seems to have stopped so, from the previous comments...

* Confluence admins:

Venkat, Luciano, Mike Edwards [1] have been proposed to cover the 
timezones

we operate in. Venkat are you progressing this?

* http://cwiki.apache.org/confluence/display/TUSCANY space access:

As this is now feeding our main (http://incubator.apache.org/tuscany/)
website we have been advised to restrict access to committers to 
prevent our

shop front acquiring dubious content. I have removed "create" access from
confluence users as I think we have been sailing close to the wind on 
this

and it would be a shame to have our web site messed up, particularly as
we've recently put out releases and we hope people are looking at them.

There are alternative approaches to this blanket change, for example, 
we may

be able to mark all of the web site pages in the /TUSCANY spaces as
restricted but this would take some effort and complicate the management
task We could also stop the automatic generation of the site and do it on
demand manually but the idea of linking up the wiki to generate the 
web site

was to avoid this.

The main option that is on the table is to go with the committer only 
access
to the TUSCANY space and create other spaces for whatever else we 
need, for

example, a generally accessible wiki. Luciano has started a conversation
about this [2] but I don't see much feedback. If you feel strongly can 
you

go and comment so that we can move this forward quickly now we are
restricting create access to /TUSCANY

* Contributions to the web site

We need to describe a mechanism where non-committers can contribute 
content
to the web site. Looking at the comments here it seems that this will 
have
to be through attaching text, cwiki markup or whatever other resources 
are

required (png, jpg etc) to JIRA so that a committer can update the site.
Logically this is no different from the situation we had when the site 
was

maintained out of svn except of course that we could use diffs then.

Regards

Simon

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






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

Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus

[Mike Edwards]

Venkat,

+1 from me.

How to migrate content?  I assume that you mean how do we control the 
process?  The steps in actually moving content are reasonably 
straightforward - but the process for deciding to do it must mirror that 
for placing code into trunk, as mentioned on some other emails...



Yours,  Mike.

Venkata Krishnan wrote:
Hi, I have the admin access now.  I am able to see the 'Create Space' 
option

on the dashboard now.  Before I go ahead let me conform the following

- We are going to create a space named 'Tuscany Wiki' with key 
'TUSCANYWIKI'

- All contents of the present wiki space 'TUSCANY' will be copied over to
this new space
- We will disable the html autoexport for TUSCANYWIKI as we really don't
need this.
- TUSCANYWIKI will be open to all confluence users.

Please let me know if any of you have concerns about all of this.  Also, 
are

we clear about how we are going to migrate content submitted on TUSCANYWIKI
over to TUSCANY?

Thanks

- Venkat

On 6/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:



Ok, thanks Venkat for looking into this.

Simon





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

Re: Wiki Access issues ? **HELP**

[Mike Edwards]

Folks,

So what's with the Edit access to the Tuscany Wiki??

I don't seem to have edit access at the moment, despite being a 
committer.  Who has admin rights for the Wiki?  Can one of the admins 
please grant me edit access, please?


Also, I know that there was a discussion about broadening the admin 
access for the Wiki.  Has anything been done about that?  My offer to 
play admin for the Tuscany Wiki remains open - I have plenty of 
experience based on my ownership of the www.osoa.org Wiki, which is also 
based on Confluence.


Yours,  Mike.

Simon Laws wrote:

So I expect this is just the product of edit access being restricted to
committers. Please comment on Luciano's post here [1] so that  a new space
can be provisioned (assuming that this is what is agreed) ASAP.

Simon

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



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

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

[ant elder]

I guess there's various ways it could be done, i was thinking of an
sdo-complete jar containing all the sdo classes (org.apache.tuscany.sdo.**)
and all the emf classes renamed from org.eclipse.emf.** to be
org.apache.tuscany.sdo.emf.**.

  ...ant

On 6/13/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


Ant,  this all sounds good,
+1 to the spec project move,
and certainly +1 to aggregating jars if we can

but just to push back one more time, as I can see scope for your response
to Frank being open to misinterpretation.  Can I check on what you mean by
renaming the packages,  and whether there are any legal issues there please?


Kelvin

On 13/06/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> On 6/13/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
> >
> > Ant,
> >
> > You said this:
> >
> > > While building that it could also rename the
> > > emf packages to start with org.apache.tuscany to avoid any version
> > problems
> > > when using Tuscany SDO with existing EMF code.
> >
> > We have discussed doing this for quite some time. It would certainly
> > eliminate the EMF version problems, but I never knew if the Eclipse
> and
> > Apache licenses actually allow us to do this. Are you sure that this
> is
> > allowed?
>
>
> Pretty sure yes. Its fine for us to distribute the emf binaries as they
> are
> "Category B: Binary Licenses Only" as defined in
> http://www.apache.org/legal/3party.html, and AFAICS there's nothing in
> the
> EPL that prevents us doing this.
>
>...ant
>

Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus

[Simon Nash]

Sounds good to me.  Let's get this started and refine the process as
we go along and learn what's most effective.

  Simon

Venkata Krishnan wrote:

Hi, I have the admin access now.  I am able to see the 'Create Space' 
option

on the dashboard now.  Before I go ahead let me conform the following

- We are going to create a space named 'Tuscany Wiki' with key 
'TUSCANYWIKI'

- All contents of the present wiki space 'TUSCANY' will be copied over to
this new space
- We will disable the html autoexport for TUSCANYWIKI as we really don't
need this.
- TUSCANYWIKI will be open to all confluence users.

Please let me know if any of you have concerns about all of this.  Also, 
are

we clear about how we are going to migrate content submitted on TUSCANYWIKI
over to TUSCANY?

Thanks

- Venkat

On 6/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:



Ok, thanks Venkat for looking into this.

Simon







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

[jira] Created: (TUSCANY-1341) Callback over WS Binding is not functioning various issues

[Lou Amodeo (JIRA)]

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


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(AdminServiceImpl.java:1080)
at 
com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at 
com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:973)
at 
com.ibm.ws.management.commands.AdminServiceCommands$InvokeCmd.execute(AdminServiceCommands.java:251)
at 
com.ibm.ws.console.core.mbean.MBeanHelper.invoke(MBeanHelper.java:239)
at 
com.ibm.ws.console.appdeployment.ApplicationDeploymentCollectionAction.execute(ApplicationDeploymentCollectionAction.java:536)
at 
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
a

[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types

[Ron Gavlin (JIRA)]

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

Ron Gavlin commented on TUSCANY-513:


Kelvin,

My pleasure. Thanks for reviewing and applying this patch so quickly. 

Regards,

- Ron

> Implement support for dynamic subclasses of statically generated types
> --
>
> Key: TUSCANY-513
> URL: https://issues.apache.org/jira/browse/TUSCANY-513
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.0
>
> Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch, 
> tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.2.patch, 
> tuscany-sdo-tools.TUSCANY-513.patch
>
>
> Implement support for dynamic subclasses of statically generated types. See 
> below exerpt from tuscany-user mailing list for details.
> Hi Ron,
> Looking at this, it looks like the problem is that you're trying to create 
> dynamic subclasses of statically generated types. The bad news is that 
> Tuscany doesn't currently support that. The good news is that it's not too 
> hard to add the support.
> The problem is that currently Tuscany only has these two primary 
> DataObject implementation classes:
> 1. DataObjectImpl - is the base class used for statically generated types. 
> It is highly tuned for performance and footprint, so, unlike the base 
> class in SDO1 (actually EMF) it doesn't support dynamic extensions.
> 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is 
> designed for pure dynamic types, not a mixture of static and dynamic.
> To support what you want, we will need another base class, say 
> ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, 
> but doesn't make the assumption that eStaticFeatureCount() is 0. My guess 
> is that there are only a few simple method overrides needed in this class. 
> Maybe you would like to try to prototype such a class yourself and hand 
> modify your generated classes to extend from it? If you did that and 
> tested it, you could submit a patch and we could then very quickly add a 
> generator option to use it (maybe even make it the default). If you'd like 
> to help with this, it would be very much appreciated!
> At any rate, you should probably open a JIRA feature request for this.
> Thanks,
> Frank
> > Frank,
> > 
> > I am working with a mixed static/dynamic model similar to the one 
> > listed at the bottom of this post. The http://example.org/ord 
> > namespace is statically registered and has code-generated classes. The 
> > http://example.org/info/zipcode and http://example.org/info/street 
> > namespaces are dynamically registered with no code-generated 
> > classes. When I attempt to load the Sample Instance (chapter04.xml),
> > I receive an UnsupportedOperationException thrown from 
> > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the 
> > exception is an instance of "InfoTypeImpl" from the "ord" 
> > namespace/ePackage. The EClass parameter is "InfoType" from the 
> > "zipcode" namespace. This instance document loads fine using EMF/SDO
> > 1.0. Any suggestions I can try to work-around this problem?
> > 
> > - Ron
> > 
> > 
> > Sample Instance (chapter04.xml)
> > http://example.org/ord>";
> > xmlns:xsi="";
> > xsi:schemaLocation=" chapter04ord1.xsd">
> > 123ABBCC123
> > 
> > Pat Walmsley
> > 15465
> >  > xmlns:ns1="";>
> > 21043
> > 
> > 
> > 
> > Priscilla Walmsley
> > 15466
> >  > xmlns:ns1="";>
> > 341 Duckworth Way
> > 
> > 
> > 
> > 
> > 557
> > Short-Sleeved Linen Blouse
> > 10
> > 
> > 
> > 
> > 
> > Schema Document 1 (chapter04ord1.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >targetNamespace="";;
> >xmlns="";;
> >xmlns:prod="";;
> >elementFormDefault="qualified">
> > http://example.org/prod>";;
> > schemaLocation="chapter04prod.xsd"/>
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >   >   maxOccurs="unbounded"/>
> >
> >
> >  
> > 
> > Schema Document 2 (chapter04infozipcode.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >xmlns:ord="";;
> >xmlns="";;
> >targetNamespace="";;
> >elementFormDefault="unqualified">
> > http://example.org/ord>";;
> > schemaLocation="chapter04ord1.xsd"/>
> >  
> >  
> > 
> >
> > 

[jira] Resolved: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson resolved TUSCANY-513.


Resolution: Fixed

See my earlier comment

> Implement support for dynamic subclasses of statically generated types
> --
>
> Key: TUSCANY-513
> URL: https://issues.apache.org/jira/browse/TUSCANY-513
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.0
>
> Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch, 
> tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.2.patch, 
> tuscany-sdo-tools.TUSCANY-513.patch
>
>
> Implement support for dynamic subclasses of statically generated types. See 
> below exerpt from tuscany-user mailing list for details.
> Hi Ron,
> Looking at this, it looks like the problem is that you're trying to create 
> dynamic subclasses of statically generated types. The bad news is that 
> Tuscany doesn't currently support that. The good news is that it's not too 
> hard to add the support.
> The problem is that currently Tuscany only has these two primary 
> DataObject implementation classes:
> 1. DataObjectImpl - is the base class used for statically generated types. 
> It is highly tuned for performance and footprint, so, unlike the base 
> class in SDO1 (actually EMF) it doesn't support dynamic extensions.
> 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is 
> designed for pure dynamic types, not a mixture of static and dynamic.
> To support what you want, we will need another base class, say 
> ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, 
> but doesn't make the assumption that eStaticFeatureCount() is 0. My guess 
> is that there are only a few simple method overrides needed in this class. 
> Maybe you would like to try to prototype such a class yourself and hand 
> modify your generated classes to extend from it? If you did that and 
> tested it, you could submit a patch and we could then very quickly add a 
> generator option to use it (maybe even make it the default). If you'd like 
> to help with this, it would be very much appreciated!
> At any rate, you should probably open a JIRA feature request for this.
> Thanks,
> Frank
> > Frank,
> > 
> > I am working with a mixed static/dynamic model similar to the one 
> > listed at the bottom of this post. The http://example.org/ord 
> > namespace is statically registered and has code-generated classes. The 
> > http://example.org/info/zipcode and http://example.org/info/street 
> > namespaces are dynamically registered with no code-generated 
> > classes. When I attempt to load the Sample Instance (chapter04.xml),
> > I receive an UnsupportedOperationException thrown from 
> > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the 
> > exception is an instance of "InfoTypeImpl" from the "ord" 
> > namespace/ePackage. The EClass parameter is "InfoType" from the 
> > "zipcode" namespace. This instance document loads fine using EMF/SDO
> > 1.0. Any suggestions I can try to work-around this problem?
> > 
> > - Ron
> > 
> > 
> > Sample Instance (chapter04.xml)
> > http://example.org/ord>";
> > xmlns:xsi="";
> > xsi:schemaLocation=" chapter04ord1.xsd">
> > 123ABBCC123
> > 
> > Pat Walmsley
> > 15465
> >  > xmlns:ns1="";>
> > 21043
> > 
> > 
> > 
> > Priscilla Walmsley
> > 15466
> >  > xmlns:ns1="";>
> > 341 Duckworth Way
> > 
> > 
> > 
> > 
> > 557
> > Short-Sleeved Linen Blouse
> > 10
> > 
> > 
> > 
> > 
> > Schema Document 1 (chapter04ord1.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >targetNamespace="";;
> >xmlns="";;
> >xmlns:prod="";;
> >elementFormDefault="qualified">
> > http://example.org/prod>";;
> > schemaLocation="chapter04prod.xsd"/>
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >   >   maxOccurs="unbounded"/>
> >
> >
> >  
> > 
> > Schema Document 2 (chapter04infozipcode.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >xmlns:ord="";;
> >xmlns="";;
> >targetNamespace="";;
> >elementFormDefault="unqualified">
> > http://example.org/ord>";;
> > schemaLocation="chapter04ord1.xsd"/>
> >  
> >  
> > 
> >
> >   
> >
> > 
> >  
> >  
> > 
> > Schema Documen

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

[kelvin goodson]

Ant,  this all sounds good,
+1 to the spec project move,
and certainly +1 to aggregating jars if we can

but just to push back one more time, as I can see scope for your response to
Frank being open to misinterpretation.  Can I check on what you mean by
renaming the packages,  and whether there are any legal issues there please?

Kelvin

On 13/06/07, ant elder <[EMAIL PROTECTED]> wrote:


On 6/13/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
>
> Ant,
>
> You said this:
>
> > While building that it could also rename the
> > emf packages to start with org.apache.tuscany to avoid any version
> problems
> > when using Tuscany SDO with existing EMF code.
>
> We have discussed doing this for quite some time. It would certainly
> eliminate the EMF version problems, but I never knew if the Eclipse and
> Apache licenses actually allow us to do this. Are you sure that this is
> allowed?


Pretty sure yes. Its fine for us to distribute the emf binaries as they
are
"Category B: Binary Licenses Only" as defined in
http://www.apache.org/legal/3party.html, and AFAICS there's nothing in the
EPL that prevents us doing this.

   ...ant

[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson commented on TUSCANY-513:


Fixed in commit 546884.  Thanks for taking the trouble to produce a nice clean 
patch Ron. Apart from all the functional stuff it was great that the licenses 
were all in place,  the new test case was hooked up into AllTests, the model 
files were updated, the test data organisation was good;  I really appreciate 
this.

> Implement support for dynamic subclasses of statically generated types
> --
>
> Key: TUSCANY-513
> URL: https://issues.apache.org/jira/browse/TUSCANY-513
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.0
>
> Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch, 
> tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.2.patch, 
> tuscany-sdo-tools.TUSCANY-513.patch
>
>
> Implement support for dynamic subclasses of statically generated types. See 
> below exerpt from tuscany-user mailing list for details.
> Hi Ron,
> Looking at this, it looks like the problem is that you're trying to create 
> dynamic subclasses of statically generated types. The bad news is that 
> Tuscany doesn't currently support that. The good news is that it's not too 
> hard to add the support.
> The problem is that currently Tuscany only has these two primary 
> DataObject implementation classes:
> 1. DataObjectImpl - is the base class used for statically generated types. 
> It is highly tuned for performance and footprint, so, unlike the base 
> class in SDO1 (actually EMF) it doesn't support dynamic extensions.
> 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is 
> designed for pure dynamic types, not a mixture of static and dynamic.
> To support what you want, we will need another base class, say 
> ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, 
> but doesn't make the assumption that eStaticFeatureCount() is 0. My guess 
> is that there are only a few simple method overrides needed in this class. 
> Maybe you would like to try to prototype such a class yourself and hand 
> modify your generated classes to extend from it? If you did that and 
> tested it, you could submit a patch and we could then very quickly add a 
> generator option to use it (maybe even make it the default). If you'd like 
> to help with this, it would be very much appreciated!
> At any rate, you should probably open a JIRA feature request for this.
> Thanks,
> Frank
> > Frank,
> > 
> > I am working with a mixed static/dynamic model similar to the one 
> > listed at the bottom of this post. The http://example.org/ord 
> > namespace is statically registered and has code-generated classes. The 
> > http://example.org/info/zipcode and http://example.org/info/street 
> > namespaces are dynamically registered with no code-generated 
> > classes. When I attempt to load the Sample Instance (chapter04.xml),
> > I receive an UnsupportedOperationException thrown from 
> > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the 
> > exception is an instance of "InfoTypeImpl" from the "ord" 
> > namespace/ePackage. The EClass parameter is "InfoType" from the 
> > "zipcode" namespace. This instance document loads fine using EMF/SDO
> > 1.0. Any suggestions I can try to work-around this problem?
> > 
> > - Ron
> > 
> > 
> > Sample Instance (chapter04.xml)
> > http://example.org/ord>";
> > xmlns:xsi="";
> > xsi:schemaLocation=" chapter04ord1.xsd">
> > 123ABBCC123
> > 
> > Pat Walmsley
> > 15465
> >  > xmlns:ns1="";>
> > 21043
> > 
> > 
> > 
> > Priscilla Walmsley
> > 15466
> >  > xmlns:ns1="";>
> > 341 Duckworth Way
> > 
> > 
> > 
> > 
> > 557
> > Short-Sleeved Linen Blouse
> > 10
> > 
> > 
> > 
> > 
> > Schema Document 1 (chapter04ord1.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >targetNamespace="";;
> >xmlns="";;
> >xmlns:prod="";;
> >elementFormDefault="qualified">
> > http://example.org/prod>";;
> > schemaLocation="chapter04prod.xsd"/>
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >   >   maxOccurs="unbounded"/>
> >
> >
> >  
> > 
> > Schema Document 2 (chapter04infozipcode.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >xmlns:ord="";;
> >xmlns="";;
> >tar

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

[ant elder]

On 6/13/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:


Ant,

You said this:

> While building that it could also rename the
> emf packages to start with org.apache.tuscany to avoid any version
problems
> when using Tuscany SDO with existing EMF code.

We have discussed doing this for quite some time. It would certainly
eliminate the EMF version problems, but I never knew if the Eclipse and
Apache licenses actually allow us to do this. Are you sure that this is
allowed?



Pretty sure yes. Its fine for us to distribute the emf binaries as they are
"Category B: Binary Licenses Only" as defined in
http://www.apache.org/legal/3party.html, and AFAICS there's nothing in the
EPL that prevents us doing this.

  ...ant

Re: SCA Binding and Disitribution was: Distributed Composites

[Simon Laws]

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


Hi,

I like the topology.xml approach. For the topology composite, I suggest
that
we use a syntax something like the following:


  


http://$host:8080/acbd";> 
https://$host:8090/acbd";>
   


http://$host:8085/jsonxyz";>
   


http://$host:1234/>
   

  
  

  
   ...


- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, June 06, 2007 7:20 AM
Subject: Re: SCA Binding and Disitribution was: Distributed Composites


> [snip]
> Simon Laws wrote:
>> Ok, I've taken the next step here and have a distributed runtime
example
>> running in my sandbox. A sample calculator application [1] showing the
>> disitributed runtime in action and a module containing the changes I
had
>> to
>> make to the runtime to get this to work [2]. The changes are actually
>> trivial but getting them in the appropriate place was a bit of a
>> challenge.
>>
>> Looking at the sample first I have, for the purposes of this example,
>> chosen
>> to extend the SCDL model with extra attributes to indicate which
runtime
>> a
>> component will run in.
>>
>> > runtimeId="sca://mydomain/A">
>>
>> This information could have been conveyed in many other ways so
>> alternative
>> suggestions are welcome.
>
> This is a pretty nice starting point.
>
> I would suggest to try to separate the topology description information
> from the logical SCA domain composition:
> - what runtimes are available
> - for each runtime:
>- the (logical) addresses at which it can be reached for each SCA
> binding type
>- the components allocated to that runtime
>
> Here are two suggestions for doing this:
>
> A topology.config file, something like that:
>
> runtimeA:
>  binding.ws: http://localhost:8080/acbd
>  binding.sca: http://localhost:1234
>  binding.jsonrpc: http://localhost:8085/jsonxyz
>  components: CalculatorServiceComponent, AddServiceComponent
>
> runtimeB:
>  binding.ws: http:myotherhost:6060/tuvw
>  binding.sca: http://myotherhost:5678
>  components: MultiplyServiceComponent, SubtractServiceComponent,
> DivideServiceComponent
>
> or a topology.xml file, where we would actually describe the SCA
runtimes,
> their configuration and how they are assembled on a network using an SCA
> assembly:
>
> topology.xml
> 
>  http://localhost:8080/acbd"/>
>  http://localhost:8085/jsonxyz"/>
>  http://localhost:1234"/>
>
>
>  
>  
>   
>  
>
>  
>
>  http://myotherhost:6060/tuvw"/>
>  http://myotherhost:5678"/>
>
>
>  
>  
>  
>   
>  
> 
>
> What I find interesting with that second form - apart from the fact that
> the user won't have to learn another configuration language if he
already
> knows SCA - is that we could use the  configurations in that
> topology file to host default configuration for the bindings described
in
> the SCA domain.
>
> Then the notation that you're proposing with the runtime ID inlined in
the
> SCA domain logical assembly could be supported as well, but as a
> progressive/shortcut option for want to inline the runtime allocation in
> their SCA domain composite. However, we would have the capability, in
our
> underlying configuration model and runtime implementation to completely
> separate the logical SCA domain composition and the topology
description,
> which are really two different dimensions of the configuration of a
> service network.
>
> Thoughts?
>>
>>
>> [1]
>>
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/calculator-distributed/
>> [2]
>>
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/disitributed-changes/
>>
>> [3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18242.html
>>
>
> --
> Jean-Sebastien
>
>
> -
> 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]

Thinking about the proposals that have been made in this thread. I like

the idea of using the SCA concept of "component" to describe the services
that the runtime must implement to allow the distributed behaviour to be
managed. I think we can take it even further at that level but I still
think  it's  confusing to represent the runtime level as a composite.

Here's another shot:


 
   http://$host:8080/acbd";>
   https://$host:8090/acbd";>
   
 
 
   
  


  
   
 
   
   
   
   
 

 
   http://$host:8081/acbd";>
   https://$host:8091/acbd";>
   
 
 
   
 
   
 
   
 
   
   
   
 


Here I've invented some top level elements to represent the runtime itself
and concentrated on representing the

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

[Frank Budinsky]

Ant,

You said this:

> While building that it could also rename the
> emf packages to start with org.apache.tuscany to avoid any version 
problems
> when using Tuscany SDO with existing EMF code.

We have discussed doing this for quite some time. It would certainly 
eliminate the EMF version problems, but I never knew if the Eclipse and 
Apache licenses actually allow us to do this. Are you sure that this is 
allowed?

Thanks,
Frank

[EMAIL PROTECTED] wrote on 06/13/2007 08:54:23 AM:

> On 6/11/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> >
> > Good suggestion Steffen.  If you were able to open a Jira and dump 
into it
> > any thoughts you may have had about the details of how you see this
> > working
> > that would be great.  The more detail you put there, the more likely 
it is
> > that someone who wants to get their hands dirty would be likely to 
pick it
> > up;  unless of course you have plans for doing it yourself. As an 
aside,
> > it's always interesting to know the background to why a particular 
feature
> > is important to someone, so if you felt like commenting on your 
scenarios
> > that would benefit from this too,  whether in the JIRA on or the
> > list,  that
> > would be great.
> >
> > For my part here are the things that I'd like to see done ...
> > - reorganisation of the build to create release distributions in line 
with
> > the SCA release format
> 
> 
> One thing we should do for this right now is move spec/sdo-api from the
> Tuscany SVN trunk top-level folder into the sdo folder, so sdo/sdo-api.
> 
> Another thing i'd wondered about was making an sdo jar that contained 
all
> the emf dependencies to simplify things for users. So that would be
> something like  all the codegen, ecore, xsd and tuscany-sdo-* jars 
merged
> into a single sdo-complete.jar. While building that it could also rename 
the
> emf packages to start with org.apache.tuscany to avoid any version 
problems
> when using Tuscany SDO with existing EMF code. Does anyone else think 
this
> would be useful?
> 
>...ant


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

Build Failure( - Compilation failure) [ \script\ScriptInvoker.java:[52,66] unreported exception java.lang.NoSuchMethodException ]

[sam tam]

Hello,
Am getting some compilation failure during the build !

Does any one have any solution for this !


__



[INFO] Building Apache Tuscany Implementation Script
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://people.apache.org/repo/m2-incubating-repository/groovy/groov
y-all/1.0/groovy-all-1.0.pom
Downloading:
http://repo1.maven.org/maven2/groovy/groovy-all/1.0/groovy-all-1.0.
pom
[INFO] [compiler:compile]
[INFO] Compiling 5 source files to
D:\Tuscany\sca\modules\implementation-script\
target\classes
[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] Compilation failure
D:\Tuscany\sca\modules\implementation-script\src\main\java\org\apache\tuscany\sc
a\implementation\script\ScriptInvoker.java:[52,66] unreported exception
java.lan
g.NoSuchMethodException; must be caught or declared to be thrown



D:\Tuscany\sca\modules\implementation-script\src\main\java\org\apache\tuscany\sc
a\implementation\script\ScriptInvoker.java:[52,66] unreported exception
java.lan
g.NoSuchMethodException; must be caught or declared to be thrown


[INFO]

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

[INFO] Total time: 1 minute 29 seconds
[INFO] Finished at: Wed Jun 13 18:37:16 IST 2007

__




Also i have cleaned the repo and tried again, yet the same error !

Kindly help me out !

Thanks in advance,

Sam...

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

[ant elder]

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


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

For my part here are the things that I'd like to see done ...
- reorganisation of the build to create release distributions in line with
the SCA release format



One thing we should do for this right now is move spec/sdo-api from the
Tuscany SVN trunk top-level folder into the sdo folder, so sdo/sdo-api.

Another thing i'd wondered about was making an sdo jar that contained all
the emf dependencies to simplify things for users. So that would be
something like  all the codegen, ecore, xsd and tuscany-sdo-* jars merged
into a single sdo-complete.jar. While building that it could also rename the
emf packages to start with org.apache.tuscany to avoid any version problems
when using Tuscany SDO with existing EMF code. Does anyone else think this
would be useful?

  ...ant

Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus

[ant elder]

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


Hi, I have the admin access now.  I am able to see the 'Create Space'
option
on the dashboard now.  Before I go ahead let me conform the following

- We are going to create a space named 'Tuscany Wiki' with key
'TUSCANYWIKI'
- All contents of the present wiki space 'TUSCANY' will be copied over to
this new space
- We will disable the html autoexport for TUSCANYWIKI as we really don't
need this.
- TUSCANYWIKI will be open to all confluence users.

Please let me know if any of you have concerns about all of this.  Also,
are
we clear about how we are going to migrate content submitted on
TUSCANYWIKI
over to TUSCANY?



That all sounds ok to me. For the migrate how about we just ask people to
use JIRAs as is done with code changes. Then for non-trivial changes we're
moving to the main website we can start making sure users either have an
ICLA on file and/or tick the JIRA box granting rights to the ASF.

  ...ant

Re: [jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types

[kelvin goodson]

Ron,
I'm looking at this right now.
Kelvin.

On 13/06/07, Ron Gavlin (JIRA)  wrote:



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

Ron Gavlin commented on TUSCANY-513:


Folks,

I have attached version 2 of the patch for this issue. It includes the
test harness that I accidentally left out of the previous patch. Since the
patch includes changes that affect code-generated classes, I regenerated
most of those classes, except for the classes generated by the ModelFactory.
I applied the changes by hand to those classes. Please let me know if you
have questions. Your timely feedback and subsequent application of the patch
is appreciated.

Regards,

- Ron

> Implement support for dynamic subclasses of statically generated types
> --
>
> Key: TUSCANY-513
> URL: https://issues.apache.org/jira/browse/TUSCANY-513
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.0
>
> Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch,
tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.2.patch,
tuscany-sdo-tools.TUSCANY-513.patch
>
>
> Implement support for dynamic subclasses of statically generated types.
See below exerpt from tuscany-user mailing list for details.
> Hi Ron,
> Looking at this, it looks like the problem is that you're trying to
create
> dynamic subclasses of statically generated types. The bad news is that
> Tuscany doesn't currently support that. The good news is that it's not
too
> hard to add the support.
> The problem is that currently Tuscany only has these two primary
> DataObject implementation classes:
> 1. DataObjectImpl - is the base class used for statically generated
types.
> It is highly tuned for performance and footprint, so, unlike the base
> class in SDO1 (actually EMF) it doesn't support dynamic extensions.
> 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It
is
> designed for pure dynamic types, not a mixture of static and dynamic.
> To support what you want, we will need another base class, say
> ExtensibleDataObjectImpl, that is quite similar to
DynamicDataObjectImpl,
> but doesn't make the assumption that eStaticFeatureCount() is 0. My
guess
> is that there are only a few simple method overrides needed in this
class.
> Maybe you would like to try to prototype such a class yourself and hand
> modify your generated classes to extend from it? If you did that and
> tested it, you could submit a patch and we could then very quickly add a
> generator option to use it (maybe even make it the default). If you'd
like
> to help with this, it would be very much appreciated!
> At any rate, you should probably open a JIRA feature request for this.
> Thanks,
> Frank
> > Frank,
> >
> > I am working with a mixed static/dynamic model similar to the one
> > listed at the bottom of this post. The http://example.org/ord
> > namespace is statically registered and has code-generated classes. The
> > http://example.org/info/zipcode and http://example.org/info/street
> > namespaces are dynamically registered with no code-generated
> > classes. When I attempt to load the Sample Instance (chapter04.xml),
> > I receive an UnsupportedOperationException thrown from
> > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the
> > exception is an instance of "InfoTypeImpl" from the "ord"
> > namespace/ePackage. The EClass parameter is "InfoType" from the
> > "zipcode" namespace. This instance document loads fine using EMF/SDO
> > 1.0. Any suggestions I can try to work-around this problem?
> >
> > - Ron
> >
> >
> > Sample Instance (chapter04.xml)
> > http://example.org/ord>";
> > xmlns:xsi="";
> > xsi:schemaLocation=" chapter04ord1.xsd">
> > 123ABBCC123
> > 
> > Pat Walmsley
> > 15465
> >  > xmlns:ns1="";>
> > 21043
> > 
> > 
> > 
> > Priscilla Walmsley
> > 15466
> >  > xmlns:ns1="";>
> > 341 Duckworth Way
> > 
> > 
> > 
> > 
> > 557
> > Short-Sleeved Linen Blouse
> > 10
> > 
> > 
> > 
> > 
> > Schema Document 1 (chapter04ord1.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >targetNamespace="";;
> >xmlns="";;
> >xmlns:prod="";;
> >elementFormDefault="qualified">
> > http://example.org/prod>";;
> > schemaLocation="chapter04prod.xsd"/>
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >   >   maxOccurs="unbounded"/>
> >
> >
> >  
> > 
> > Schema Docume

Re: Geronimo/Tuscany integration

[Vamsavardhana Reddy]

Hi,

Myself and Manu have been working on the integration thing.  As a
first step, we have created a plugin for Geronimo that will let the
user to deploy standalone tuscany modules into Geronimo and use the
deployed services by looking up in JNDI.  I have put the code in
Geronimo Sandbox at
https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/.

Going forward, we have the following in mind:
A) Write a deploymentwatcher so that Tuscany modules can be bundled as
part of J2EE artifacts.
B) Extend the current deployer to enable Tuscany Modules deployed in
Geronimo to access resources like datasources from Geronimo

Some of the questions we have are:
1.  Should we use this plugin approach or intergrate Tuscany to be
bundled as part of the Geronimo distribution?
2.  Should we have support for bundling Tuscany composites in WAR,
EJB-JAR and EAR?  Or should we provide for adding a separate Tuscany
module in EAR?
3.  Where should we maintain the integration code?

Your comments and suggestions will be very helpful.

Thanks and best regards,
Vamsi

On 5/10/07, Manu George <[EMAIL PROTECTED]> wrote:

Hi Raymond/Jay,

  I would like to join this effort. I would like to discuss what
is expected of the deep integration. I will just list down my
understanding of both the current and proposed integrations

Understanding of the Current Integration

1) TuscanyContextListener creates an SCA domain when the servlet is
created and then destroys it when the servlet is destroyed.
2) During SCA domain creation it looks up the composites and deploys
them in the domain
Creates a webapp module activator for registering servlet hosts.
3) Finally we have a servlet that forwards requests to the servlet
registered with the Tuscany Servlet Host.
4) An SCADomain is created for each application and we can lookup the
services from the SCADomain.
5) During SCADomain creation a runtime is also created for the DefaultSCADomain.
7) All tuscany classes are loaded repeatedly for each application in
separate classloaders.
8) A runtime is created per application

Understanding/Doubts about the proposed Integration.

1) Each SCA application will have an SCA module which will be a jar
with an SCDL in META-INF. This jar can also be part of an EAR. . There
will be a Tuscany deployer that will take care of deploying the SCA
modules. Should WAR files be also able to contain SCA jars?
2) Each App will have an SCA Domain which will be instantiated when
the application starts. Is this assumption correct or can there be
multiple SCADomains per app?
3) The Tuscany classes are loaded only once and then shared between
the different SCA applications.
4) There will be multiple domains instantiated from different
applications and there should be a server wide domain registry where
applications can look up and invoke different composites from domains
different from their own. (Can this be Global JNDI/Gbean refs or is
there something specific in tuscany).
5) There should be only a single Tuscany Runtime for the entire
geronimo instance.
6) How can we lookup the services running in one geronimo instance
from an app in another geronimo instance. Is this supported in Tuscany

These are just the initial set of points/questions that hit me when I
thought about the integration. Jay /Raymond I guess you guys will be
aware of many other points as well. Can you reply with your analysis
so that we can flesh out the requirements completely in the mailing
list. That way both the communities can contribute their thoughts. If
you have already started can you just point me to where I can catch up
on what has happened?

Thanks
Manu

On 4/26/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi, Geronimo community.
>
> As you may know, Tuscany is an Apache project under incubation to provide an
> open source SOA infrastructure. For more information, you can visit
> http://cwiki.apache.org/TUSCANY/.
>
> Tuscany implements the SCA specification (http://www.osoa.org) and allows
> you to develop and run SCA components in various hosting environments. We
> currently integrate with Tomcat and Jetty and would like to try to integrate
> with Geronimo as well. I would like to start some discussions here to figure
> out the best way to do that.
>
> After some preliminary investigations of Geronimo, I feel that there are two
> options on the table so far.
>
> 1) Shallow integration: Package SCA applications together with the Tuscany
> runtime as WARs and deploy them Geronimo as Web applications. It's basically
> the integration with a Web container. We register a TuscanyContextListner
> (which implements javax.servlet.ServletContextListener) in web.xml to
> start/stop the Tuscany runtime when the web application is started/stopped.
>
> This will allow us to support the following use cases:
> * A Web application hosted by Geronimo with business logic written as SCA
> components
> * Expose one or more SCA components as Web services over HTTP as supported
> by the Web container.

Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus

[Venkata Krishnan]

Hi, I have the admin access now.  I am able to see the 'Create Space' option
on the dashboard now.  Before I go ahead let me conform the following

- We are going to create a space named 'Tuscany Wiki' with key 'TUSCANYWIKI'
- All contents of the present wiki space 'TUSCANY' will be copied over to
this new space
- We will disable the html autoexport for TUSCANYWIKI as we really don't
need this.
- TUSCANYWIKI will be open to all confluence users.

Please let me know if any of you have concerns about all of this.  Also, are
we clear about how we are going to migrate content submitted on TUSCANYWIKI
over to TUSCANY?

Thanks

- Venkat

On 6/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:


Ok, thanks Venkat for looking into this.

Simon

[jira] Resolved: (TUSCANY-1297) xsi:type in generated XML causes it not to validate/load into: visual studio or Mindreef SOAPscope

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-1297.
---

Resolution: Fixed

> xsi:type in generated XML causes it not to validate/load into: visual studio 
> or Mindreef SOAPscope
> --
>
> Key: TUSCANY-1297
> URL: https://issues.apache.org/jira/browse/TUSCANY-1297
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: any
>Reporter: Matthew Peters
> Fix For: Cpp-Next
>
>
> We use SDO to build and generate WSDL. We use the standard WSDL and SOAP 
> schemas (schemata?) to build the model then add port, operation, binding etc. 
> elements, then serialise the lot to XML. There are occasional xsi:type 
> attributes in the serialised XML which cause the WSDL not to validate or load 
> in visual studio. Here is a snippet from WSDL that we have generated in this 
> way:
>  type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">
> 
>   
> 
>   
>   
> 
>   
>   
> 
>  transport="http://schemas.xmlsoap.org/soap/http"; style="document"/>
>   
> These xsi:type attributes cause this WSDL to fail to load. I quote one of our 
> users:
> > MS Visual Studio (I'm using Visual Web Dev 2005 Express Edition) will
> > not import a SCA generated WSDL.  It complains that it does not validate
> > because of the following element attributes:
> > xsi:type="tns3:tBody"  of 
> > xsi:type="tns3:tAddress" of 
> > Stripping out these attributes resolved the VS WSDL import problem.
> and a different bug report but the same problem:
> > WSDL generated does not validate (ran against the oXygen editor and
> Mindreef SOAPscope). 

-- 
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-513) Implement support for dynamic subclasses of statically generated types

[Ron Gavlin (JIRA)]

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

Ron Gavlin commented on TUSCANY-513:


Folks,

I have attached version 2 of the patch for this issue. It includes the test 
harness that I accidentally left out of the previous patch. Since the patch 
includes changes that affect code-generated classes, I regenerated most of 
those classes, except for the classes generated by the ModelFactory. I applied 
the changes by hand to those classes. Please let me know if you have questions. 
Your timely feedback and subsequent application of the patch is appreciated.

Regards,

- Ron

> Implement support for dynamic subclasses of statically generated types
> --
>
> Key: TUSCANY-513
> URL: https://issues.apache.org/jira/browse/TUSCANY-513
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.0
>
> Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch, 
> tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.2.patch, 
> tuscany-sdo-tools.TUSCANY-513.patch
>
>
> Implement support for dynamic subclasses of statically generated types. See 
> below exerpt from tuscany-user mailing list for details.
> Hi Ron,
> Looking at this, it looks like the problem is that you're trying to create 
> dynamic subclasses of statically generated types. The bad news is that 
> Tuscany doesn't currently support that. The good news is that it's not too 
> hard to add the support.
> The problem is that currently Tuscany only has these two primary 
> DataObject implementation classes:
> 1. DataObjectImpl - is the base class used for statically generated types. 
> It is highly tuned for performance and footprint, so, unlike the base 
> class in SDO1 (actually EMF) it doesn't support dynamic extensions.
> 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is 
> designed for pure dynamic types, not a mixture of static and dynamic.
> To support what you want, we will need another base class, say 
> ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, 
> but doesn't make the assumption that eStaticFeatureCount() is 0. My guess 
> is that there are only a few simple method overrides needed in this class. 
> Maybe you would like to try to prototype such a class yourself and hand 
> modify your generated classes to extend from it? If you did that and 
> tested it, you could submit a patch and we could then very quickly add a 
> generator option to use it (maybe even make it the default). If you'd like 
> to help with this, it would be very much appreciated!
> At any rate, you should probably open a JIRA feature request for this.
> Thanks,
> Frank
> > Frank,
> > 
> > I am working with a mixed static/dynamic model similar to the one 
> > listed at the bottom of this post. The http://example.org/ord 
> > namespace is statically registered and has code-generated classes. The 
> > http://example.org/info/zipcode and http://example.org/info/street 
> > namespaces are dynamically registered with no code-generated 
> > classes. When I attempt to load the Sample Instance (chapter04.xml),
> > I receive an UnsupportedOperationException thrown from 
> > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the 
> > exception is an instance of "InfoTypeImpl" from the "ord" 
> > namespace/ePackage. The EClass parameter is "InfoType" from the 
> > "zipcode" namespace. This instance document loads fine using EMF/SDO
> > 1.0. Any suggestions I can try to work-around this problem?
> > 
> > - Ron
> > 
> > 
> > Sample Instance (chapter04.xml)
> > http://example.org/ord>";
> > xmlns:xsi="";
> > xsi:schemaLocation=" chapter04ord1.xsd">
> > 123ABBCC123
> > 
> > Pat Walmsley
> > 15465
> >  > xmlns:ns1="";>
> > 21043
> > 
> > 
> > 
> > Priscilla Walmsley
> > 15466
> >  > xmlns:ns1="";>
> > 341 Duckworth Way
> > 
> > 
> > 
> > 
> > 557
> > Short-Sleeved Linen Blouse
> > 10
> > 
> > 
> > 
> > 
> > Schema Document 1 (chapter04ord1.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >targetNamespace="";;
> >xmlns="";;
> >xmlns:prod="";;
> >elementFormDefault="qualified">
> > http://example.org/prod>";;
> > schemaLocation="chapter04prod.xsd"/>
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >   >   maxOccurs="unbounded"/>
> >
> >
> >  
> > 
> > Schema Document 2 (chapter04infozipcode.xsd)
> > http:

[jira] Updated: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types

[Ron Gavlin (JIRA)]

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

Ron Gavlin updated TUSCANY-513:
---

Attachment: tuscany-sdo-tools.TUSCANY-513.2.patch

> Implement support for dynamic subclasses of statically generated types
> --
>
> Key: TUSCANY-513
> URL: https://issues.apache.org/jira/browse/TUSCANY-513
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.0
>
> Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch, 
> tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.2.patch, 
> tuscany-sdo-tools.TUSCANY-513.patch
>
>
> Implement support for dynamic subclasses of statically generated types. See 
> below exerpt from tuscany-user mailing list for details.
> Hi Ron,
> Looking at this, it looks like the problem is that you're trying to create 
> dynamic subclasses of statically generated types. The bad news is that 
> Tuscany doesn't currently support that. The good news is that it's not too 
> hard to add the support.
> The problem is that currently Tuscany only has these two primary 
> DataObject implementation classes:
> 1. DataObjectImpl - is the base class used for statically generated types. 
> It is highly tuned for performance and footprint, so, unlike the base 
> class in SDO1 (actually EMF) it doesn't support dynamic extensions.
> 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is 
> designed for pure dynamic types, not a mixture of static and dynamic.
> To support what you want, we will need another base class, say 
> ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, 
> but doesn't make the assumption that eStaticFeatureCount() is 0. My guess 
> is that there are only a few simple method overrides needed in this class. 
> Maybe you would like to try to prototype such a class yourself and hand 
> modify your generated classes to extend from it? If you did that and 
> tested it, you could submit a patch and we could then very quickly add a 
> generator option to use it (maybe even make it the default). If you'd like 
> to help with this, it would be very much appreciated!
> At any rate, you should probably open a JIRA feature request for this.
> Thanks,
> Frank
> > Frank,
> > 
> > I am working with a mixed static/dynamic model similar to the one 
> > listed at the bottom of this post. The http://example.org/ord 
> > namespace is statically registered and has code-generated classes. The 
> > http://example.org/info/zipcode and http://example.org/info/street 
> > namespaces are dynamically registered with no code-generated 
> > classes. When I attempt to load the Sample Instance (chapter04.xml),
> > I receive an UnsupportedOperationException thrown from 
> > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the 
> > exception is an instance of "InfoTypeImpl" from the "ord" 
> > namespace/ePackage. The EClass parameter is "InfoType" from the 
> > "zipcode" namespace. This instance document loads fine using EMF/SDO
> > 1.0. Any suggestions I can try to work-around this problem?
> > 
> > - Ron
> > 
> > 
> > Sample Instance (chapter04.xml)
> > http://example.org/ord>";
> > xmlns:xsi="";
> > xsi:schemaLocation=" chapter04ord1.xsd">
> > 123ABBCC123
> > 
> > Pat Walmsley
> > 15465
> >  > xmlns:ns1="";>
> > 21043
> > 
> > 
> > 
> > Priscilla Walmsley
> > 15466
> >  > xmlns:ns1="";>
> > 341 Duckworth Way
> > 
> > 
> > 
> > 
> > 557
> > Short-Sleeved Linen Blouse
> > 10
> > 
> > 
> > 
> > 
> > Schema Document 1 (chapter04ord1.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >targetNamespace="";;
> >xmlns="";;
> >xmlns:prod="";;
> >elementFormDefault="qualified">
> > http://example.org/prod>";;
> > schemaLocation="chapter04prod.xsd"/>
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >   >   maxOccurs="unbounded"/>
> >
> >
> >  
> > 
> > Schema Document 2 (chapter04infozipcode.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >xmlns:ord="";;
> >xmlns="";;
> >targetNamespace="";;
> >elementFormDefault="unqualified">
> > http://example.org/ord>";;
> > schemaLocation="chapter04ord1.xsd"/>
> >  
> >  
> > 
> >
> >   
> >
> > 
> >  
> >  
> > 
> > Schema Document 

[jira] Updated: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types

[Ron Gavlin (JIRA)]

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

Ron Gavlin updated TUSCANY-513:
---

Attachment: tuscany-sdo-impl.TUSCANY-513.2.patch

> Implement support for dynamic subclasses of statically generated types
> --
>
> Key: TUSCANY-513
> URL: https://issues.apache.org/jira/browse/TUSCANY-513
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.0
>
> Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch, 
> tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch
>
>
> Implement support for dynamic subclasses of statically generated types. See 
> below exerpt from tuscany-user mailing list for details.
> Hi Ron,
> Looking at this, it looks like the problem is that you're trying to create 
> dynamic subclasses of statically generated types. The bad news is that 
> Tuscany doesn't currently support that. The good news is that it's not too 
> hard to add the support.
> The problem is that currently Tuscany only has these two primary 
> DataObject implementation classes:
> 1. DataObjectImpl - is the base class used for statically generated types. 
> It is highly tuned for performance and footprint, so, unlike the base 
> class in SDO1 (actually EMF) it doesn't support dynamic extensions.
> 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is 
> designed for pure dynamic types, not a mixture of static and dynamic.
> To support what you want, we will need another base class, say 
> ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, 
> but doesn't make the assumption that eStaticFeatureCount() is 0. My guess 
> is that there are only a few simple method overrides needed in this class. 
> Maybe you would like to try to prototype such a class yourself and hand 
> modify your generated classes to extend from it? If you did that and 
> tested it, you could submit a patch and we could then very quickly add a 
> generator option to use it (maybe even make it the default). If you'd like 
> to help with this, it would be very much appreciated!
> At any rate, you should probably open a JIRA feature request for this.
> Thanks,
> Frank
> > Frank,
> > 
> > I am working with a mixed static/dynamic model similar to the one 
> > listed at the bottom of this post. The http://example.org/ord 
> > namespace is statically registered and has code-generated classes. The 
> > http://example.org/info/zipcode and http://example.org/info/street 
> > namespaces are dynamically registered with no code-generated 
> > classes. When I attempt to load the Sample Instance (chapter04.xml),
> > I receive an UnsupportedOperationException thrown from 
> > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the 
> > exception is an instance of "InfoTypeImpl" from the "ord" 
> > namespace/ePackage. The EClass parameter is "InfoType" from the 
> > "zipcode" namespace. This instance document loads fine using EMF/SDO
> > 1.0. Any suggestions I can try to work-around this problem?
> > 
> > - Ron
> > 
> > 
> > Sample Instance (chapter04.xml)
> > http://example.org/ord>";
> > xmlns:xsi="";
> > xsi:schemaLocation=" chapter04ord1.xsd">
> > 123ABBCC123
> > 
> > Pat Walmsley
> > 15465
> >  > xmlns:ns1="";>
> > 21043
> > 
> > 
> > 
> > Priscilla Walmsley
> > 15466
> >  > xmlns:ns1="";>
> > 341 Duckworth Way
> > 
> > 
> > 
> > 
> > 557
> > Short-Sleeved Linen Blouse
> > 10
> > 
> > 
> > 
> > 
> > Schema Document 1 (chapter04ord1.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >targetNamespace="";;
> >xmlns="";;
> >xmlns:prod="";;
> >elementFormDefault="qualified">
> > http://example.org/prod>";;
> > schemaLocation="chapter04prod.xsd"/>
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >  
> >
> >  
> >  
> >  
> >
> >  
> >   >   maxOccurs="unbounded"/>
> >
> >
> >  
> > 
> > Schema Document 2 (chapter04infozipcode.xsd)
> > http://www.w3.org/2001/XMLSchema>";;
> >xmlns:ord="";;
> >xmlns="";;
> >targetNamespace="";;
> >elementFormDefault="unqualified">
> > http://example.org/ord>";;
> > schemaLocation="chapter04ord1.xsd"/>
> >  
> >  
> > 
> >
> >   
> >
> > 
> >  
> >  
> > 
> > Schema Document 3 (chapter04infostreet.xsd)
> > http://www.

Re: [DAS] Status of DAS Release

[Amita Vadhavkar]

Things tested to be working -
all UT as part of mvn build
all samples in different browsers.

Apart from das\distribution\binary\pom.xml - change and documentation
changes in JIRA 1335, I have a doubt in logging mechanism in web samples.

In DBConfig utility , the code uses Logger.getLogger(className) - to get
logger from log4j.

Whereas in all RDB DAS code, it is
LoggerFactory.INSTANCE.getLogger(className) - to get logger from RDB DAS
util.
In this, the level is OFF - hardcoded in the code.

So, when the log4j.properties file is used in tomcat to switch on logging,
the logging works for DBConfig (as it is using direct log4j), but logging
does not switch on for RDB DAS classes, as it is hardcoded OFF in the RDB
DAS jar.

Is this the desired behavior? Will there be any need to switch on logging in
web samples for RDB DAS code and how to do it without touching
tuscany-das-rdb-1.0-incubating.jar?

Regards,
Amita

On 6/11/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:


Hi All,

When tried mvn -Pdistribution on das:-
das\distribution\binary\pom.xml - does not list ajax web sample under
dependency and thus does not package same

As now, non-committer does not have access to edit wiki, I have created
JIRA-TUSCANY-1335 for all the pending updates for DAS I was doing. Please
see how these can be completed using attached zipped files.

Architecture Guide -
http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+architecture+guide
images to upload - ClassDiag.jpg, rdbDAS.gif

User Guide -
http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+User+Guide
Under Samples(See Capabilities in use)
Put links for:-
Web Sample -
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/companyweb/readme.htm
J2SE Sample -
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/customer/readme.htm
Advanced Web Sample - 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/sample-ajax-das/readme.htm


Development Guide - DAS_Java_Development_Guide.txt - need to add to wiki

need to checkin under 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/distribution/src/main/release/RELEASE
NOTES
RELEASE_NOTES.txt

About to complete CHANGES.txt , will add by eod to JIRA 1335..

Regards,
Amita

On 6/10/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
>
> I went through all das samples and they seem to be working fine on
> Windows
> XP Home Edition SP 2 environment. I also corrected some links on readmes
> that were pointing to old tuscany website.
>
> I ran the rat on java/das directory and added Apache Licence header to
> files
> that were missing it.
>
> Regards,
> Adriano Crestani
>
> On 6/8/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >
> > First of all, let me thank you all for helping on this release.
> > Recently there has been a lot of progress, and things are looking good
> > from the list of issues we had listed in the wiki [1]. The remaining
> > documentation tasks could probably go in parallel with the release
> > candidates. So, we should start thinking about creating a branch for
> > the next release sometime soon, probably over the weekend or Monday
> > and then start publishing release candidates from that.
> >
> > Also, I think we should look into the following items before we create
> > the first RC :
> >
> >- run rat and make the results available
> >- review the contents of license, readme, release_notes, changes,
> etc
> >- review javadoc
> >- make sure samples readme are updated and correct and the samples
> > are working ok on different environments
> >
> > I'd also like to suggest two other things :
> >- Name the release beta1, to be aligned with the beta1 release of
> SDO.
> >- Any blocking issue to be tracked as blocking JIRA and directly
> > assigned to beta1 release.
> >
> > Does this sound ok to everyone?  Any Thoughts ?
> >
> >
> > [1]
> >
> 
http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+Beta1+Release
> >
> >
> > --
> > 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: Contribute to SCA-OSGi integration

[Graham Charters]

Hi Nicole/Rajini,

I'm wondering if there is some confusion over terminology and the
scenarios being discussed.  I believe Rajini is only referring to OSGi
bundles integrated into SCA through an .  So in
these scenarios both components are SCA components.  Perhaps for
clarity we should refer to the ones implemented using OSGi bundles as
OSGi SCA components.

So, for scenario 1, I think we have:

OSGi SCA Component -- local wire --> non-OSGi SCA Component (e.g. POJO)

In this scenario the OSGi SCA Component implementation will look up
and expect to find a service in the OSGi Registry.  The SCA wiring
states that that service is provided by the non-OSGi SCA Component and
therefore Tuscany must register a proxy service (a proxy to the
non-OSGi SCA Component) in the OSGi Registry.  The OSGi SCA Component
implementation will be unaware that it is calling a non-OSGi SCA
Component.

For scenarios 2, I think we have:

non-OSGi SCA Component (e.g. POJO) -- local wire --> OSGi SCA Component

In this scenario, Tuscany knows that the target component is
implemented by an OSGi bundle and it must look-up the target service
in the OSGi Registry.

Of course, it could easily be me that's confused, but I don't see
where bindings come into these scenarios.  I do think it would be good
to expand the scenarios to include bindings thoughts, and perhaps,
Nicole, you could elaborate on the scenarios you describe.  For
example, I'm not sure the OSGi components you refer to are SCA.  I
think you may be thinking of more a peer-to-peer view of OSGi and SCA.

Regards,

Graham.

On 12/06/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote:

Hi Rajini,

good to hear that you're going to contribute to SCA-OSGi :-)

We wrote a paper about the different possibilities of combining OSGi and
SCA for the SCA drumbeat end of march. You can find it on the OSOA
homepage:
http://www.osoa.org/display/Main/SCA+Resources.
The paper contains a high level description of the OSGi Binding,
implementation type
and OSGi host. Would be great to get some comments from you.

>If there are references from the OSGi component to other non-OSGi SCA
>components, a proxy service is registered by the Tuscany runtime with
the
>OSGi registry so that the OSGi bundles can access these SCA services as
>normal OSGi services.
Well, this is one option, but not the only one. If for example the
non-OSGi SCA component
provides a SOAP service binding, a SOAP proxy will be injected.

>References from non-OSGi components to OSGi components
>are resolved by looking up the OSGi registry.
Yes, if the non-OSGi SCA component has declared a reference with OSGi
binding.
If the OSGi component has declared a JMS service binding, the non-OSGi
SCA component
could use JMS instead of OSGi binding :-)

Best regards
Nicole


> >Hello,
>
> >I would like to contribute to the SCA<->OSGi integration activities.
>
> >I have been looking at the existing OSGi binding implementation in
> Tuscany
> >which exposes SCA services as OSGi services. Even though this binding
> is no
> >longer working with the latest Tuscany builds, the samples were very
> useful
> >to understand the scenarios. I was also looking at the notes  on the
> mailing
> >list  (they are slightly old - dated Nov 2006) which talk about an
> OSGi host
> >and also an OSGi implementation type. Is there any ongoing work in
> these
> >areas?
>
> >Graham Charters and I have been investigating the use of an OSGi
> >implementation type which will enable existing OSGi bundles to be run
> as SCA
> >components under Tuscany.  We are particulary interested in the
> scenario
> >where Tuscany is in control. If components of OSGi implementation
> type are
> >specified in the composite, Tuscany starts up an OSGi runtime and
> deploys
> >the OSGi bundles corresponding to the components into the OSGi
> runtime. If
> >there are references from the OSGi component to other non-OSGi SCA
> >components, a proxy service is registered by the Tuscany runtime with
> the
> >OSGi registry so that the OSGi bundles can access these SCA services
> as
> >normal OSGi services. References from non-OSGi components to OSGi
> components
> >are resolved by looking up the OSGi registry.
>
> >We would like to obtain feedback on using this approach and also
> would like
> >to get involved in the ongoing support for SCA<->OSGi integration.
>
> >Thank you...
>
>
> >Regards,
>
> >Rajini
>



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

Re: [DAS] TUSCANY-866: Default OCC policy

[Amita Vadhavkar]

Please let me know what is there in code base at present/in-progress for OCC
recovery? Will you please elaborate the approach and if there is any item I
can pick up for next release?

Regards,
Amita


On 10/18/06, Brent Daniel <[EMAIL PROTECTED]> wrote:


I've been working on some function to recover from collisions (since
at the moment we have none :) ). One of the recovery mechanisms I'm
planning to put in is a means to "force" the update. Though it would
require an extra step, this should take care of this case.

Brent

On 10/17/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
> I have talked to clients that want their data slammed into the database
> no matter what.  But, this is an edge case.  We can wait for someone to
> ask for it ... or contribute it.
>
> Brent Daniel wrote:
>
> > Kevin,
> >
> >  We can do that, but it will be our fourth different way to specify
> > OCC behavior (default, version column, managed version column, and
> > none.) Is there a good use case for this? It seems like the only time
> > you would want to go without concurrency control is when you have
> > read-only tables, and in that case this behavior would never be
> > reached anyway.
> >
> > Brent
> >
> > On 10/17/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
> >
> >> Brent,
> >> This sounds reasonable but we probably want some mechanism to provide
> >> our previous default policy which is "no collision checking".  Maybe
> >> a piece of config. What do you think?
> >> --
> >> Kevin
> >>
> >>
> >>
> >> [DAS] Use overqualified update by default
> >> -
> >>
> >> Key: TUSCANY-866
> >> URL: http://issues.apache.org/jira/browse/TUSCANY-866
> >> Project: Tuscany
> >>  Issue Type: New Feature
> >>  Components: Java DAS RDB
> >>Reporter: Brent Daniel
> >>
> >>
> >> Currently in the DAS we either use a user-defined version column or
> >> do not use any concurrency control. We have enough information to
> >> build an overqualified update in cases where a version column is not
> >> defined. For example, if a field "name" is changed from "Bob" to
> >> "John", we would generate a query such as:
> >>
> >> UPDATE CUSTOMER SET NAME = 'John' WHERE ID = 1 AND NAME = 'Bob'
> >>
> >> If the statement does not update any rows in the database, the DAS
> >> will throw a concurrency control exception.
> >>
> >> This scheme will not work in case of LONG VARCHAR, BLOB, or CLOB
> >> columns, so an exception should be thrown in that case indicating
> >> that a version column must be defined.
> >>
> >>
> >>
> >> -
> >> 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]
>
>

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

[jira] Created: (TUSCANY-1340) DAS: custom validation support during applyChanges()

[Amita Vadhavkar (JIRA)]

DAS: custom validation support during applyChanges()


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


Here validations can be based on Database provided Meta Data, also,
we can think of defining custom validations per Command basis in DAS
config. With this, invalid (validation failed) Data Graphs can be
deleted from the tree. The dependency management logic will need to handle the 
consequent
actions for this deletion(parent-child etc.)

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


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

Re: SCA Binding and Disitribution was: Distributed Composites

[Simon Laws]

No, it was operator error. For some reason I didn't snip out the bit I was
replying to. Apologies

Simon

[jira] Created: (TUSCANY-1339) DAS:support JDBC batch updates/inserts

[Amita Vadhavkar (JIRA)]

DAS:support JDBC batch updates/inserts
--

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


This can be support for explicit as well as SDO-integrated inserts/updates and 
Stored Procedures

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