Re: Do we want the simpler spi? was: svn commit: r544528 - in /incubator/tuscany/java/sca: modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ samples/helloworld-ws-reference/src/m

[Venkata Krishnan]

Hi,

Though I haven't looked deep into the simplifications I really feel it would
be better to have them as part of the SPIs than as an optional thing outside
it.  As a developer I'd be more inclined to look up the SPIs and go on than
look over the SPIs for additional utils or helpers.  Just as perspective
thats all :)

- Venkat

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


I'm not sure i agree about the sample, wont it be even more confusing
having
it use the old way? Maybe if there was something the sample was doing that
required the complex SPI but while there isn't wont it just seem odd to do
it an unnecessarily complicated way.

Do we even want this simpler SPI? If we do i think we should use it, if we
don't we should scrap it now, which I'm fine with doing. Maybe it would be
better to just move some of the simplifications to the existing SPI?

   ...ant

On 6/5/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Ant,
>
> This commit introduced breaking changes to the helloworld-ws-reference
> and helloworld-ws-service samples, using some kind of .
> Probably an oversight :)
>
> More important, I think we should revert to the official Tuscany SPIs in
> the implementation-crud sample, as it is our main sample to show people
> how to develop extensions using these SPIs.
>
> I'll be happy to have another new sample showing how to use the new
> simplified extension layer, as I think that this new layer will be very
> useful.
>
> This will avoid confusion, and will also allow people to compare and
> choose between the two layers and ways to develop extensions.
>
> Thanks...
>
> [EMAIL PROTECTED] wrote:
> > Author: antelder
> > Date: Tue Jun  5 09:00:23 2007
> > New Revision: 544528
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=544528
> > Log:
> > Change implementation-crud sample to use extension-helper instead of
> core spi (hoping that may prompt some review comments on if the
> extension-helper needs changes)
> >
> > Added:
> >
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDImplementation.java
> >
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDImplementationActivator.java
> (with props)
> >
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDInvoker.java
> (with props)
> >
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/META-INF/services/org.apache.tuscany.sca.spi.ImplementationActivator
> >   - copied, changed from r544134,
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/META-INF/services/org.apache.tuscany.sca.core.ModuleActivator
> > Removed:
> >
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDImplementationFactory.java
> >
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/DefaultCRUDImplementationFactory.java
> >
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/impl/
> >
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/module/
> >
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/provider/
> >
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/META-INF/services/org.apache.tuscany.sca.core.ModuleActivator
> > Modified:
> >
>
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
> >
>
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java
> >
>
incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/java/helloworld/HelloWorldClient.java
> >
>
incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/resources/helloworldwsclient.composite
> >
>
incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite
> > incubator/tuscany/java/sca/samples/implementation-crud/pom.xml
> >
> > Modified:
>
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
> > URL:
>
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java?view=diff&rev=544528&r1=544527&r2=544528
> >
>
==
> > ---
>
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
> (original)
> > +++
>
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
> Tue Jun  5 09:00:23 2007
> > @@ -68,7 +68,7 @@
> >
> >  Class implClass =
> implementationActivator.getImplementationClass();
> >  QName scdlQName = implementationActivator.getSCDLQName();
> > -staxProcessors.addArtifactProcessor(new
> SCDLProcessor(assem

Re: Java SCA 0.90 javadocs

[Luciano Resende]

I have done suggested updates and have committed under revision
r544731. I'll update the wiki tomorrow morning after the javadoc is
available from the live website.

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

Luciano Resende wrote:
> I have generated the javadocs for the SCA 0.9 release, and have
> divided them in two groups :
>
>   - API, this contains the OSOA Apis and the host-embedded
> definitions and is available at [1]
>
>   - SPIs, this contains the javadoc for the spis listed on the
> CHANGES doc [3] as intended to be more stable over future releases,
> and it's available under [2]
>
>
> I'd like people to give it a quick review, and when we are comfortable
> with the contents, I'd like to move this to our website svn and link
> to it from our wiki.
>
> Thoughts ?
>
>
> [1]
> http://people.apache.org/~lresende/tuscany/javadoc/java-sca-0.9/sca-api/
> [2]
> http://people.apache.org/~lresende/tuscany/javadoc/java-sca-0.9/sca-spi/
> [3]
> 
https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-0.90/distribution/src/main/release/CHANGES
>
>

Great, thanks for doing that, it will be useful to have these Javadocs
on our web site.

I have two minor comments:

- It would be nice if we could exclude SCADomainBean and
SCATestCaseRunner from the API as I don't think that they're really
useful to application developers (I think we should remove them at some
point).

- The .impl and .util packages should be excluded from both the API and
SPI javadocs.

Thanks

--
Jean-Sebastien


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





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

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

Re: svn commit: r544658 - in /incubator/tuscany/java/sca/samples: helloworld-ws-reference/src/main/java/helloworld/ helloworld-ws-reference/src/main/resources/ helloworld-ws-service/src/main/resources

[Raymond Feng]

Hi,

Now the sample is failing with the following error. It seems the endpoint 
address is not matching.


Caused by: org.apache.axis2.AxisFault: Transport error: 404 Error: 
/HelloWorldSe

rviceComponent
   at 
org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessa

geWithCommons(CommonsHTTPTransportSender.java:314)
   at 
org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(Com

monsHTTPTransportSender.java:201)
   ... 46 more
Caused by: org.apache.axis2.AxisFault: Transport error: 404 Error: 
/HelloWorldSe

rviceComponent
   at 
org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.jav

a:179)
   at 
org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:73)
   at 
org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessa

geWithCommons(CommonsHTTPTransportSender.java:305)
   ... 47 more
Caused by: org.apache.axis2.AxisFault: Transport error: 404 Error: 
/HelloWorldSe

rviceComponent
   at 
org.apache.axis2.transport.http.HTTPSender.handleResponse(HTTPSender.

java:320)
   at 
org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.jav

a:177)
   ... 49 more

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

To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2007 3:13 PM
Subject: svn commit: r544658 - in /incubator/tuscany/java/sca/samples: 
helloworld-ws-reference/src/main/java/helloworld/ 
helloworld-ws-reference/src/main/resources/ 
helloworld-ws-service/src/main/resources/




Author: antelder
Date: Tue Jun  5 15:13:03 2007
New Revision: 544658

URL: http://svn.apache.org/viewvc?view=rev&rev=544658
Log:
Remove the accidental commit on the binding.console stuff

Modified:

incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/java/helloworld/HelloWorldClient.java

incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/resources/helloworldwsclient.composite

incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite

Modified: 
incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/java/helloworld/HelloWorldClient.java
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/java/helloworld/HelloWorldClient.java?view=diff&rev=544658&r1=544657&r2=544658

==
---  
incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/java/helloworld/HelloWorldClient.java 
(original)
+++ 
incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/java/helloworld/HelloWorldClient.java 
Tue Jun  5 15:13:03 2007

@@ -30,10 +30,8 @@
SCADomain scaDomain = 
SCADomain.newInstance("helloworldwsclient.composite");
HelloWorldService helloWorldService = 
scaDomain.getService(HelloWorldService.class, 
"HelloWorldServiceComponent");


-//String value = helloWorldService.getGreetings("World");
-//System.out.println(value);
-
-Thread.sleep(90);
+String value = helloWorldService.getGreetings("World");
+System.out.println(value);

scaDomain.close();
}

Modified: 
incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/resources/helloworldwsclient.composite
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/resources/helloworldwsclient.composite?view=diff&rev=544658&r1=544657&r2=544658

==
---  
incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/resources/helloworldwsclient.composite 
(original)
+++ 
incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/resources/helloworldwsclient.composite 
Tue Jun  5 15:13:03 2007

@@ -22,18 +22,13 @@
 xmlns:hw="http://helloworld";
 name="helloworldwsclient">

-promote="HelloWorldServiceComponent">

-
-
-
-

  


promote="HelloWorldServiceComponent/helloWorldService">


-
+wsdlElement="http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)"/>





Modified: 
incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite?view=diff&rev=544658&r1=544657&r2=544658

==
---  
incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite 
(original)
+++ 
incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite 
Tue Jun  5 15:13:03 2007

@@ -22,12 +22,11 @@
 xmlns:hw="http://helloworld";
name="helloworldws">

- promote="HelloWorldServiceComponent">

+
+ 
 interface="http://helloworld#wsdl.interface(Hel

Re: Website - Consistent navigation menus

[haleh mahbod]

How about we change the name of the document to 'Tuscany cwiki & Website
Structure'

And remove the paragraphs marked with the pink comments?

http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56590

This document is purely sharing the wiki stucture and explains how to move
cwiki to the website.


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


Hi Ant,

What drove that statement was the re-org that had to done to the content.
If we do not follow some fundamental guidelines its going to be difficult
to
organize or link up the content.  Also there aren't any guidelines there
that are going to be cumbersome to follow - there are just about simple
things like taking care to see that a page aligns with the overall page
tree
structure and that it has a consistent set of menus... For this release
there has been quite a bit of effort that had to be spent just to
reorganize
the contents.

If there is any guideline that you feel could be cumbersome I am open to
making it simple to encourage contributions.

Thanks

- Venkat


On 6/5/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> I don't like this bit:
>
> "Since the Wiki content forms the backbone for the public website
content,
> it is important that the community adheres to some community accepted
> common
> guidelines when authoring content on the Wiki, to help in consistency
and
> maintainability of the content."
>
> If we're worried about what happens on the website we should just
restrict
> access so only committers can update it, then, just as with the code, we
> work CTR.
>
> The website is looking good now, much better than before, but IMHO that
> doesn't mean its perfect or that we should try to restrict or control
any
> future changes to it.
>
>...ant
>
> On 6/5/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I've added more to this guidelines page.  Please take a look and see
if
> it
> > all makes sense.  Thanks.
> >
> > - Venkat
> >
> > On 6/5/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > Website update is done.
> > >
> > > Below is the draft of 'cwiki development guide' that lays out the
tree
> > > structure for cwiki.
> > >
> > >
> >
>
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+cwiki+Development+Guideline
> > > Can we update it with your suggestions and once an agreement is
> reached
> > > make
> > > it the development guide for cwiki.
> > > It was very difficult to organize the content and I am sure it'll
get
> > into
> > > the same shape if we don't all follow some agreed to guidelines.
> > >
> > >
> > > Work remaining:
> > > - Convert the old download pages to the new format. Thanks Venkat
for
> > your
> > > help thus far for moving the content from the old style to the new
> > style.
> > > - There is a lot of in-progress documentation. Are any of these
ready
> to
> > > be
> > > added to the list of documentations for each project?
> > >
> > > Haleh
> > >
> > > On 6/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Haleh, please see my comments inline.
> > > >
> > > > Thanks
> > > >
> > > > - Venkat
> > > >
> > > > On 6/1/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > I don't see a difference and in fact it is  more work.
> > > > >
> > > > > In today's mode: you update one page.
> > > > > a) update Latest release
> > > > > b) move the old release to previous releases.
> > > > > (Note: I think previous releases should be on the same page).
> > > >
> > > >
> > > > For every release I suppose we will have alteast 1 or 1.5 pages of
> > > > information i.e. the release related info and the two tables.  Do
> you
> > > mean
> > > > we move all of this to the 'Previous Release' section.  If we did
> this
> > > by
> > > > the end of this year we will have several pages to scroll down to.
> > > >
> > > > In your proposal: Have a page for each release and then link it
back
> > to
> > > > > latest releases page.
> > > >
> > > >
> > > > Yes.. the pages are short and concise.  There is just about a list
> of
> > > > releases and the user can choose any one and then get to read up
> what
> > > the
> > > > release contains and what is downloadable on a diff. pages.  This
is
> > not
> > > > much overhead - what is more is just a couple of lines.
> > > >
> > > > Are we making this too complicated? My preference would be to
> convert
> > > the
> > > > > table we currently have into something readable
> > > > > that has a link to readme for the release on the same page. I'll
> add
> > a
> > > > > sample to the page so we can take a look.
> > > > >
> > > > > On 6/1/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi Haleh,
> > > > > >
> > > > > > I am trying to re-org the downloads / release page for the
> > following
> > > > > > reason
> > > > > > :--
> > > > > >
> > > > > > Currently the SCA Release pages points to two things i) Latest
> > > Release
> > > > > ii)
> > > > > > Previous Releases.  In the Latest Release section

Re: problem in Input2InputTransformer: if (sourceWrapped && (!targetWrapped))

[Raymond Feng]

Hi, Scott.

Thank you for finding the problem. I'll fix it.

Raymond

- Original Message - 
From: "Scott Kurz" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, June 05, 2007 4:09 PM
Subject: problem in Input2InputTransformer: if (sourceWrapped && 
(!targetWrapped))




In testing some of the issues mentioned in this thread:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18236.html
on some newer code I noticed what seems to be a problem in
Input2InputTransformer


It seems like the targetWrapperHandler can't get set in the case we go 
down

this path:

 if (sourceWrapped && (!targetWrapped))


Instead of doing:
 targetWrapperHandler = getWrapperHandler(targetDataBinding, false);
we should do this:
 targetWrapperHandler = getWrapperHandler(getDataBinding(targetOp);,
false);
since above we only set 'targetDataBinding' if 'targetWrapped' was true:
  if (targetWrapped) {
   targetDataBinding = getDataBinding(targetOp);
   targetWrapperHandler = getWrapperHandler(targetDataBinding,
true);
   }


Or something equivalent should be done...

This seems too small for a JIRA so I won't open one.

Raymond, do you agree?

Scott




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

problem in Input2InputTransformer: if (sourceWrapped && (!targetWrapped))

[Scott Kurz]

In testing some of the issues mentioned in this thread:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18236.html
on some newer code I noticed what seems to be a problem in
Input2InputTransformer


It seems like the targetWrapperHandler can't get set in the case we go down
this path:

 if (sourceWrapped && (!targetWrapped))


Instead of doing:
 targetWrapperHandler = getWrapperHandler(targetDataBinding, false);
we should do this:
 targetWrapperHandler = getWrapperHandler(getDataBinding(targetOp);,
false);
since above we only set 'targetDataBinding' if 'targetWrapped' was true:
  if (targetWrapped) {
   targetDataBinding = getDataBinding(targetOp);
   targetWrapperHandler = getWrapperHandler(targetDataBinding,
true);
   }


Or something equivalent should be done...

This seems too small for a JIRA so I won't open one.

Raymond, do you agree?

Scott

[jira] Commented: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?

[Scott Kurz (JIRA)]

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

Scott Kurz commented on TUSCANY-824:


This is a link to the ML discussion Raymond mentioned:

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


> DataBinding: Is it a concern of Programming Model vs. Assembly?
> ---
>
> Key: TUSCANY-824
> URL: https://issues.apache.org/jira/browse/TUSCANY-824
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-M2
>Reporter: ant elder
>Assignee: Raymond Feng
>Priority: Critical
> Fix For: Java-SCA-Next
>
>
> There have been some question about the DataBinding framework and if it 
> should be a concern of the Programming Model vs. Assembly?
> See: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08679.html
> and a follow up mention in: 
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09363.html

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


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

[jira] Updated: (TUSCANY-1325) Property value with xsd:QName type is not deserialized and serialized correctly

[Fuhwei Lwo (JIRA)]

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

Fuhwei Lwo updated TUSCANY-1325:


Attachment: 1325.patch

In my patch, I need to override createFromString and convertToString because I 
cannot find prefix and namespace mapping information from EMF's 
XMLTypeFactory.eINSTANCE.

Please review my proposed changes. Thanks.

> Property value with xsd:QName type is not deserialized and serialized 
> correctly
> ---
>
> Key: TUSCANY-1325
> URL: https://issues.apache.org/jira/browse/TUSCANY-1325
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M2
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Attachments: 1325.patch, XSDQNameTestCase.java, XSDQNameTestCase.java
>
>
> Current SDO implementation doesn't convert property value with xsd:QName type 
> at all. The value is treated as a plain string without any conversion. The 
> conversion should take place based on SDO 2.1 spec section 9.4.1.

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

Do we want the simpler spi? was: svn commit: r544528 - in /incubator/tuscany/java/sca: modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ samples/helloworld-ws-reference/src/main/

[ant elder]

I'm not sure i agree about the sample, wont it be even more confusing having
it use the old way? Maybe if there was something the sample was doing that
required the complex SPI but while there isn't wont it just seem odd to do
it an unnecessarily complicated way.

Do we even want this simpler SPI? If we do i think we should use it, if we
don't we should scrap it now, which I'm fine with doing. Maybe it would be
better to just move some of the simplifications to the existing SPI?

  ...ant

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


Ant,

This commit introduced breaking changes to the helloworld-ws-reference
and helloworld-ws-service samples, using some kind of .
Probably an oversight :)

More important, I think we should revert to the official Tuscany SPIs in
the implementation-crud sample, as it is our main sample to show people
how to develop extensions using these SPIs.

I'll be happy to have another new sample showing how to use the new
simplified extension layer, as I think that this new layer will be very
useful.

This will avoid confusion, and will also allow people to compare and
choose between the two layers and ways to develop extensions.

Thanks...

[EMAIL PROTECTED] wrote:
> Author: antelder
> Date: Tue Jun  5 09:00:23 2007
> New Revision: 544528
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=544528
> Log:
> Change implementation-crud sample to use extension-helper instead of
core spi (hoping that may prompt some review comments on if the
extension-helper needs changes)
>
> Added:
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDImplementation.java
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDImplementationActivator.java
(with props)
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDInvoker.java
(with props)
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/META-INF/services/org.apache.tuscany.sca.spi.ImplementationActivator
>   - copied, changed from r544134,
incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/META-INF/services/org.apache.tuscany.sca.core.ModuleActivator
> Removed:
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDImplementationFactory.java
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/DefaultCRUDImplementationFactory.java
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/impl/
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/module/
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/provider/
>
incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/META-INF/services/org.apache.tuscany.sca.core.ModuleActivator
> Modified:
>
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
>
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java
>
incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/java/helloworld/HelloWorldClient.java
>
incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/resources/helloworldwsclient.composite
>
incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite
> incubator/tuscany/java/sca/samples/implementation-crud/pom.xml
>
> Modified:
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
> URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java?view=diff&rev=544528&r1=544527&r2=544528
>
==
> ---
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
(original)
> +++
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
Tue Jun  5 09:00:23 2007
> @@ -68,7 +68,7 @@
>
>  Class implClass =
implementationActivator.getImplementationClass();
>  QName scdlQName = implementationActivator.getSCDLQName();
> -staxProcessors.addArtifactProcessor(new
SCDLProcessor(assemblyFactory, scdlQName, implClass));
> +staxProcessors.addArtifactProcessor(new
SCDLProcessor(assemblyFactory, scdlQName, implClass, registry, factories));
>
>  if (implementationActivator.getImplementationClass() !=
null && providerFactories != null) {
>  addImplementationProvider(implementationActivator,
providerFactories);
>
> Modified:
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java
> URL:
http://svn.apache.org/viewvc/incubator/tuscany/j

[jira] Updated: (TUSCANY-1325) Property value with xsd:QName type is not deserialized and serialized correctly

[Fuhwei Lwo (JIRA)]

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

Fuhwei Lwo updated TUSCANY-1325:


Attachment: XSDQNameTestCase.java

Added Apache Java license header to the test case file.

> Property value with xsd:QName type is not deserialized and serialized 
> correctly
> ---
>
> Key: TUSCANY-1325
> URL: https://issues.apache.org/jira/browse/TUSCANY-1325
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M2
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Attachments: XSDQNameTestCase.java, XSDQNameTestCase.java
>
>
> Current SDO implementation doesn't convert property value with xsd:QName type 
> at all. The value is treated as a plain string without any conversion. The 
> conversion should take place based on SDO 2.1 spec section 9.4.1.

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


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

[jira] Updated: (TUSCANY-1325) Property value with xsd:QName type is not deserialized and serialized correctly

[Fuhwei Lwo (JIRA)]

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

Fuhwei Lwo updated TUSCANY-1325:


Attachment: XSDQNameTestCase.java

Attached a test case file - XSDQNameTestCase.java

> Property value with xsd:QName type is not deserialized and serialized 
> correctly
> ---
>
> Key: TUSCANY-1325
> URL: https://issues.apache.org/jira/browse/TUSCANY-1325
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M2
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Attachments: XSDQNameTestCase.java
>
>
> Current SDO implementation doesn't convert property value with xsd:QName type 
> at all. The value is treated as a plain string without any conversion. The 
> conversion should take place based on SDO 2.1 spec section 9.4.1.

-- 
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: Automated nightly builds

[Luciano Resende]

Wouldn't that fail if you start from a clean repo ? It expects the
other modules to be built or available as deployed snapshots no ?

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

[snip]
Luciano Resende wrote:
>> I'm looking for a distribution that I could use directly, as the
>> individual JARs are not so useful. Is there a way to get the
>> distribution built as part of the automated build?
>
> For DAS, I have a "distribution" profile that generate javadoc,
> distributions, etc
> Maybe we could do same for SCA (and SDO) , and I could use this
> profile on the automated builds.
>
> Thougths ?
>

or maybe even simpler than a profile, is it possible to just add the
distribution Maven module to the confluence build config?

--
Jean-Sebastien


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





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

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

Re: [IP CLEARANCE] An external contribution to Apache Tuscany

[robert burrell donkin]

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

I'm following up on this thread which has gone very quiet.  AFAIK
there has not yet been an acknowledgement of the software grant form
by an officer of the ASF.  Can anyone who is an officer of the ASF
help with this, please?


i'm not an officer but any member or officer (for example, your
mentors) can check this by examining the cclas.txt in subversion. i've
taken a look and it's in the file. hope this is good enough for you.

sorry about the delay

- robert

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

Re: Automated nightly builds

[Jean-Sebastien Delfino]

[snip]
Luciano Resende wrote:

I'm looking for a distribution that I could use directly, as the
individual JARs are not so useful. Is there a way to get the
distribution built as part of the automated build?


For DAS, I have a "distribution" profile that generate javadoc,
distributions, etc
Maybe we could do same for SCA (and SDO) , and I could use this
profile on the automated builds.

Thougths ?



or maybe even simpler than a profile, is it possible to just add the 
distribution Maven module to the confluence build config?


--
Jean-Sebastien


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

Build break, was: svn commit: r544528 - in /incubator/tuscany/java/sca: modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ samples/helloworld-ws-reference/src/main/java/helloworld

[Jean-Sebastien Delfino]

Ant,

This commit introduced breaking changes to the helloworld-ws-reference 
and helloworld-ws-service samples, using some kind of . 
Probably an oversight :)


More important, I think we should revert to the official Tuscany SPIs in 
the implementation-crud sample, as it is our main sample to show people 
how to develop extensions using these SPIs.


I'll be happy to have another new sample showing how to use the new 
simplified extension layer, as I think that this new layer will be very 
useful.


This will avoid confusion, and will also allow people to compare and 
choose between the two layers and ways to develop extensions.


Thanks...

[EMAIL PROTECTED] wrote:

Author: antelder
Date: Tue Jun  5 09:00:23 2007
New Revision: 544528

URL: http://svn.apache.org/viewvc?view=rev&rev=544528
Log:
Change implementation-crud sample to use extension-helper instead of core spi 
(hoping that may prompt some review comments on if the extension-helper needs 
changes)

Added:

incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDImplementation.java

incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDImplementationActivator.java
   (with props)

incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDInvoker.java
   (with props)

incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/META-INF/services/org.apache.tuscany.sca.spi.ImplementationActivator
  - copied, changed from r544134, 
incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/META-INF/services/org.apache.tuscany.sca.core.ModuleActivator
Removed:

incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/CRUDImplementationFactory.java

incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/DefaultCRUDImplementationFactory.java

incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/impl/

incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/module/

incubator/tuscany/java/sca/samples/implementation-crud/src/main/java/crud/provider/

incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/META-INF/services/org.apache.tuscany.sca.core.ModuleActivator
Modified:

incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java

incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java

incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/java/helloworld/HelloWorldClient.java

incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/resources/helloworldwsclient.composite

incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite
incubator/tuscany/java/sca/samples/implementation-crud/pom.xml

Modified: 
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java?view=diff&rev=544528&r1=544527&r2=544528
==
--- 
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
 (original)
+++ 
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ImplementationsActivator.java
 Tue Jun  5 09:00:23 2007
@@ -68,7 +68,7 @@
 
 Class implClass = implementationActivator.getImplementationClass();

 QName scdlQName = implementationActivator.getSCDLQName();
-staxProcessors.addArtifactProcessor(new 
SCDLProcessor(assemblyFactory, scdlQName, implClass));
+staxProcessors.addArtifactProcessor(new 
SCDLProcessor(assemblyFactory, scdlQName, implClass, registry, factories));
 
 if (implementationActivator.getImplementationClass() != null && providerFactories != null) {

 addImplementationProvider(implementationActivator, 
providerFactories);

Modified: 
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java?view=diff&rev=544528&r1=544527&r2=544528
==
--- 
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java
 (original)
+++ 
incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java
 Tue Jun  5 09:00:23 2007
@@ -21,10 +21,13 @@
 
 import sta

Re: [LDAP DAS] Quick Update

[Luciano Resende]

Great news Ole, I'm looking forward to see the demo working !

On 6/5/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:

Hey Guys,

I'm a few days away from showing a demo that reads and writes DataGraph instances.  I started 
getting my "Groove On" so I've just been doing "Go" coding, and will finish the 
design guide after, although I did add a lot more content to in order to to provide visibility wrt 
end game.

Cheers,
- Ole





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





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

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

Re: Website - Consistent navigation menus

[Venkata Krishnan]

Hi Ant,

What drove that statement was the re-org that had to done to the content.
If we do not follow some fundamental guidelines its going to be difficult to
organize or link up the content.  Also there aren't any guidelines there
that are going to be cumbersome to follow - there are just about simple
things like taking care to see that a page aligns with the overall page tree
structure and that it has a consistent set of menus... For this release
there has been quite a bit of effort that had to be spent just to reorganize
the contents.

If there is any guideline that you feel could be cumbersome I am open to
making it simple to encourage contributions.

Thanks

- Venkat


On 6/5/07, ant elder <[EMAIL PROTECTED]> wrote:


I don't like this bit:

"Since the Wiki content forms the backbone for the public website content,
it is important that the community adheres to some community accepted
common
guidelines when authoring content on the Wiki, to help in consistency and
maintainability of the content."

If we're worried about what happens on the website we should just restrict
access so only committers can update it, then, just as with the code, we
work CTR.

The website is looking good now, much better than before, but IMHO that
doesn't mean its perfect or that we should try to restrict or control any
future changes to it.

   ...ant

On 6/5/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've added more to this guidelines page.  Please take a look and see if
it
> all makes sense.  Thanks.
>
> - Venkat
>
> On 6/5/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Website update is done.
> >
> > Below is the draft of 'cwiki development guide' that lays out the tree
> > structure for cwiki.
> >
> >
>
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+cwiki+Development+Guideline
> > Can we update it with your suggestions and once an agreement is
reached
> > make
> > it the development guide for cwiki.
> > It was very difficult to organize the content and I am sure it'll get
> into
> > the same shape if we don't all follow some agreed to guidelines.
> >
> >
> > Work remaining:
> > - Convert the old download pages to the new format. Thanks Venkat for
> your
> > help thus far for moving the content from the old style to the new
> style.
> > - There is a lot of in-progress documentation. Are any of these ready
to
> > be
> > added to the list of documentations for each project?
> >
> > Haleh
> >
> > On 6/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Haleh, please see my comments inline.
> > >
> > > Thanks
> > >
> > > - Venkat
> > >
> > > On 6/1/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I don't see a difference and in fact it is  more work.
> > > >
> > > > In today's mode: you update one page.
> > > > a) update Latest release
> > > > b) move the old release to previous releases.
> > > > (Note: I think previous releases should be on the same page).
> > >
> > >
> > > For every release I suppose we will have alteast 1 or 1.5 pages of
> > > information i.e. the release related info and the two tables.  Do
you
> > mean
> > > we move all of this to the 'Previous Release' section.  If we did
this
> > by
> > > the end of this year we will have several pages to scroll down to.
> > >
> > > In your proposal: Have a page for each release and then link it back
> to
> > > > latest releases page.
> > >
> > >
> > > Yes.. the pages are short and concise.  There is just about a list
of
> > > releases and the user can choose any one and then get to read up
what
> > the
> > > release contains and what is downloadable on a diff. pages.  This is
> not
> > > much overhead - what is more is just a couple of lines.
> > >
> > > Are we making this too complicated? My preference would be to
convert
> > the
> > > > table we currently have into something readable
> > > > that has a link to readme for the release on the same page. I'll
add
> a
> > > > sample to the page so we can take a look.
> > > >
> > > > On 6/1/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi Haleh,
> > > > >
> > > > > I am trying to re-org the downloads / release page for the
> following
> > > > > reason
> > > > > :--
> > > > >
> > > > > Currently the SCA Release pages points to two things i) Latest
> > Release
> > > > ii)
> > > > > Previous Releases.  In the Latest Release section we have
> hardcoded
> > > the
> > > > > content for the 0.90 release.  This is something we will have to
> > > revisit
> > > > > every time we make a release and then the content there has to
be
> > > moved
> > > > > over
> > > > > as well.  i.e. for 0.91 we will have to edit this page and then
> move
> > > the
> > > > > contents of 0.90 else where.  To help this to be a bit smooth, I
> > > suggest
> > > > > that for every release we create a separate page i.e. a page for
> > 0.90,
> > > a
> > > > > page for 0.91 and so on.  Then in the SCA Releases page we
simply
> > > > > 'inlcude'
> > > > > the relevan

[jira] Updated: (TUSCANY-1318) can not get include Composite's services, components...

[Jean-Sebastien Delfino (JIRA)]

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

Jean-Sebastien Delfino updated TUSCANY-1318:


Fix Version/s: (was: Java-SCA-0.90)
   Java-SCA-Next

> can not get include Composite's services, components...
> ---
>
> Key: TUSCANY-1318
> URL: https://issues.apache.org/jira/browse/TUSCANY-1318
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-0.90
> Environment: Windows XP
>Reporter: Yang Lei
> Fix For: Java-SCA-Next
>
>
> Add two lines to ReadAllTestCase.testReadComposite()
> Composite include = composite.getIncludes().get(0);
> assertEquals(include.getName(), new QName("http://calc";, 
> "TestAllDivide"));
> // the following is the added lines
> assertEquals(1,include.getComponents().size());
> assertEquals(1,include.getServices().size(), 1);
> And got 0 components and 0 services.
> Tried to get other attribute on the include as PolicySet and Intents, are are 
> also empty. 

-- 
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: Reactivating the extension, ready to go with the latest commits to sandbox

[Jean-Sebastien Delfino]

ant elder wrote:

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


Hi,

It seems that it breaks the build as the following dependency cannot be
resolved:


org.osoa
sca-api
1.0-incubating-SNAPSHOT


I'll fix it to use "org.apache.tuscany.sca" as the group id.

A side question, should the group id for sca-api be org.osoa or
org.apache.tuscany.sca?



It didn't seem right to me for the org.apache.tuscany project to be
publishing things outside of that namespace. Its worked in the past as we
publish to the Incubator maven repository but would we even be able to
publish outside of org.apache when its going to the real maven 
repository?


  ...ant



Sorry, my fault... it was building for me as I had an old 
org.osoa/sca-api artifact in my Maven repository from before the change 
to org.apache.tuscany.sca.


+1 for using org.apache.tuscany.sca, as this is what we use in all 
modules now.


--
Jean-Sebastien


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

Re: Servlet path change?

[Jean-Sebastien Delfino]

ant elder wrote:

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


Am just playing with the big bank demo that Sebastien made and it seems
now
that the servlets have moved from

services/AccountJSONService

to

services/SCADomain/AccountJSONService

Looking back through SVN changes and the ML I can't see where this
happened
but I know that this just means I'm looking in the wrong place. Is this
change permanent. If so I'll check in fixes to the client.



That was TUSCANY-1269 and r543083, also see
http://incubator.apache.org/tuscany/sca-java-bindingjsonrpc.html 
although i

guess that could be updated to mention what the actual endpoint URI is.

The "services/' part is coming from the servlet definition in the 
web.xml.

The "SCADomain/" part is fixed right now, the "AccountJSONService" is the
name of the binding.

TUSCANY-1269 brought the binding.ajax and binding.jsonrpc together so 
they
work the same way and which binding is used can be transparent to 
clients,

but I don't think this is the permanent final solution yet. We probably
should try to make all binding endpoints work as much as possible in a
standard way as described in section 1.7.2 of the Assembly spec.

  ...ant



+1, we should compute the service URI as described in section 1.7.2 of 
the assembly spec. I created 
http://issues.apache.org/jira/browse/TUSCANY-1326 to report this.


--
Jean-Sebastien


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

[jira] Created: (TUSCANY-1326) Jsonrpc and Ajax bindings should use endpoints as defined in the assembly spec 1.7.2

[Jean-Sebastien Delfino (JIRA)]

Jsonrpc and Ajax bindings should use endpoints as defined in the assembly spec 
1.7.2


 Key: TUSCANY-1326
 URL: https://issues.apache.org/jira/browse/TUSCANY-1326
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JSON-RPC Binding Extension
Reporter: Jean-Sebastien Delfino
 Fix For: Java-SCA-Next


The jsonrpc and Ajax bindings currently hardcode the endpoint uri of the 
services they provide.

Instead they should use the algorithm described in the SCA assembly spec 
section 1.7.2

-- 
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: Reactivating the extension, ready to go with the latest commits to sandbox

[ant elder]

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


Hi,

It seems that it breaks the build as the following dependency cannot be
resolved:


org.osoa
sca-api
1.0-incubating-SNAPSHOT


I'll fix it to use "org.apache.tuscany.sca" as the group id.

A side question, should the group id for sca-api be org.osoa or
org.apache.tuscany.sca?



It didn't seem right to me for the org.apache.tuscany project to be
publishing things outside of that namespace. Its worked in the past as we
publish to the Incubator maven repository but would we even be able to
publish outside of org.apache when its going to the real maven repository?

  ...ant

[jira] Commented: (TUSCANY-1325) Property value with xsd:QName type is not deserialized and serialized correctly

[Fuhwei Lwo (JIRA)]

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

Fuhwei Lwo commented on TUSCANY-1325:
-

Here is related information from the Tuscany dev-list.

Handling this in the same way as we handled base64Binary sounds right 
to 
me. We didn't override createFromString and convertToString, however. 
We 
simply mapped internally to the EMF base64Binary type and let EMF 
handle 
it in its default way. 

Note that the code to make this work is in AttributeImpl.getType() and 
in 
SDOXSDEcoreBuilder.getBuiltInEClassifier().

Thanks,
Frank.

Fuhwei Lwo <[EMAIL PROTECTED]> wrote on 06/04/2007 04:23:15 PM:

> I believe we have a bug in loading/saviing xsd:QName property value.
> Based on SDO 2.1 spec section 9.4.1, proper conversion should take 
> place. Unfortunately, Tuscany SDO is not doing any conversion today.
> If no one objects, I will open a JIRA.
> 
> When I started to look into possible solution for this problem, I 
> discovered both xsd:anyURI and xsd:QName are mapped to SDO URI type.
> This is similar to JIRA 1223 Frank has fixed for xsd:base64Binary 
> and xsd:hexBinary. I think we can copy what 1223 has done by 
> internally mapping xsd:QName to SDO QName type then in the 
> SDOXMLResourceImpl$SDOXMLHelperImpl, override createFromString and 
> convertToString for deserialization and serialization respectively.
> 
> Let me know if this proposed solution makes sense.
> 
> Fuhwei

> Property value with xsd:QName type is not deserialized and serialized 
> correctly
> ---
>
> Key: TUSCANY-1325
> URL: https://issues.apache.org/jira/browse/TUSCANY-1325
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M2
> Environment: WinXP
>Reporter: Fuhwei Lwo
>
> Current SDO implementation doesn't convert property value with xsd:QName type 
> at all. The value is treated as a plain string without any conversion. The 
> conversion should take place based on SDO 2.1 spec section 9.4.1.

-- 
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-1325) Property value with xsd:QName type is not deserialized and serialized correctly

[Fuhwei Lwo (JIRA)]

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

Fuhwei Lwo commented on TUSCANY-1325:
-

I am currently working on the solution and will upload for review when I am 
ready.

> Property value with xsd:QName type is not deserialized and serialized 
> correctly
> ---
>
> Key: TUSCANY-1325
> URL: https://issues.apache.org/jira/browse/TUSCANY-1325
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M2
> Environment: WinXP
>Reporter: Fuhwei Lwo
>
> Current SDO implementation doesn't convert property value with xsd:QName type 
> at all. The value is treated as a plain string without any conversion. The 
> conversion should take place based on SDO 2.1 spec section 9.4.1.

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


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

[jira] Created: (TUSCANY-1325) Property value with xsd:QName type is not deserialized and serialized correctly

[Fuhwei Lwo (JIRA)]

Property value with xsd:QName type is not deserialized and serialized correctly
---

 Key: TUSCANY-1325
 URL: https://issues.apache.org/jira/browse/TUSCANY-1325
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M2
 Environment: WinXP
Reporter: Fuhwei Lwo


Current SDO implementation doesn't convert property value with xsd:QName type 
at all. The value is treated as a plain string without any conversion. The 
conversion should take place based on SDO 2.1 spec section 9.4.1.

-- 
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: Reactivating the extension, ready to go with the latest commits to sandbox

[Raymond Feng]

Hi,

It seems that it breaks the build as the following dependency cannot be 
resolved:



org.osoa
sca-api
1.0-incubating-SNAPSHOT


I'll fix it to use "org.apache.tuscany.sca" as the group id.

A side question, should the group id for sca-api be org.osoa or 
org.apache.tuscany.sca?


Thanks,
Raymond

- Original Message - 
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, June 05, 2007 9:48 AM
Subject: Re: Reactivating the  extension, ready to go 
with the latest commits to sandbox




Jean-Sebastien Delfino wrote:

Mike Edwards wrote:

Jean-Sebastien,

OK, with the latest commit to the sandbox, there is a working version of 
the Spring implementation.  It has the fixes you need, plus a set of 
other changes which have got the basic version working.


I'll hold off on further updates until it's in trunk.

The next step is to get References working from the Spring 
implementation to some external SCA components.



Yours,  Mike.

Jean-Sebastien Delfino wrote:
I reviewed the update of the Spring extension that Mike has put in the 
sandbox and it looks like a good step to get the Spring extension going 
again.


I just had to adjust a few lines to use the 0.90  release SPIs to get 
it building with the level of code in trunk. I'll commit these fixes 
later today.


Then I'd like to replace the old modules/spring-implementation in trunk 
(which is broken) by this update. If there's no objection I'll do that 
sometime tomorrow.





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




Great, Thanks!

I'll work on integrating it with the main build in trunk, and will post 
here once it's ready.




The Spring framework implementation extension is now integrated in the 
main build.


I also did some minor cleanup, removed some old .scdl files and adjusted 
the disclaimer, license and notice.


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

Re: Reactivating the extension, ready to go with the latest commits to sandbox

[Jean-Sebastien Delfino]

Jean-Sebastien Delfino wrote:

Mike Edwards wrote:

Jean-Sebastien,

OK, with the latest commit to the sandbox, there is a working version 
of the Spring implementation.  It has the fixes you need, plus a set 
of other changes which have got the basic version working.


I'll hold off on further updates until it's in trunk.

The next step is to get References working from the Spring 
implementation to some external SCA components.



Yours,  Mike.

Jean-Sebastien Delfino wrote:
I reviewed the update of the Spring extension that Mike has put in 
the sandbox and it looks like a good step to get the Spring 
extension going again.


I just had to adjust a few lines to use the 0.90  release SPIs to 
get it building with the level of code in trunk. I'll commit these 
fixes later today.


Then I'd like to replace the old modules/spring-implementation in 
trunk (which is broken) by this update. If there's no objection I'll 
do that sometime tomorrow.





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




Great, Thanks!

I'll work on integrating it with the main build in trunk, and will 
post here once it's ready.




The Spring framework implementation extension is now integrated in the 
main build.


I also did some minor cleanup, removed some old .scdl files and adjusted 
the disclaimer, license and notice.


--
Jean-Sebastien


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

[LDAP DAS] Quick Update

[Ole Ersoy]

Hey Guys,

I'm a few days away from showing a demo that reads and writes DataGraph instances.  I started 
getting my "Groove On" so I've just been doing "Go" coding, and will finish the 
design guide after, although I did add a lot more content to in order to to provide visibility wrt 
end game.

Cheers,
- Ole





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

Re: using service name to call a service

[Mike Edwards]

Muhwas,

I dont understand what you are saying here.

Surely, the actual service has a specific interface - it isn't simply 
"anything", so you can only cast to the actual business interface it 
actually implements.


Or did you envisage your client code introspecting the returned service 
proxy and dealing with whatever it found?  The latter case is possible 
but it is not a pattern I would encourage people to use - the code is 
likely to get very complex.  I can see a possible use for it in writing 
test clients, where the parameters are actually presented in a GUI for a 
user to fill dynamically.  However, this is not typical of real business 
code.



Yours,  Mike.

muhwas wrote:

by the way i used this

CompositeContext compositeContext =
CurrentCompositeContext.getContext();
// get service reference using service component name
in client side default.scdl
return
compositeContext.locateService(java.lang.Object.class,serviceName);

and then i casted it to what ever interface type i
want to. so i think passing in interface doesn't
nessasary.

--- scabooz <[EMAIL PROTECTED]> wrote:



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

[jira] Updated: (TUSCANY-1324) DeserializationNoSchemaTestCase took a long time to run

[Fuhwei Lwo (JIRA)]

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

Fuhwei Lwo updated TUSCANY-1324:


Attachment: 1324.patch

Here is the patch to remove http:// in the target namespace

> DeserializationNoSchemaTestCase took a long time to run
> ---
>
> Key: TUSCANY-1324
> URL: https://issues.apache.org/jira/browse/TUSCANY-1324
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M2
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Attachments: 1324.patch
>
>
> DeserializationNoSchemaTestCase tried to load an XML without registering its 
> XSD. The target namespace in the XML is http://www.example.com/simple. Since 
> this target namespace has not been defined, SDO/EMF will try to resolve 
> http://www.example.com/simple which will try to connect to the Internet.
> In the past, I have tried to provide a solution to disable resolving remote 
> XSD but it seems other people are using the remote feature. To solve this 
> test case problem, my suggestion is to remove http:// from the namespace. I 
> will upload a patch soon.

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


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

[jira] Created: (TUSCANY-1324) DeserializationNoSchemaTestCase took a long time to run

[Fuhwei Lwo (JIRA)]

DeserializationNoSchemaTestCase took a long time to run
---

 Key: TUSCANY-1324
 URL: https://issues.apache.org/jira/browse/TUSCANY-1324
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M2
 Environment: WinXP
Reporter: Fuhwei Lwo


DeserializationNoSchemaTestCase tried to load an XML without registering its 
XSD. The target namespace in the XML is http://www.example.com/simple. Since 
this target namespace has not been defined, SDO/EMF will try to resolve 
http://www.example.com/simple which will try to connect to the Internet.

In the past, I have tried to provide a solution to disable resolving remote XSD 
but it seems other people are using the remote feature. To solve this test case 
problem, my suggestion is to remove http:// from the namespace. I will upload a 
patch soon.

-- 
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: CTS suite SDO version 1.0-incubator-SNAPSHOT or 1.0-incubating-SNAPSHOT?

[kelvin goodson]

Just found time to persist with the "0 tests executed". Problem solved as
per http://issues.apache.org/jira/browse/TUSCANY-1249
Kelvin.

On 23/05/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


Ant,
  I changed the dependency versions,  and I added incubating to the
version tags of the CTS artifacts.  I still suffer from the issue that I
get 0 tests run in my maven environment,  but I get 100% success when
running the tests in eclipse.  Can you please update and rerun in mavenand let 
me know if that fixes your failing test.

Kelvin.

On 23/05/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> The CTS code pom.xml's currently use SDO version 1.0-incubator-SNAPSHOTbut
> that should be 1.0-incubating-SNAPSHOT now shouldn't it?
>
> Using the 1.0-incubating-SNAPSHOT SDO version and running CTS I get:
>
> Running test.sdo21.vendor.tuscany.tests.AdoptedCtsTestSuite
> CTS_TEST_HELPER was not set - attempting Tuscany implementation : null
> Loaded test.sdo21.vendor.tuscany.testHelper.TuscanyTestHelper
> Tests run: 486, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 3.891sec
> <<< FAILURE!
>
> Is this expected? Could I comment out the failing test with a FIXME
> comment
> so the CTS build runs clean?
>
>...ant
>

[jira] Resolved: (TUSCANY-1249) SDO CTS executes 0 tests when run in mvn

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson resolved TUSCANY-1249.
-

Resolution: Invalid

This symptom disappeared after I made 3 changes,  not sure which one(s) did the 
trick,  but I
upgraded to maven 2.0.6
removed my junit folder from my local maven repository
removed my org/apache/maven/plugins/maven-surefire-plugin from my local repo

> SDO CTS executes 0 tests when run in mvn
> 
>
> Key: TUSCANY-1249
> URL: https://issues.apache.org/jira/browse/TUSCANY-1249
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-SDO-CTS-Next
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-CTS-Next
>
>
> Some users report on the tuscany-dev mailing list that 0 tests execute when 
> running the CTS using maven as described in the instructions.

-- 
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: Reactivating the extension, ready to go with the latest commits to sandbox

[Jean-Sebastien Delfino]

Mike Edwards wrote:

Jean-Sebastien,

OK, with the latest commit to the sandbox, there is a working version 
of the Spring implementation.  It has the fixes you need, plus a set 
of other changes which have got the basic version working.


I'll hold off on further updates until it's in trunk.

The next step is to get References working from the Spring 
implementation to some external SCA components.



Yours,  Mike.

Jean-Sebastien Delfino wrote:
I reviewed the update of the Spring extension that Mike has put in 
the sandbox and it looks like a good step to get the Spring extension 
going again.


I just had to adjust a few lines to use the 0.90  release SPIs to get 
it building with the level of code in trunk. I'll commit these fixes 
later today.


Then I'd like to replace the old modules/spring-implementation in 
trunk (which is broken) by this update. If there's no objection I'll 
do that sometime tomorrow.





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




Great, Thanks!

I'll work on integrating it with the main build in trunk, and will post 
here once it's ready.


--
Jean-Sebastien


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

Re: Website - Consistent navigation menus

[Hernan Cunico]

You will have to restrict edit to just committers if you want to make this Confluence 
space your "official" web site.
I strongly recommend you folks discuss this with Infra@ as you will also need 
Confluence admin auth to control your own user groups.

Cheers!
Hernan
ant elder wrote:

I don't like this bit:

"Since the Wiki content forms the backbone for the public website content,
it is important that the community adheres to some community accepted 
common

guidelines when authoring content on the Wiki, to help in consistency and
maintainability of the content."

If we're worried about what happens on the website we should just restrict
access so only committers can update it, then, just as with the code, we
work CTR.

The website is looking good now, much better than before, but IMHO that
doesn't mean its perfect or that we should try to restrict or control any
future changes to it.

  ...ant

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


Hi,

I've added more to this guidelines page.  Please take a look and see 
if it

all makes sense.  Thanks.

- Venkat

On 6/5/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Website update is done.
>
> Below is the draft of 'cwiki development guide' that lays out the tree
> structure for cwiki.
>
>
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+cwiki+Development+Guideline 


> Can we update it with your suggestions and once an agreement is reached
> make
> it the development guide for cwiki.
> It was very difficult to organize the content and I am sure it'll get
into
> the same shape if we don't all follow some agreed to guidelines.
>
>
> Work remaining:
> - Convert the old download pages to the new format. Thanks Venkat for
your
> help thus far for moving the content from the old style to the new
style.
> - There is a lot of in-progress documentation. Are any of these 
ready to

> be
> added to the list of documentations for each project?
>
> Haleh
>
> On 6/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi Haleh, please see my comments inline.
> >
> > Thanks
> >
> > - Venkat
> >
> > On 6/1/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> > >
> > > I don't see a difference and in fact it is  more work.
> > >
> > > In today's mode: you update one page.
> > > a) update Latest release
> > > b) move the old release to previous releases.
> > > (Note: I think previous releases should be on the same page).
> >
> >
> > For every release I suppose we will have alteast 1 or 1.5 pages of
> > information i.e. the release related info and the two tables.  Do you
> mean
> > we move all of this to the 'Previous Release' section.  If we did 
this

> by
> > the end of this year we will have several pages to scroll down to.
> >
> > In your proposal: Have a page for each release and then link it back
to
> > > latest releases page.
> >
> >
> > Yes.. the pages are short and concise.  There is just about a list of
> > releases and the user can choose any one and then get to read up what
> the
> > release contains and what is downloadable on a diff. pages.  This is
not
> > much overhead - what is more is just a couple of lines.
> >
> > Are we making this too complicated? My preference would be to convert
> the
> > > table we currently have into something readable
> > > that has a link to readme for the release on the same page. I'll 
add

a
> > > sample to the page so we can take a look.
> > >
> > > On 6/1/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Haleh,
> > > >
> > > > I am trying to re-org the downloads / release page for the
following
> > > > reason
> > > > :--
> > > >
> > > > Currently the SCA Release pages points to two things i) Latest
> Release
> > > ii)
> > > > Previous Releases.  In the Latest Release section we have
hardcoded
> > the
> > > > content for the 0.90 release.  This is something we will have to
> > revisit
> > > > every time we make a release and then the content there has to be
> > moved
> > > > over
> > > > as well.  i.e. for 0.91 we will have to edit this page and then
move
> > the
> > > > contents of 0.90 else where.  To help this to be a bit smooth, I
> > suggest
> > > > that for every release we create a separate page i.e. a page for
> 0.90,
> > a
> > > > page for 0.91 and so on.  Then in the SCA Releases page we simply
> > > > 'inlcude'
> > > > the relevant page under the 'Latest Release' section.
> > > >
> > > > For the section on Previous Releases, I suggest that we put up a
> > > > table/list
> > > > of links to all the previous release pages.  So when there is 
0.91

,
> we
> > > > simply include 0.91 page to the 'Latest Release' section and then
> > > include
> > > > '
> > > > 0.90' page to the 'Previous Releases' list.
> > > >
> > > > I feel this is maintainable in the long run.  Hope I am no 
missing

> > > > something
> > > > in all of this
> > > >
> > > > - Venkat
> > > >
> > > > On 6/1/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi Kelvin, I've just added one more m

Re: Website - Consistent navigation menus

[ant elder]

I don't like this bit:

"Since the Wiki content forms the backbone for the public website content,
it is important that the community adheres to some community accepted common
guidelines when authoring content on the Wiki, to help in consistency and
maintainability of the content."

If we're worried about what happens on the website we should just restrict
access so only committers can update it, then, just as with the code, we
work CTR.

The website is looking good now, much better than before, but IMHO that
doesn't mean its perfect or that we should try to restrict or control any
future changes to it.

  ...ant

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


Hi,

I've added more to this guidelines page.  Please take a look and see if it
all makes sense.  Thanks.

- Venkat

On 6/5/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Website update is done.
>
> Below is the draft of 'cwiki development guide' that lays out the tree
> structure for cwiki.
>
>
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+cwiki+Development+Guideline
> Can we update it with your suggestions and once an agreement is reached
> make
> it the development guide for cwiki.
> It was very difficult to organize the content and I am sure it'll get
into
> the same shape if we don't all follow some agreed to guidelines.
>
>
> Work remaining:
> - Convert the old download pages to the new format. Thanks Venkat for
your
> help thus far for moving the content from the old style to the new
style.
> - There is a lot of in-progress documentation. Are any of these ready to
> be
> added to the list of documentations for each project?
>
> Haleh
>
> On 6/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi Haleh, please see my comments inline.
> >
> > Thanks
> >
> > - Venkat
> >
> > On 6/1/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> > >
> > > I don't see a difference and in fact it is  more work.
> > >
> > > In today's mode: you update one page.
> > > a) update Latest release
> > > b) move the old release to previous releases.
> > > (Note: I think previous releases should be on the same page).
> >
> >
> > For every release I suppose we will have alteast 1 or 1.5 pages of
> > information i.e. the release related info and the two tables.  Do you
> mean
> > we move all of this to the 'Previous Release' section.  If we did this
> by
> > the end of this year we will have several pages to scroll down to.
> >
> > In your proposal: Have a page for each release and then link it back
to
> > > latest releases page.
> >
> >
> > Yes.. the pages are short and concise.  There is just about a list of
> > releases and the user can choose any one and then get to read up what
> the
> > release contains and what is downloadable on a diff. pages.  This is
not
> > much overhead - what is more is just a couple of lines.
> >
> > Are we making this too complicated? My preference would be to convert
> the
> > > table we currently have into something readable
> > > that has a link to readme for the release on the same page. I'll add
a
> > > sample to the page so we can take a look.
> > >
> > > On 6/1/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Haleh,
> > > >
> > > > I am trying to re-org the downloads / release page for the
following
> > > > reason
> > > > :--
> > > >
> > > > Currently the SCA Release pages points to two things i) Latest
> Release
> > > ii)
> > > > Previous Releases.  In the Latest Release section we have
hardcoded
> > the
> > > > content for the 0.90 release.  This is something we will have to
> > revisit
> > > > every time we make a release and then the content there has to be
> > moved
> > > > over
> > > > as well.  i.e. for 0.91 we will have to edit this page and then
move
> > the
> > > > contents of 0.90 else where.  To help this to be a bit smooth, I
> > suggest
> > > > that for every release we create a separate page i.e. a page for
> 0.90,
> > a
> > > > page for 0.91 and so on.  Then in the SCA Releases page we simply
> > > > 'inlcude'
> > > > the relevant page under the 'Latest Release' section.
> > > >
> > > > For the section on Previous Releases, I suggest that we put up a
> > > > table/list
> > > > of links to all the previous release pages.  So when there is 0.91
,
> we
> > > > simply include 0.91 page to the 'Latest Release' section and then
> > > include
> > > > '
> > > > 0.90' page to the 'Previous Releases' list.
> > > >
> > > > I feel this is maintainable in the long run.  Hope I am no missing
> > > > something
> > > > in all of this
> > > >
> > > > - Venkat
> > > >
> > > > On 6/1/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi Kelvin, I've just added one more menu item 'SCA Java Home' to
> > link
> > > > > back to the home page of the subproject.  Will do the same for
DAS
> > and
> > > > SDO
> > > > > as well, now.
> > > > >
> > > > > Also I am going to see if we can get the other downloads pages
(M2
> > > ones)
> > > > > to look the same as the current one.

Re: Website - Consistent navigation menus

[Venkata Krishnan]

Hi,

I've added more to this guidelines page.  Please take a look and see if it
all makes sense.  Thanks.

- Venkat

On 6/5/07, haleh mahbod <[EMAIL PROTECTED]> wrote:


Hi,

Website update is done.

Below is the draft of 'cwiki development guide' that lays out the tree
structure for cwiki.

http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+cwiki+Development+Guideline
Can we update it with your suggestions and once an agreement is reached
make
it the development guide for cwiki.
It was very difficult to organize the content and I am sure it'll get into
the same shape if we don't all follow some agreed to guidelines.


Work remaining:
- Convert the old download pages to the new format. Thanks Venkat for your
help thus far for moving the content from the old style to the new style.
- There is a lot of in-progress documentation. Are any of these ready to
be
added to the list of documentations for each project?

Haleh

On 6/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi Haleh, please see my comments inline.
>
> Thanks
>
> - Venkat
>
> On 6/1/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> >
> > I don't see a difference and in fact it is  more work.
> >
> > In today's mode: you update one page.
> > a) update Latest release
> > b) move the old release to previous releases.
> > (Note: I think previous releases should be on the same page).
>
>
> For every release I suppose we will have alteast 1 or 1.5 pages of
> information i.e. the release related info and the two tables.  Do you
mean
> we move all of this to the 'Previous Release' section.  If we did this
by
> the end of this year we will have several pages to scroll down to.
>
> In your proposal: Have a page for each release and then link it back to
> > latest releases page.
>
>
> Yes.. the pages are short and concise.  There is just about a list of
> releases and the user can choose any one and then get to read up what
the
> release contains and what is downloadable on a diff. pages.  This is not
> much overhead - what is more is just a couple of lines.
>
> Are we making this too complicated? My preference would be to convert
the
> > table we currently have into something readable
> > that has a link to readme for the release on the same page. I'll add a
> > sample to the page so we can take a look.
> >
> > On 6/1/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Haleh,
> > >
> > > I am trying to re-org the downloads / release page for the following
> > > reason
> > > :--
> > >
> > > Currently the SCA Release pages points to two things i) Latest
Release
> > ii)
> > > Previous Releases.  In the Latest Release section we have hardcoded
> the
> > > content for the 0.90 release.  This is something we will have to
> revisit
> > > every time we make a release and then the content there has to be
> moved
> > > over
> > > as well.  i.e. for 0.91 we will have to edit this page and then move
> the
> > > contents of 0.90 else where.  To help this to be a bit smooth, I
> suggest
> > > that for every release we create a separate page i.e. a page for
0.90,
> a
> > > page for 0.91 and so on.  Then in the SCA Releases page we simply
> > > 'inlcude'
> > > the relevant page under the 'Latest Release' section.
> > >
> > > For the section on Previous Releases, I suggest that we put up a
> > > table/list
> > > of links to all the previous release pages.  So when there is 0.91,
we
> > > simply include 0.91 page to the 'Latest Release' section and then
> > include
> > > '
> > > 0.90' page to the 'Previous Releases' list.
> > >
> > > I feel this is maintainable in the long run.  Hope I am no missing
> > > something
> > > in all of this
> > >
> > > - Venkat
> > >
> > > On 6/1/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Kelvin, I've just added one more menu item 'SCA Java Home' to
> link
> > > > back to the home page of the subproject.  Will do the same for DAS
> and
> > > SDO
> > > > as well, now.
> > > >
> > > > Also I am going to see if we can get the other downloads pages (M2
> > ones)
> > > > to look the same as the current one.
> > > >
> > > > - Venkat
> > > >
> > > > On 6/1/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Haleh,
> > > > >   this looks really good, thanks. I particularly like the
"Latest
> > > > > Tuscany
> > > > > Releases" inset box and the new download page layout.  The
> > sub-project
> > > > > menu
> > > > > doesn't provide a link back to the sub-project's home. Would it
be
> > > > > possible
> > > > > to make the title of the sub-project menu to be a link back to
the
> > > > > sub-project's home?
> > > > >
> > > > > Regards, Kelvin.
> > > > >
> > > > > On 01/06/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi,
> > > > > > The left navigation bar used to change as we navigated through
> > > pages.
> > > > > > We also had a discussion around wanting a release page per
> > > subproject
> > > > > on
> > > > > > the
> > > > > > subproject page.
> > > > > > Based on thes

Re: Reactivating the extension, ready to go with the latest commits to sandbox

[Mike Edwards]

Jean-Sebastien,

OK, with the latest commit to the sandbox, there is a working version of 
the Spring implementation.  It has the fixes you need, plus a set of 
other changes which have got the basic version working.


I'll hold off on further updates until it's in trunk.

The next step is to get References working from the Spring 
implementation to some external SCA components.



Yours,  Mike.

Jean-Sebastien Delfino wrote:
I reviewed the update of the Spring extension that Mike has put in the 
sandbox and it looks like a good step to get the Spring extension going 
again.


I just had to adjust a few lines to use the 0.90  release SPIs to get it 
building with the level of code in trunk. I'll commit these fixes later 
today.


Then I'd like to replace the old modules/spring-implementation in trunk 
(which is broken) by this update. If there's no objection I'll do that 
sometime tomorrow.





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

[jira] Updated: (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 updated TUSCANY-513:
---

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.0

Setting target version to SDO Java 1.0 to reflect Ron's wishes

> 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.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"/>
> >  
> >  
> > 
> >
> >   
> >
> > 
> >  
> >  
> > 
> > Sc

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

Patch Info: [Patch Available]

> 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-Next
>
> Attachments: 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.w3.org/2001/XMLSchema>";;
> >xmlns:ord="

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

Ron Gavlin commented on TUSCANY-513:


Folks,

I have attached patches for sdo-impl and sdo-tools to resolve this issue. I 
apologize that the patch is a bit stale however this is the version of the 
patch that is approved for contribution. In particular, the sdo-tools 
JavaGenerator is a bit out of date but the merge should be trivial for you.

It would be greatly appreciated if you reviewed and applied this patch prior to 
the tuscany sdo 1.0 release. If there is anything I can do to help make that 
happen, let me know.

Thanks for your continued support.

- 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-Next
>
> Attachments: 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>";;
> > 

[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.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-Next
>
> Attachments: 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.w3.org/2001/XMLSchema>";;
> > 

[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.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-Next
>
> Attachments: 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.w3.org/2001/XMLSchema>";;
> >  

[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: (was: tuscany-sdo-impl.TUSCANY-513.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-Next
>
> Attachments: 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.w3.org/2001/XMLSchema>";;
> 

[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: (was: tuscany-sdo-tools.TUSCANY-513.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-Next
>
> Attachments: 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.w3.org/2001/XMLSchema>";;
>

[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.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-Next
>
> Attachments: 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.w3.org/2001/XMLSchema>";;
> > 

[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.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-Next
>
> Attachments: 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.w3.org/2001/XMLSchema>";;
> >  

Re: [IP CLEARANCE] An external contribution to Apache Tuscany

[Simon Nash]

I'm following up on this thread which has gone very quiet.  AFAIK
there has not yet been an acknowledgement of the software grant form
by an officer of the ASF.  Can anyone who is an officer of the ASF
help with this, please?

  Simon

Raymond Feng wrote:


Hi,

The Tuscany project (which is currently under incubation) recently 
received a code donation from IBM under JIRA TUSCANY-1126 
(http://issues.apache.org/jira/browse/TUSCANY-1126). As indicated in the 
issue, the contribution was from IBM to Apache as granted by the CCLA 
signed on 9 February 2007.


As the starting point, can an Officer of the ASF acknowledge the receipt 
of the software grant form?


Please educate me if you find any issues as I'm new to this process.

Thanks,
Raymond

-
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: XSLT binding

[Simon Nash]

+1 for adding an XSLT implementation type to Tuscany.

  Simon

ant elder wrote:

On 5/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:



- any interest in an xslt binding that could take the incoming soap message


and transform it to fit a business domain schema to allow for cleaner SDO
generated object models?




I had a play around with trying to get the script container working with
xslt and now I'm not sure the JSR-223 xslt integration is the best 
approach,

so think it would be great to have an xslt extension. Would you still be
interested in having  a go at that?  The latest Tuscany code makes writing
an extension quite easy, you could probably start by just copying the
existing implementation-script module and changing that for xslt.

 ...ant




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

[Java SDO CTS] code coverage tests

[kelvin goodson]

I'm running the clover maven plugin against SDO and its unit tests to get
code coverage figures.  However, I'd like to get results for the CTS against
the Tuscany SDO implementation.  My assumption from reading the clover
documentation is that since the SDO implementation is simply a maven
dependency for the CTS, that clover will not be able to produce figures for
coverage of the SDO implementation whilst running the CTS.   My next step is
to create a local single project that includes source for both the impl and
the CTS,  but that's not a very nice solution. Does anyone have any insights
into this?
--
Kelvin.

Re: Reactivating the extension, was: svn commit: r543273 [1/2]

[ant elder]

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


Sebastien,

You may like to wait just a little - I have done a series of updates to
the code which have got it very near to running basic examples.  I'll
undertake to fix it to the latest level in trunk as well (I have become
VERY wary of moving up trunk levels after wasting immense amounts of
time earlier due to the level of churn in trunk).



You shouldn't need to worry about this anymore as from 0.90 on things should
be far more stable and backward compatible.

If anyone does happen to notice a breaking change occur in trunk please do
say so we know that it was a considered and intentional thing to be doing.

  ...ant

Re: Servlet path change?

[ant elder]

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


Am just playing with the big bank demo that Sebastien made and it seems
now
that the servlets have moved from

services/AccountJSONService

to

services/SCADomain/AccountJSONService

Looking back through SVN changes and the ML I can't see where this
happened
but I know that this just means I'm looking in the wrong place. Is this
change permanent. If so I'll check in fixes to the client.



That was TUSCANY-1269 and r543083, also see
http://incubator.apache.org/tuscany/sca-java-bindingjsonrpc.html although i
guess that could be updated to mention what the actual endpoint URI is.

The "services/' part is coming from the servlet definition in the web.xml.
The "SCADomain/" part is fixed right now, the "AccountJSONService" is the
name of the binding.

TUSCANY-1269 brought the binding.ajax and binding.jsonrpc together so they
work the same way and which binding is used can be transparent to clients,
but I don't think this is the permanent final solution yet. We probably
should try to make all binding endpoints work as much as possible in a
standard way as described in section 1.7.2 of the Assembly spec.

  ...ant

Servlet path change?

[Simon Laws]

Am just playing with the big bank demo that Sebastien made and it seems now
that the servlets have moved from

services/AccountJSONService

to

services/SCADomain/AccountJSONService

Looking back through SVN changes and the ML I can't see where this happened
but I know that this just means I'm looking in the wrong place. Is this
change permanent. If so I'll check in fixes to the client.

Simon

Re: Contribute to SCA-OSGi integration

[ant elder]

On 6/5/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote:


I will submit the code through JIRA once it is ready. If there is already
documentation about the Tuscany SPIs, I would like to use it, otherwise,
the
samples and the Java implementation seem to be quite useful to get
started.

OSGi doesn't provide a standard mechanism to start a new runtime, and
different implementations use different classes and methods to start up
the
console. It would have been nice if the FrameworkAdmin service could be
used
to start up an OSGi runtime within the current VM, but since that doesn't
seem possible, we have to rely on dynamically loading up the runtime that
is
available on the classpath.  Equinox has a static method
EclipseStarter.startup() which can be used to start a single OSGi runtime
in
a VM. Apache Felix can be started using new Felix.start(properties,
activatorList) which is neater. Knoplerfish runtime can be started using
new
Framework().launch(). So I think we can get around the fact that there is
no
standard way to embed a OSGi runtime.

We haven't addressed the third aspect that Raymond mentioned (using OSGi
as
the underlying technology for SCA containers), so it is very useful to
know
that Bill is already working on it. Since this is orthogonal to the work
we
are doing, the two can go on in parallel, and yes, it will be good to have
subdirectories under contrib for the three so that the code can be shared.

Thank you

Regards,

Rajini



I've created empty modules for these, in trunk for now as we've been using
contrib more as dumping ground for old stuff, so feel free to go ahead and
start adding code:

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-osgi/
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-osgi/
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-osgi/

  ...ant

Re: Contribute to SCA-OSGi integration

[Rajini Sivaram]

I will submit the code through JIRA once it is ready. If there is already
documentation about the Tuscany SPIs, I would like to use it, otherwise, the
samples and the Java implementation seem to be quite useful to get started.

OSGi doesn't provide a standard mechanism to start a new runtime, and
different implementations use different classes and methods to start up the
console. It would have been nice if the FrameworkAdmin service could be used
to start up an OSGi runtime within the current VM, but since that doesn't
seem possible, we have to rely on dynamically loading up the runtime that is
available on the classpath.  Equinox has a static method
EclipseStarter.startup() which can be used to start a single OSGi runtime in
a VM. Apache Felix can be started using new Felix.start(properties,
activatorList) which is neater. Knoplerfish runtime can be started using new
Framework().launch(). So I think we can get around the fact that there is no
standard way to embed a OSGi runtime.

We haven't addressed the third aspect that Raymond mentioned (using OSGi as
the underlying technology for SCA containers), so it is very useful to know
that Bill is already working on it. Since this is orthogonal to the work we
are doing, the two can go on in parallel, and yes, it will be good to have
subdirectories under contrib for the three so that the code can be shared.

Thank you

Regards,

Rajini

[ANNOUNCE] Apache Tuscany SCA Java 0.90 released

[ant elder]

The Apache Tuscany team are pleased to announce the 0.90-incubating release
of the Java SCA project.

Apache Tuscany provides a runtime based on the Service Component
Architecture. SCA is a set of specifications aimed at simplifying SOA
Application Development which are being standardized at OASIS as part of
Open Composite Services Architecture (Open CSA).

This release represents a significant milestone on the road to an Apache
Tuscany SCA 1.0 release. It is based on the final 1.0 versions of the SCA
specifications and it includes a substantial redesign of parts of the
runtime which has significantly improved usability compared with previous
releases, as well as providing stable, easy to use SPIs for extension
development.

To download or for more information about the release go to:
http://incubator.apache.org/tuscany/sca-java-releases.html

To find out more about OASIS Open CSA go to: http://www.oasis-opencsa.org.

Apache Tuscany welcomes your help. Any contribution, including code,
testing, improving the documentation, or bug reporting is always
appreciated. For more information on how to get involved in Apache Tuscany
visit the website at: http://incubator.apache.org/tuscany.

Thank you for your interest in Apache Tuscany!
The Apache Tuscany Team.
---

Tuscany is an effort undergoing incubation at the Apache Software Foundation
(ASF), sponsored by the Apache Web services PMC. Incubation is required of
all newly accepted projects until a further review indicates that the
infrastructure, communications, and decision making process have stabilized
in a manner consistent with other successful ASF projects. While incubation
status is not necessarily a reflection of the completeness or stability of
the code, it does indicate that the project has yet to be fully endorsed by
the ASF.