[jira] Commented: (TUSCANY-536) Cannot mix both WS Entrypoint and WS External Service
[
http://issues.apache.org/jira/browse/TUSCANY-536?page=comments#action_12440816
]
Dinesh Premalal commented on TUSCANY-536:
-
Attached sample on issue Axis2c-209. Could somebody please tell What's the idea
about provided sample? Does it meet your requirement? else please let us know.
> Cannot mix both WS Entrypoint and WS External Service
> -
>
> Key: TUSCANY-536
> URL: http://issues.apache.org/jira/browse/TUSCANY-536
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SCA
>Affects Versions: Cpp-current, Cpp-M1
>Reporter: Andrew Borley
>Priority: Minor
> Fix For: Cpp-current
>
>
> A component invoked via a WS Entrypoint fails after invoking a WS External
> Service. I believe this is a problem with freeing memory in Axis2C & have
> asked a question on the Axis2C mailing list. Currently this causes the server
> to crash.
> A workaround can be used - comment out the block that frees the Axis2C
> service client in Axis2Client.cpp at line 169:
> //if (svc_client)
> //{
> //AXIS2_SVC_CLIENT_FREE(svc_client, env);
> //svc_client = NULL;
> //}
> Unfortunately this can cause memory leakage problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can JAXB/XMLBeans work with axis binding now
Sorry, I don't know that before. Thanks for your help, Jeremy! Li 2006/10/9, Jeremy Boynes <[EMAIL PROTECTED]>: Li, your email is being held in a moderation queue as you are not subscribed to the mailing list. I've modded one copy through. -- Jeremy On Oct 8, 2006, at 6:54 PM, Li Shen wrote: > Hi, > > I noticed that in the helloworldws sample, now only SDO gets used. > If I want > to use JAXB/XMLBeans instead of SDO, what shall I do then? > > Basically, I know I may need to register the SCDL of JAXB/XMLBeans > to my > Tuscany runtime, and replace some configurations such as > @DataType(name="commonj.sdo.DataObject") and in > helloworldws with > JAXB/XMLBeans specific stuff. Is that correct? How will and > look like? The same as SDO? Also, looks like for now > there is > still no SCDL available for JAXB/XMLBeans, do you guys have any > plan to add > them? > > Thanks, > Li > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: Can JAXB/XMLBeans work with axis binding now
Sorry, I don't know that before. Thanks for your help, Jeremy! Li > -Original Message- > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > Sent: Monday, October 09, 2006 12:55 PM > To: Li Shen > Cc: tuscany-dev@ws.apache.org > Subject: Re: Can JAXB/XMLBeans work with axis binding now > > Li, your email is being held in a moderation queue as you are not > subscribed to the mailing list. I've modded one copy through. > -- > Jeremy > > On Oct 8, 2006, at 6:54 PM, Li Shen wrote: > > > Hi, > > > > I noticed that in the helloworldws sample, now only SDO gets used. > > If I want > > to use JAXB/XMLBeans instead of SDO, what shall I do then? > > > > Basically, I know I may need to register the SCDL of JAXB/XMLBeans > > to my > > Tuscany runtime, and replace some configurations such as > > @DataType(name="commonj.sdo.DataObject") and in > > helloworldws with > > JAXB/XMLBeans specific stuff. Is that correct? How will and > > look like? The same as SDO? Also, looks like for now > > there is > > still no SCDL available for JAXB/XMLBeans, do you guys have any > > plan to add > > them? > > > > Thanks, > > Li > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can JAXB/XMLBeans work with axis binding now
Sorry, I don't know that before. Thanks for your help, Jeremy! Li > -Original Message- > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > Sent: Monday, October 09, 2006 12:55 PM > To: Li Shen > Cc: tuscany-dev@ws.apache.org > Subject: Re: Can JAXB/XMLBeans work with axis binding now > > Li, your email is being held in a moderation queue as you are not > subscribed to the mailing list. I've modded one copy through. > -- > Jeremy > > On Oct 8, 2006, at 6:54 PM, Li Shen wrote: > > > Hi, > > > > I noticed that in the helloworldws sample, now only SDO gets used. > > If I want > > to use JAXB/XMLBeans instead of SDO, what shall I do then? > > > > Basically, I know I may need to register the SCDL of JAXB/XMLBeans > > to my > > Tuscany runtime, and replace some configurations such as > > @DataType(name="commonj.sdo.DataObject") and in > > helloworldws with > > JAXB/XMLBeans specific stuff. Is that correct? How will and > > look like? The same as SDO? Also, looks like for now > > there is > > still no SCDL available for JAXB/XMLBeans, do you guys have any > > plan to add > > them? > > > > Thanks, > > Li > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SDO can't load an XML doc with no namespace
Sebastian, I looked into this a bit more and it may not be as bad as it appears. Currently, when the XML parser encounters an element for which there is no type defined, it ignores that element and all of its content, resuming the parse once that unknown element has ended. The exception to this is when the element is a member of a parent that is defined to have open content. In your example, the root element has no type definition and, of course, it can't have a parent with open content, so it and all of its contents are ignored, which explains the output that you see. I can see one possible workaround and one possible fix for this. The workaround is that you provide an xsd that defines just the root element giving it open content. In your case that would be something like http://www.w3.org/2001/XMLSchema";> Then the root element has a type and will be processed normally, and everything it contains will be processed as open content. I tried this and it seems to work. The fix would be for me to hack the code so that when we find that a root element has no corresponding type (or possibly when there are no user defined types at all) then I could automagically create an open type for it. This would give the same behaviour as the previous case but spare you the need to provide the .xsd I'm inclined to just go ahead and do that since its not obviously any worse than the current behaviour but I'm open to other ideas. Regards, Geoff. On 07/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Well, I can load it, but it's desperately empty :) Given the following XML: JaneDoe I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: Is this supported by our SDO/C++ implementation? or is it a bug? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JIRA Permissions
Hi Can I assign JIRAs to myself and then update them futher as I work or close them ? How do I do that ? I had raised http://issues.apache.org/jira/browse/TUSCANY-809 releated to updating license headers and want to close that now as I have committed the updates. Thanks - Venkat
Re: [C++] SDO can't load an XML doc with no namespace
Can you create an open type on the fly? Is the datafactory not "locked" once the first DO is created? Cheers, On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: Sebastian, I looked into this a bit more and it may not be as bad as it appears. Currently, when the XML parser encounters an element for which there is no type defined, it ignores that element and all of its content, resuming the parse once that unknown element has ended. The exception to this is when the element is a member of a parent that is defined to have open content. In your example, the root element has no type definition and, of course, it can't have a parent with open content, so it and all of its contents are ignored, which explains the output that you see. I can see one possible workaround and one possible fix for this. The workaround is that you provide an xsd that defines just the root element giving it open content. In your case that would be something like http://www.w3.org/2001/XMLSchema";> Then the root element has a type and will be processed normally, and everything it contains will be processed as open content. I tried this and it seems to work. The fix would be for me to hack the code so that when we find that a root element has no corresponding type (or possibly when there are no user defined types at all) then I could automagically create an open type for it. This would give the same behaviour as the previous case but spare you the need to provide the .xsd I'm inclined to just go ahead and do that since its not obviously any worse than the current behaviour but I'm open to other ideas. Regards, Geoff. On 07/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Well, I can load it, but it's desperately empty :) > > Given the following XML: > JaneDoe > > I have no XSD for this document, and don't want to have one or have to > define specific SDO types for it. I just want to load this XML into an > SDO DataObject. > > XMLDocumentPtr doc = XMLHelper::load(xml); > gives me an XMLDocumentPtr with no root DataObject. > > char* xml = XMLHelper::save(doc); > gives me this: > > > Is this supported by our SDO/C++ implementation? or is it a bug? > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Pete
Re: [C++] A name for M2
OK. Name chosen: -1.0-incubator-M2 Thanks all! On 10/5/06, haleh mahbod <[EMAIL PROTECTED]> wrote: Makes sense to keep the naming convention consistent across Tuscany. On 10/5/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Pete Robbins wrote: > > -1.0-incubator-M2 looks good for me. > > > > +1 from me. > > > On 05/10/06, Andrew Borley <[EMAIL PROTECTED]> wrote: > >> > >> Hi everyone, > >> > >> We need to choose a full name for the forthcoming release, so I've put > a > >> few > >> suggestions below - any favourite? > >> So far we've been referring to this release as M2 or Milestone 2 so all > >> the > >> suggestions below have M2 in them. > >> We don't have the Maven restriction to start with a number, but we may > >> want > >> to follow the Java naming for M2 (1.0-incubator-M2), alternatively we > >> could > >> follow the names from the first C++ release: tuscany_sca_cpp- > >> 0.1.incubating-M1 and tuscany_sdo_cpp-0.1.incubating-M1 > >> > >> Some alternatives are: > >> tuscany_sca_cpp-1.0-incubator-M2 > >> tuscany_sca_cpp-0.1.incubating-M2 > >> tuscany_sca_cpp-0.2.incubating-M2 > >> > >> Any preferences/better ideas? Mine would be the first in the list to > >> show > >> that we are at a similar level to the Java side ;-). > >> > >> Cheers > >> Andy > >> > >> > > > > > > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: About Node2Object Databinding Transformer
Hi Raymond,
Is there where you recommend the fix to be in SimpleTypeMapperExtension
public Object toJavaObject(TypeInfo simpleType, String value,
TransformationContext context) {
value = value.trim()
...
...
Shall I make this change and commit ? Please let me know. Thanks
- Venkat
On 10/9/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
We probably should call the "trim()" in SimpleTypeMapperExtension.
Thanks,
Raymond
- Original Message -
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To:
Sent: Sunday, October 08, 2006 2:55 AM
Subject: About Node2Object Databinding Transformer
> Hi Raymond,
>
> Presently the :
> org.apache.tuscany.core.databinding.xml.Node2Objecttransformer's
> 'getText' method returns the xml text as is packed with
> whitespaces. Can it return the text after trimming it ? ...
>
> protected String getText(Node source) {
>if (source instanceof Document) {
>source = ((Document)source).getDocumentElement();
>}
>return source.getTextContent().trim();
>}
>
> The reason I ask for this is that it makes a difference when configuring
> component properties. i.e.
>
> Hi There
>
> is different from ...
>
>
> Hi There
>
>
> The second one returns the property value packed with whitespaces
> (including
> the newline char). Also for numerical property values we might have
have
> problems in parsing.
>
> Thanks
>
> - Venkat
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SDO can't load an XML doc with no namespace
That's a different question. As I understand it, Sebastian (and others) were asking about loading an XML instance document without a corresponding xsd (or any other type information) and as above there is a way to do that and I can hack it to make it a little easier. As you say, you cannot create any type at all after the first data object is created. I'm looking into relaxing that too, but it is a separate issue from processing XML without a schema. Regards, Geoff. On 09/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote: Can you create an open type on the fly? Is the datafactory not "locked" once the first DO is created? Cheers, On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > Sebastian, > > I looked into this a bit more and it may not be as bad as it appears. > > Currently, when the XML parser encounters an element for which there is no > type defined, it ignores that element and all of its content, resuming the > parse once that unknown element has ended. The exception to this is when > the > element is a member of a parent that is defined to have open content. In > your example, the root element has no type definition and, of course, it > can't have a parent with open content, so it and all of its contents are > ignored, which explains the output that you see. > > I can see one possible workaround and one possible fix for this. > > The workaround is that you provide an xsd that defines just the root > element > giving it open content. In your case that would be something like > > http://www.w3.org/2001/XMLSchema";> > > > > > > > > > Then the root element has a type and will be processed normally, and > everything it contains will be processed as open content. I tried this and > it seems to work. > > The fix would be for me to hack the code so that when we find that a root > element has no corresponding type (or possibly when there are no user > defined types at all) then I could automagically create an open type for > it. > This would give the same behaviour as the previous case but spare you the > need to provide the .xsd > > I'm inclined to just go ahead and do that since its not obviously any > worse > than the current behaviour but I'm open to other ideas. > > Regards, > > Geoff. > > On 07/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > Well, I can load it, but it's desperately empty :) > > > > Given the following XML: > > JaneDoe > > > > I have no XSD for this document, and don't want to have one or have to > > define specific SDO types for it. I just want to load this XML into an > > SDO DataObject. > > > > XMLDocumentPtr doc = XMLHelper::load(xml); > > gives me an XMLDocumentPtr with no root DataObject. > > > > char* xml = XMLHelper::save(doc); > > gives me this: > > > > > > Is this supported by our SDO/C++ implementation? or is it a bug? > > > > -- > > Jean-Sebastien > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- Pete
Re: [C++] SDO can't load an XML doc with no namespace
Well it depends on which DataFactory you are using during the loading of the xml. I would usually create an XSDHelper and load a schema. I'd then create an XMLHelper using the DataFactory from the XSDHelper. I then load my xml. If I now load a "schemaless" xml using that XMLHelper how do you create the new Open Type? Cheers, On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: That's a different question. As I understand it, Sebastian (and others) were asking about loading an XML instance document without a corresponding xsd (or any other type information) and as above there is a way to do that and I can hack it to make it a little easier. As you say, you cannot create any type at all after the first data object is created. I'm looking into relaxing that too, but it is a separate issue from processing XML without a schema. Regards, Geoff. On 09/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > Can you create an open type on the fly? Is the datafactory not "locked" > once > the first DO is created? > > Cheers, > > > On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > > > Sebastian, > > > > I looked into this a bit more and it may not be as bad as it appears. > > > > Currently, when the XML parser encounters an element for which there is > no > > type defined, it ignores that element and all of its content, resuming > the > > parse once that unknown element has ended. The exception to this is when > > the > > element is a member of a parent that is defined to have open content. In > > your example, the root element has no type definition and, of course, it > > can't have a parent with open content, so it and all of its contents are > > ignored, which explains the output that you see. > > > > I can see one possible workaround and one possible fix for this. > > > > The workaround is that you provide an xsd that defines just the root > > element > > giving it open content. In your case that would be something like > > > > http://www.w3.org/2001/XMLSchema";> > > > > > > > > > > > > > > > > > > Then the root element has a type and will be processed normally, and > > everything it contains will be processed as open content. I tried this > and > > it seems to work. > > > > The fix would be for me to hack the code so that when we find that a > root > > element has no corresponding type (or possibly when there are no user > > defined types at all) then I could automagically create an open type for > > it. > > This would give the same behaviour as the previous case but spare you > the > > need to provide the .xsd > > > > I'm inclined to just go ahead and do that since its not obviously any > > worse > > than the current behaviour but I'm open to other ideas. > > > > Regards, > > > > Geoff. > > > > On 07/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > > Well, I can load it, but it's desperately empty :) > > > > > > Given the following XML: > > > > JaneDoe > > > > > > I have no XSD for this document, and don't want to have one or have to > > > define specific SDO types for it. I just want to load this XML into an > > > SDO DataObject. > > > > > > XMLDocumentPtr doc = XMLHelper::load(xml); > > > gives me an XMLDocumentPtr with no root DataObject. > > > > > > char* xml = XMLHelper::save(doc); > > > gives me this: > > > > > > > > > Is this supported by our SDO/C++ implementation? or is it a bug? > > > > > > -- > > > Jean-Sebastien > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > Pete > > -- Pete
Re: [C++] SDO can't load an XML doc with no namespace
That is still a separate issue from the one Sebastian raised. Sebastian specifically stated that he did not have an xsd and didn't want one. Loading an XML instance without type information in that situation can be done, via a small xsd file immediately (as a workaround), and via small code change soon. The issue of frozen type systems affects other things besides this one. It needs to be fixed, but it's still a separate question. Geoff. On 09/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote: Well it depends on which DataFactory you are using during the loading of the xml. I would usually create an XSDHelper and load a schema. I'd then create an XMLHelper using the DataFactory from the XSDHelper. I then load my xml. If I now load a "schemaless" xml using that XMLHelper how do you create the new Open Type? Cheers, On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > That's a different question. > > As I understand it, Sebastian (and others) were asking about loading an > XML > instance document without a corresponding xsd (or any other type > information) and as above there is a way to do that and I can hack it to > make it a little easier. > > As you say, you cannot create any type at all after the first data object > is > created. I'm looking into relaxing that too, but it is a separate issue > from > processing XML without a schema. > > Regards, > > Geoff. > > On 09/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > Can you create an open type on the fly? Is the datafactory not "locked" > > once > > the first DO is created? > > > > Cheers, > > > > > > On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > > > > > Sebastian, > > > > > > I looked into this a bit more and it may not be as bad as it appears. > > > > > > Currently, when the XML parser encounters an element for which there > is > > no > > > type defined, it ignores that element and all of its content, resuming > > the > > > parse once that unknown element has ended. The exception to this is > when > > > the > > > element is a member of a parent that is defined to have open content. > In > > > your example, the root element has no type definition and, of course, > it > > > can't have a parent with open content, so it and all of its contents > are > > > ignored, which explains the output that you see. > > > > > > I can see one possible workaround and one possible fix for this. > > > > > > The workaround is that you provide an xsd that defines just the root > > > element > > > giving it open content. In your case that would be something like > > > > > > http://www.w3.org/2001/XMLSchema";> > > > > > > > > > > > > > > > > > > > > > > > > > > > Then the root element has a type and will be processed normally, and > > > everything it contains will be processed as open content. I tried this > > and > > > it seems to work. > > > > > > The fix would be for me to hack the code so that when we find that a > > root > > > element has no corresponding type (or possibly when there are no user > > > defined types at all) then I could automagically create an open type > for > > > it. > > > This would give the same behaviour as the previous case but spare you > > the > > > need to provide the .xsd > > > > > > I'm inclined to just go ahead and do that since its not obviously any > > > worse > > > than the current behaviour but I'm open to other ideas. > > > > > > Regards, > > > > > > Geoff. > > > > > > On 07/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > > > > Well, I can load it, but it's desperately empty :) > > > > > > > > Given the following XML: > > > > > > JaneDoe > > > > > > > > I have no XSD for this document, and don't want to have one or have > to > > > > define specific SDO types for it. I just want to load this XML into > an > > > > SDO DataObject. > > > > > > > > XMLDocumentPtr doc = XMLHelper::load(xml); > > > > gives me an XMLDocumentPtr with no root DataObject. > > > > > > > > char* xml = XMLHelper::save(doc); > > > > gives me this: > > > > > > > > > > > > Is this supported by our SDO/C++ implementation? or is it a bug? > > > > > > > > -- > > > > Jean-Sebastien > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > -- > > Pete > > > > > > -- Pete
Re: [C++] SDO can't load an XML doc with no namespace
You are assuming the state of the DataFactory that is passed in when loading
the xml.
XMLHelperptr xmlH = HelperProvider::getXMLHelper(); // returns "clean" XML
helper with virgin DataFactory
XMLDocumentPtr xmlD = xmlH->load("mySchemaless.xml"); // your fix would make
this work BUT the DataFactory is now "frozen"
XMLDocumentPtr xmlD = xmlH->load("anotherSchemaless.xml"); // Bang! - can't
add a new open type as DF is frozen
I would look at always defining an open type e.g. commonj/sdo#AnyOpenType in
a DataFactory. When loading the schemaless xml you create one of these then
create the DO's from the xml with this as the root (pseudo-root). The
XMLDocument returned would have the first DO defined from the xml as the
rootDataObject, not the pseudo-root.
Cheers,
On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
That is still a separate issue from the one Sebastian raised.
Sebastian specifically stated that he did not have an xsd and didn't want
one. Loading an XML instance without type information in that situation
can
be done, via a small xsd file immediately (as a workaround), and via small
code change soon. The issue of frozen type systems affects other things
besides this one. It needs to be fixed, but it's still a separate
question.
Geoff.
On 09/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> Well it depends on which DataFactory you are using during the loading of
> the
> xml. I would usually create an XSDHelper and load a schema. I'd then
> create
> an XMLHelper using the DataFactory from the XSDHelper. I then load my
xml.
> If I now load a "schemaless" xml using that XMLHelper how do you create
> the
> new Open Type?
>
> Cheers,
>
>
> On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
> >
> > That's a different question.
> >
> > As I understand it, Sebastian (and others) were asking about loading
an
> > XML
> > instance document without a corresponding xsd (or any other type
> > information) and as above there is a way to do that and I can hack it
to
> > make it a little easier.
> >
> > As you say, you cannot create any type at all after the first data
> object
> > is
> > created. I'm looking into relaxing that too, but it is a separate
issue
> > from
> > processing XML without a schema.
> >
> > Regards,
> >
> > Geoff.
> >
> > On 09/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > >
> > > Can you create an open type on the fly? Is the datafactory not
> "locked"
> > > once
> > > the first DO is created?
> > >
> > > Cheers,
> > >
> > >
> > > On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Sebastian,
> > > >
> > > > I looked into this a bit more and it may not be as bad as it
> appears.
> > > >
> > > > Currently, when the XML parser encounters an element for which
there
> > is
> > > no
> > > > type defined, it ignores that element and all of its content,
> resuming
> > > the
> > > > parse once that unknown element has ended. The exception to this
is
> > when
> > > > the
> > > > element is a member of a parent that is defined to have open
> content.
> > In
> > > > your example, the root element has no type definition and, of
> course,
> > it
> > > > can't have a parent with open content, so it and all of its
contents
> > are
> > > > ignored, which explains the output that you see.
> > > >
> > > > I can see one possible workaround and one possible fix for this.
> > > >
> > > > The workaround is that you provide an xsd that defines just the
root
> > > > element
> > > > giving it open content. In your case that would be something like
> > > >
> > > > http://www.w3.org/2001/XMLSchema";>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Then the root element has a type and will be processed normally,
and
> > > > everything it contains will be processed as open content. I tried
> this
> > > and
> > > > it seems to work.
> > > >
> > > > The fix would be for me to hack the code so that when we find that
a
> > > root
> > > > element has no corresponding type (or possibly when there are no
> user
> > > > defined types at all) then I could automagically create an open
type
> > for
> > > > it.
> > > > This would give the same behaviour as the previous case but spare
> you
> > > the
> > > > need to provide the .xsd
> > > >
> > > > I'm inclined to just go ahead and do that since its not obviously
> any
> > > > worse
> > > > than the current behaviour but I'm open to other ideas.
> > > >
> > > > Regards,
> > > >
> > > > Geoff.
> > > >
> > > > On 07/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Well, I can load it, but it's desperately empty :)
> > > > >
> > > > > Given the following XML:
> > > > >
> > >
> JaneDoe
> > > > >
> > > > > I have no XSD for this document, and don't want to have one or
> have
> > to
> > > > > define specific SDO types for it. I just want to load this XML
> into
> > an
> > > > > SDO DataObject.
> > > > >
> > > > > XMLDocumentPtr doc = XMLHelper::load(xml);
> > > > > gives me an XMLDocu
[jira] Commented: (TUSCANY-804) SDO build instructions must be fixed, prevents new user from building correctly.
[ http://issues.apache.org/jira/browse/TUSCANY-804?page=comments#action_12440848 ] Kelvin Goodson commented on TUSCANY-804: Aside from needing to fix the issue described, this issue highlights an assymetry. A user may be building from a source distribution (simply to recreate the binary distribution), or may be planning to begin development. For building from a source distribution the BUILDING.txt file at the top of the zip folder hierarchy describes the steps required to recreate the binary distro, and points the user to the website if they want to begin development. The website doesn't refer the user who wants to simply build the binary distribtion to the BUILDING.txt file. My suspicion here is that Brandon is trying to build the M2 release candidate using the instructions from the website for establishing a development environment. We need to be much clearer in describing the two approaches. > SDO build instructions must be fixed, prevents new user from building > correctly. > > > Key: TUSCANY-804 > URL: http://issues.apache.org/jira/browse/TUSCANY-804 > Project: Tuscany > Issue Type: Bug > Components: Website >Reporter: Brandon Werner > > On the website URL: > http://incubator.apache.org/tuscany/java_sdo_overview.html > It specifies this: > md > cd > svn co -N https://svn.apache.org/repos/asf/incubator/tuscany/java > cd java > svn up sdo > svn up -N spec > cd spec > svn up sdo > However, the last command should be "svn up sdo-api" after the branch > change > This is littered all over this page and has the effect that anyone who > tries to d/l and build just the SDO of Tuscany won't have the API :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring commonality amongst Script containers in Java SCA
On 10/7/06, Jim Marino <[EMAIL PROTECTED]> wrote: On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: > > On Oct 7, 2006, at 7:22 AM, ant elder wrote: > >> This is all working quite well now so i'd like to move it from my >> sandbox to >> be with the other containers. BSF 2.4 has just come out and the >> jar is >> available from a proper maven repo and the script container >> supports all the >> SCA things like references, properties and async, also the start of a >> website page describing it which I'll move to the site once its a >> bit more >> done: >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/doc/sca-java-container-script.xml >> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/ >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.easy/ >> > I'm fine with this as long as the name of "container.easy" can be > changed to something that denotes it has to do with scripting, > something like "container.bsf". > After looking at the code more instead of having something separate, why wouldn't we look to see if we can merge the "easy container" into the extension API? I'd like to get a clearer direction on this before we move things around. Specifically, I have a few questions related to this: 1. Is this container just for scripting? It appears not to be tied to scripting 2. What value does this container provide over the extension API? Does it automate certain coding tasks only relevant to a subset of containers or all containers? Could we just merge such automation with AtomicComponentExtension 3. There appears to be a bit of code duplication, some of which may be a vestige from the Groovy container which needs to be refactored. For example, AsyncInvoker. In a merge, maybe we could eliminate the need for this? Jim Way back I was moaning about the complexity of the SPI and it was suggested having a separate extension project for a simplified SPI for extensions with simpler requirements. I can't find a link, maybe the 1st sandbox phone call or an old IRC chat? Thats where this came from. Its not quite finished yet, there's some parts that could be simplified further. I'd also like to do the same thing for bindings but haven't got to that yet. This is not necessarily tied to only scripting containers but thats all we've tried it with so far, and as Venkat suggests there likely is a bit more work required to make it more generally useful. There probably are some parts that could be moved to existing SPI classes, but there are also parts that may be a bit inflexible to be made part of the general extension SPI. As you point out the async bit does seem pretty isolated so that probably could be easily moved out. Given we're trying to get an M2 release out real soon I'm not sure about messing with the existing SPI classes now. How about for now moving the obvious bits like async out but keeping the rest in say a separate container.helperproject or in a separate SPI package like org.apache.tuscany.spi.extension.container? ...ant ...ant
Re: JIRA Permissions
This comes up every time we add a new committer, looks like right now Jeremy is the only one able to do this, see: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg07691.html Dims, any chance I could be granted this power as well so we have someone in a different timezone to Jeremy who's able to do this? ...ant On 10/9/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi Can I assign JIRAs to myself and then update them futher as I work or close them ? How do I do that ? I had raised http://issues.apache.org/jira/browse/TUSCANY-809 releated to updating license headers and want to close that now as I have committed the updates. Thanks - Venkat
[jira] Commented: (TUSCANY-809) Update headers for files in sca tools, sca javascript, sca ruby and sca rmi projects
[ http://issues.apache.org/jira/browse/TUSCANY-809?page=comments#action_12440857 ] Venkatakrishnan commented on TUSCANY-809: - Hi, I have completed the updates and have committed them as well. Could somebody help in closing this JIRA... Thanks. > Update headers for files in sca tools, sca javascript, sca ruby and sca rmi > projects > > > Key: TUSCANY-809 > URL: http://issues.apache.org/jira/browse/TUSCANY-809 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Samples, Java SCA JavaScript Container, Java > SCA Tools >Affects Versions: Java-M2 >Reporter: Venkatakrishnan >Priority: Critical > > As reported by Daniel Kulp in > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09256.html fix the > files in the following projects: - > - sca tools > - javacript > - ruby > - rmi extension -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-809) Update headers for files in sca tools, sca javascript, sca ruby and sca rmi projects
[ http://issues.apache.org/jira/browse/TUSCANY-809?page=all ] ant elder closed TUSCANY-809. - Resolution: Fixed > Update headers for files in sca tools, sca javascript, sca ruby and sca rmi > projects > > > Key: TUSCANY-809 > URL: http://issues.apache.org/jira/browse/TUSCANY-809 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Samples, Java SCA JavaScript Container, Java > SCA Tools >Affects Versions: Java-M2 >Reporter: Venkatakrishnan >Priority: Critical > > As reported by Daniel Kulp in > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09256.html fix the > files in the following projects: - > - sca tools > - javacript > - ruby > - rmi extension -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SDO can't load an XML doc with no namespace
On 10/9/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
You are assuming the state of the DataFactory that is passed in when
loading
the xml.
XMLHelperptr xmlH = HelperProvider::getXMLHelper(); // returns "clean" XML
helper with virgin DataFactory
XMLDocumentPtr xmlD = xmlH->load("mySchemaless.xml"); // your fix would
make
this work BUT the DataFactory is now "frozen"
XMLDocumentPtr xmlD = xmlH->load("anotherSchemaless.xml"); // Bang! -
can't
add a new open type as DF is frozen
I would look at always defining an open type e.g. commonj/sdo#AnyOpenType
in
a DataFactory. When loading the schemaless xml you create one of these
then
create the DO's from the xml with this as the root (pseudo-root). The
XMLDocument returned would have the first DO defined from the xml as the
rootDataObject, not the pseudo-root.
Cheers,
On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
>
> That is still a separate issue from the one Sebastian raised.
>
> Sebastian specifically stated that he did not have an xsd and didn't
want
> one. Loading an XML instance without type information in that situation
> can
> be done, via a small xsd file immediately (as a workaround), and via
small
> code change soon. The issue of frozen type systems affects other things
> besides this one. It needs to be fixed, but it's still a separate
> question.
>
> Geoff.
>
> On 09/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > Well it depends on which DataFactory you are using during the loading
of
> > the
> > xml. I would usually create an XSDHelper and load a schema. I'd then
> > create
> > an XMLHelper using the DataFactory from the XSDHelper. I then load my
> xml.
> > If I now load a "schemaless" xml using that XMLHelper how do you
create
> > the
> > new Open Type?
> >
> > Cheers,
> >
> >
> > On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
> > >
> > > That's a different question.
> > >
> > > As I understand it, Sebastian (and others) were asking about loading
> an
> > > XML
> > > instance document without a corresponding xsd (or any other type
> > > information) and as above there is a way to do that and I can hack
it
> to
> > > make it a little easier.
> > >
> > > As you say, you cannot create any type at all after the first data
> > object
> > > is
> > > created. I'm looking into relaxing that too, but it is a separate
> issue
> > > from
> > > processing XML without a schema.
> > >
> > > Regards,
> > >
> > > Geoff.
> > >
> > > On 09/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Can you create an open type on the fly? Is the datafactory not
> > "locked"
> > > > once
> > > > the first DO is created?
> > > >
> > > > Cheers,
> > > >
> > > >
> > > > On 09/10/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Sebastian,
> > > > >
> > > > > I looked into this a bit more and it may not be as bad as it
> > appears.
> > > > >
> > > > > Currently, when the XML parser encounters an element for which
> there
> > > is
> > > > no
> > > > > type defined, it ignores that element and all of its content,
> > resuming
> > > > the
> > > > > parse once that unknown element has ended. The exception to this
> is
> > > when
> > > > > the
> > > > > element is a member of a parent that is defined to have open
> > content.
> > > In
> > > > > your example, the root element has no type definition and, of
> > course,
> > > it
> > > > > can't have a parent with open content, so it and all of its
> contents
> > > are
> > > > > ignored, which explains the output that you see.
> > > > >
> > > > > I can see one possible workaround and one possible fix for this.
> > > > >
> > > > > The workaround is that you provide an xsd that defines just the
> root
> > > > > element
> > > > > giving it open content. In your case that would be something
like
> > > > >
> > > > > http://www.w3.org/2001/XMLSchema";>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Then the root element has a type and will be processed normally,
> and
> > > > > everything it contains will be processed as open content. I
tried
> > this
> > > > and
> > > > > it seems to work.
> > > > >
> > > > > The fix would be for me to hack the code so that when we find
that
> a
> > > > root
> > > > > element has no corresponding type (or possibly when there are no
> > user
> > > > > defined types at all) then I could automagically create an open
> type
> > > for
> > > > > it.
> > > > > This would give the same behaviour as the previous case but
spare
> > you
> > > > the
> > > > > need to provide the .xsd
> > > > >
> > > > > I'm inclined to just go ahead and do that since its not
obviously
> > any
> > > > > worse
> > > > > than the current behaviour but I'm open to other ideas.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Geoff.
> > > > >
> > > > > On 07/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
> > > > > >
> > > > > > Well, I can load it, but it's desperately empty :)
> > > > > >
> > > > > > Given the following
Re: JIRA Permissions
Ant, Added you as an admin. -- dims On 10/9/06, ant elder <[EMAIL PROTECTED]> wrote: This comes up every time we add a new committer, looks like right now Jeremy is the only one able to do this, see: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg07691.html Dims, any chance I could be granted this power as well so we have someone in a different timezone to Jeremy who's able to do this? ...ant On 10/9/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Hi > > Can I assign JIRAs to myself and then update them futher as I work or > close > them ? How do I do that ? > > I had raised http://issues.apache.org/jira/browse/TUSCANY-809 releated to > updating license headers and want to close that now as I have committed > the > updates. > > Thanks > > - Venkat > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Permissions
Thanks dims. I've added you to tuscany now Venkat. ...ant On 10/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Ant, Added you as an admin. -- dims On 10/9/06, ant elder <[EMAIL PROTECTED]> wrote: > This comes up every time we add a new committer, looks like right now Jeremy > is the only one able to do this, see: > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg07691.html > > Dims, any chance I could be granted this power as well so we have someone in > a different timezone to Jeremy who's able to do this? > >...ant > > On 10/9/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > > Hi > > > > Can I assign JIRAs to myself and then update them futher as I work or > > close > > them ? How do I do that ? > > > > I had raised http://issues.apache.org/jira/browse/TUSCANY-809 releated to > > updating license headers and want to close that now as I have committed > > the > > updates. > > > > Thanks > > > > - Venkat > > > > > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Permissions
Thanks Ant. :) I hope to be troubling others a little less from now. - Venkat On 10/9/06, ant elder <[EMAIL PROTECTED]> wrote: Thanks dims. I've added you to tuscany now Venkat. ...ant On 10/9/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > Ant, > > Added you as an admin. > > -- dims > > On 10/9/06, ant elder <[EMAIL PROTECTED]> wrote: > > This comes up every time we add a new committer, looks like right now > Jeremy > > is the only one able to do this, see: > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg07691.html > > > > Dims, any chance I could be granted this power as well so we have > someone in > > a different timezone to Jeremy who's able to do this? > > > >...ant > > > > On 10/9/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > > > > Hi > > > > > > Can I assign JIRAs to myself and then update them futher as I work or > > > close > > > them ? How do I do that ? > > > > > > I had raised http://issues.apache.org/jira/browse/TUSCANY-809releated > to > > > updating license headers and want to close that now as I have > committed > > > the > > > updates. > > > > > > Thanks > > > > > > - Venkat > > > > > > > > > > > > > -- > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[JAVA SCA] Samples status?
Can someone do a quick update on the status of the samples? I'm trying to run the HelloWorldWS sample from SVN. I got the server working I believe but had to drag in the SDO Jars and the SDO binding Jar into the webapp - they weren't in the sample jar. Interesting thing about this was I got a NPE rather than a class not found when SDO was missing. A little confusing. I haven't got the client (I'm guessing HelloWorldWSClient) to work. I get a NPE when it tries to use the current context. It's difficult to know what jars are required for the client so I put all of the jars that appear in the HelloWorldWS lib dir on the classpath. Now looking at the dev list the samples are undergoing a reorg at the moment so I expect this is all a result of that. It that's the case I'll go a way for a bit and come back and try again when the reorg is done. Regards Simon
Re: Modeling persistence services, was Re: EJB3 (JPA) support
Hi guys, Special attention for Jim toward the end of this. There have been some branches in this email thread. Apologies if I don't inject at the right point in the chain, but much of the discussion is not related to the point I want to make. I need to react to something that's been discussed along the way. The notion that a property somehow represents a contract between the implementation and the container is quite a stretch IMHO. The real purpose of a property is to configure a business service so that the component behaves as the business would expect. I can see your perspective when viewed from the aspect of someone developing the runtime. It is certainly true that the container has responsibility for creating properties, BUT it has the exact same responsibility for injecting business services onto references. So, the argument you're making for using properties to hold references to system services holds on water. However, I do have sympathy with the idea that there are built-in services which SCA business component implementations can use. These built-in services live in a kind of "no man's land" right now. On one hand we have properties (which are defined by the both the Java spec spec and the assembly spec as described by XML schema) that are used to provide parameterization of business logic and we have business services that are assembled into compositions of SOA services. I agree with Jim that we should maintain a clear separation of purpose between property and reference. After thinking on this for a while, I've decided that the spec has correctly defined the property concept, therefore the use of property to hold references to "system services" is inappropriate and actually violates the spec. This comes across more harshly than I am intending. Jim, I think you need to raise this issue in the spec group, if you really think that properties should have the semantics you want. Despite the current lack of compliance language in the specs, I think it's still very clear where the boundaries of properties are. Dave Booz - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Tuesday, October 03, 2006 8:26 PM Subject: Re: Modeling persistence services, was Re: EJB3 (JPA) support On Oct 3, 2006, at 2:43 PM, Jeremy Boynes wrote: On Oct 3, 2006, at 1:41 PM, Jim Marino wrote: I like most types of cake too but I think we should really have one way of doing this. I've vacillated in the past on whether things such as DataSources, EntityManagers, etc. are modeled as services in an *application* assembly or are contracts a particular implementation may have with the container, i.e. a property. I believe they are the second. My understanding of DAS on the other hand is that it models data services which should be represented as services in an application assembly. So, if someone wants to model data access as a service then they should use DAS (which could, as an implementation strategy, use JPA or DAS for SQL data). I think there's a big difference between something like and Agreed, that's what I said previously although I see I had a typo at the end that may have confused things: DAS could use JPA or JDBC for SQL data access. I think is about simplifying the configuration of a complex component with a specific service interface (in this case EntityManager). SCA assembly allows you to do this and although it may seem odd, it is valid. We may suggest alternatives but in the end providing the freedom for users to choose is essential to our success. DAS on the other hand is about declarative definition of data access. Whereas in the case the service contract is fixed, DAS is about allowing the user to define data access in terms of a service design pattern. The application developer defines the service contract (as Java, WSDL, ...) with SCA supporting multiple implementations of that contract. Someone may choose an implementation based on JPA, JDO or some other programmatic technology, or they can choose an implementation based on DAS's declarative model. This sounds like having cake, eating it, and also being able to give it to a friend :-) We provide the flexibility for users: 1) to access infrastructure services through properties Yes for things like JPA, JDBC, etc. 2) to reference infrastructure services through inclusion in their assembly If we do 1 I don't think we should do 2 (that doesn't stop someone from extending Tuscany to do it though). See my comments below. 3) to access data through an application service with declarative implementation by DAS Yes, that's the value I see in DAS IMO users will want to do all of these and we should not do anything to stop them. Allowing people to do it and facilitating it are two separate things. We allow people to do it in that someone could come along an extend the runtime in (almost) any way they please. I don't think we should
Reminder. Request for Project Ideas for University Students
In mid-September I posted some material to the mailing list and Wiki regarding the possibility of M.Sc students at Oxford working on Tuscany as the project element of their course. I am also now talking to a University in France (Ecole des Mines de Nantes) about a similar proposal, although in the case of EMN, the project represents about 4 months of effort, compared to Oxford's 1 or 2. Various people suggested project titles, that are listed here http://wiki.apache.org/ws/Tuscany/CommunityBuilding, however, there isn't sufficient detail to allow me to sell the ideas, or an interested student to assess whether the subject is worth pursuing. If you are active in any of the areas listed, could you supply more detail, either on the Wiki page, or direct to me if that is easier. Thanks in advance.
TargetNotFoundException: Autowire target not found
Hi, While trying to invoke an axis2 based service from a test case, I get the following exception: org.apache.tuscany.spi.component.TargetNotFoundException: Autowire target not found [org.apache.tuscany.idl.wsdl.InterfaceWSDLIntrospector] at org.apache.tuscany.core.implementation.system.wire.SystemOutboundAutowire.getTargetService (SystemOutboundAutowire.java:86) at org.apache.tuscany.core.implementation.system.component.SystemWireObjectFactory.getInstance (SystemWireObjectFactory.java:40) at org.apache.tuscany.core.injection.MethodInjector.inject( MethodInjector.java:46) at org.apache.tuscany.core.implementation.PojoAtomicComponent.createInstance( PojoAtomicComponent.java:123) at org.apache.tuscany.core.component.scope.ModuleScopeContainer.eagerInitComponents (ModuleScopeContainer.java:144) at org.apache.tuscany.core.component.scope.ModuleScopeContainer.onEvent( ModuleScopeContainer.java:72) at org.apache.tuscany.spi.component.AbstractSCAObject.publish( AbstractSCAObject.java:94) at org.apache.tuscany.core.implementation.composite.AbstractCompositeComponent.publish (AbstractCompositeComponent.java:139) at org.apache.tuscany.core.implementation.composite.AbstractCompositeComponent.start (AbstractCompositeComponent.java:106) at org.apache.tuscany.test.SCATestCase.deployExtension(SCATestCase.java :110) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:59) I searched for InterfaceWSDLIntrospector, and found it inside idl/wsdl project. So included this in the path. Unfortunately the problem persists. Anybody knows how to fix this ? or any clue on how to proceed ? Thanks in advance, -- Warm regards, jojo.
Re: SCA Java samples for M2
Hi, So can we finalize on this and start moving the samples. While doing this can we also do the following: - - Go up to the wiki http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the samples section - If the sample is tried and includes a readme that explains how to go about setting it up and running it mark the sample as complete. - If there are issues related to the sample, please update the issues that are pending or being worked upon. Thoughts ? - Venkat On 10/8/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Yes Jim.. so that the pattern is clear to the user. i.e the user would see and feel in the samples at a particular level, only those features that exist at that level. For example a user could get a feel of individual extensions from the various samples, be able to digest them and then move out to the SCA level to get a feel of how the extensions could be combined. Then moving futher out to the base wherein the samples there demonstrate the roles of SCA, SDO and DAS in providing uniform service access, data proecessing and data access mechanism for SOA based applications. - Venkat On 10/8/06, Jim Marino <[EMAIL PROTECTED]> wrote: > > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: > > > Hi, > > > > I'd prefer to have business samples under 'samples' itself. I > > perceive that > > technology samples will go to the respective project directories > > and all > > others are to demonstrate the cool things of combining containers, > > transports - the integration story and they would all get under > > samples i.e. > > samples/BigBang, samples/SupplyChain .. and so on. > > > I want to check that we are saying the same thing. Here is what I > understand the proposed structuring to be: > > > samples/bingbank > > > > das/samples/companyweb > > > > sca/samples/calculator > > > > sca/services/containers/container.javascript/src/samples/ > > calculator > > To me this means: > > 1. Samples which are designed to illustrate multiple Tuscany sub- > projects (SCA/SDO/DAS) working together go under java/samples. These > are generally "applications" or as some people like to refer to them > "business samples" > > 2. Samples which are applications that are designed to illustrate one > Tuscany sub-project go under their respective sub-project samples > directory. For example, das/samples/companyweb or sca/samples/bigbank > for a version of BigBank that only uses SCA. > > 3. SCA samples that illustrate a particular Java SCA runtime > extension go in a samples folder under the extension, e.g. sca/ > services/containers/container.javascript/src/samples/calculator. SDO > and DAS may choose to follow a similar scheme if it makes sense for > those projects. > > Does that align with what you are saying? > > Jim > > > > - Venkat > > > > > > > > On 10/7/06, ant elder <[EMAIL PROTECTED]> wrote: > >> > >> I guess I was thinking that the technology type samples would be > >> the ones > >> that are now moved further down into the folder hierarchy so the only > >> thing > >> left up at the top would be the business samples so there wasn't > >> the need > >> for the two folders 'samples' and 'sampleapps' so sampleapps might > >> as well > >> just be renamed to samples to keep everything consistent. > >> > >> Please anyone say if they disagree with that. I'd also still like > >> to hear > >> comments or suggestions on all this from others who've expressed an > >> interest > >> in the samples in the past before I make the changes - Jim , > >> Rick, Simon? > >> > >>...ant > >> > >> On 10/6/06, Brent Daniel <[EMAIL PROTECTED]> wrote: > >> > > >> > Previously we had discussed having a "sampleapps" directory to > >> > distinguish "business samples" from technology samples.[1] Do we > >> want > >> > to continue this distinction? > >> > > >> > Brent > >> > > >> > > >> > [1] - > >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html > >> > > >> > On 10/6/06, ant elder < [EMAIL PROTECTED]> wrote: > >> > > Ok I think we're getting some agreement but I'd like to be clear > >> > everyone > >> > > agrees and is happy before I make any changes. Sounds like for > >> things > >> > like > >> > > the Groovy/JavaScript/etc helloworld and calculator type > >> samples they > >> > would > >> > > go with the extension, I'm guessing samples that use just sca > >> and java > >> > would > >> > > go in an sca/samples directory. Samples that use multiple > >> extensions > >> but > >> > > still just SCA would also go in the sca/samples directory, and > >> there'd > >> > be a > >> > > top level samples directory for things like bigbank that use > >> > sca/sdo/das. > >> > > > >> > > So: > >> > > > >> > > samples/bingbank > >> > > das/samples/companyweb > >> > > sca/samples/calculator > >> > > sca/services/containers/container.javascript/src/samples/ > >> calculator > >> > > > >> > > Comments? > >> > > > >> > > ...ant > >> > > > >> > > On 10/5/06, Jim Marino <[EMAIL PROTECTED] > wrote: > >> > >
Big Bank Failing - with weekend updates
Hello, BB was running on Friday. With this morning updates it's now failing to boot the webapp in TC. I'm trying to isolate, but not quite there yet. I think it's related to the maven artifact resolution put in. It maybe as simple as a missing jar. Unfortunately, it seems the exception on the server side are being lost even to the TC log making it a tad more difficult to isolate. Anyone familiar with this changes have any hints ? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
A final part of this is how the samples get built. One thing Jim wanted was for the samples to not get built with a regular build. If there's a (or some?) sample in sca/services/containers/container.javascript/src/samples/calculator how does that fit in with the maven build? ...ant On 10/9/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi, So can we finalize on this and start moving the samples. While doing this can we also do the following: - - Go up to the wiki http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the samples section - If the sample is tried and includes a readme that explains how to go about setting it up and running it mark the sample as complete. - If there are issues related to the sample, please update the issues that are pending or being worked upon. Thoughts ? - Venkat On 10/8/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Yes Jim.. so that the pattern is clear to the user. i.e the user would > see and feel in the samples at a particular level, only those features that > exist at that level. > > For example a user could get a feel of individual extensions from the > various samples, be able to digest them and then move out to the SCA level > to get a feel of how the extensions could be combined. Then moving futher > out to the base wherein the samples there demonstrate the roles of SCA, SDO > and DAS in providing uniform service access, data proecessing and data > access mechanism for SOA based applications. > > - Venkat > > On 10/8/06, Jim Marino < [EMAIL PROTECTED]> wrote: > > > > > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: > > > > > Hi, > > > > > > I'd prefer to have business samples under 'samples' itself. I > > > perceive that > > > technology samples will go to the respective project directories > > > and all > > > others are to demonstrate the cool things of combining containers, > > > transports - the integration story and they would all get under > > > samples i.e. > > > samples/BigBang, samples/SupplyChain .. and so on. > > > > > I want to check that we are saying the same thing. Here is what I > > understand the proposed structuring to be: > > > > > samples/bingbank > > > > > das/samples/companyweb > > > > > sca/samples/calculator > > > > > sca/services/containers/container.javascript/src/samples/ > > > calculator > > > > To me this means: > > > > 1. Samples which are designed to illustrate multiple Tuscany sub- > > projects (SCA/SDO/DAS) working together go under java/samples. These > > are generally "applications" or as some people like to refer to them > > "business samples" > > > > 2. Samples which are applications that are designed to illustrate one > > Tuscany sub-project go under their respective sub-project samples > > directory. For example, das/samples/companyweb or sca/samples/bigbank > > for a version of BigBank that only uses SCA. > > > > 3. SCA samples that illustrate a particular Java SCA runtime > > extension go in a samples folder under the extension, e.g. sca/ > > services/containers/container.javascript/src/samples/calculator. SDO > > and DAS may choose to follow a similar scheme if it makes sense for > > those projects. > > > > Does that align with what you are saying? > > > > Jim > > > > > > > - Venkat > > > > > > > > > > > > On 10/7/06, ant elder <[EMAIL PROTECTED]> wrote: > > >> > > >> I guess I was thinking that the technology type samples would be > > >> the ones > > >> that are now moved further down into the folder hierarchy so the only > > >> thing > > >> left up at the top would be the business samples so there wasn't > > >> the need > > >> for the two folders 'samples' and 'sampleapps' so sampleapps might > > >> as well > > >> just be renamed to samples to keep everything consistent. > > >> > > >> Please anyone say if they disagree with that. I'd also still like > > >> to hear > > >> comments or suggestions on all this from others who've expressed an > > >> interest > > >> in the samples in the past before I make the changes - Jim , > > >> Rick, Simon? > > >> > > >>...ant > > >> > > >> On 10/6/06, Brent Daniel <[EMAIL PROTECTED]> wrote: > > >> > > > >> > Previously we had discussed having a "sampleapps" directory to > > >> > distinguish "business samples" from technology samples.[1] Do we > > >> want > > >> > to continue this distinction? > > >> > > > >> > Brent > > >> > > > >> > > > >> > [1] - > > >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html > > >> > > > >> > On 10/6/06, ant elder < [EMAIL PROTECTED]> wrote: > > >> > > Ok I think we're getting some agreement but I'd like to be clear > > >> > everyone > > >> > > agrees and is happy before I make any changes. Sounds like for > > >> things > > >> > like > > >> > > the Groovy/JavaScript/etc helloworld and calculator type > > >> samples they > > >> > would > > >> > > go with the extension, I'm guessing samples that use just sca > > >> and java > > >> > would > > >> > > go in an sca/samples directory. Sampl
Re: Big Bank Failing - with weekend updates
Hi, I don't know if this is anyway related to your problem, but I also had a web app not working this morning. But for me it was evident that, the class "TuscanyContextListener" was missing. I guess it is renamed to (or replaced with ?) WebappRuntimeImpl. However the samples still referes to org.apache.tuscany.runtime.webapp.TuscanyContextListener. For exmple web.xmlin sample-helloworldws has the old reference. On 10/9/06, Rick <[EMAIL PROTECTED]> wrote: Hello, BB was running on Friday. With this morning updates it's now failing to boot the webapp in TC. I'm trying to isolate, but not quite there yet. I think it's related to the maven artifact resolution put in. It maybe as simple as a missing jar. Unfortunately, it seems the exception on the server side are being lost even to the TC log making it a tad more difficult to isolate. Anyone familiar with this changes have any hints ? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Warm regards, jojo.
Re: SCA Java samples for M2
What is the reasoning behind not wanting to build samples? You can always go in a subdir while developing and only re-build a particular extension or the core. I'm worried that this will lead the samples to go out of date. ant elder wrote: A final part of this is how the samples get built. One thing Jim wanted was for the samples to not get built with a regular build. If there's a (or some?) sample in sca/services/containers/container.javascript/src/samples/calculator how does that fit in with the maven build? ...ant On 10/9/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi, So can we finalize on this and start moving the samples. While doing this can we also do the following: - - Go up to the wiki http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the samples section - If the sample is tried and includes a readme that explains how to go about setting it up and running it mark the sample as complete. - If there are issues related to the sample, please update the issues that are pending or being worked upon. Thoughts ? - Venkat On 10/8/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Yes Jim.. so that the pattern is clear to the user. i.e the user would > see and feel in the samples at a particular level, only those features that > exist at that level. > > For example a user could get a feel of individual extensions from the > various samples, be able to digest them and then move out to the SCA level > to get a feel of how the extensions could be combined. Then moving futher > out to the base wherein the samples there demonstrate the roles of SCA, SDO > and DAS in providing uniform service access, data proecessing and data > access mechanism for SOA based applications. > > - Venkat > > On 10/8/06, Jim Marino < [EMAIL PROTECTED]> wrote: > > > > > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: > > > > > Hi, > > > > > > I'd prefer to have business samples under 'samples' itself. I > > > perceive that > > > technology samples will go to the respective project directories > > > and all > > > others are to demonstrate the cool things of combining containers, > > > transports - the integration story and they would all get under > > > samples i.e. > > > samples/BigBang, samples/SupplyChain .. and so on. > > > > > I want to check that we are saying the same thing. Here is what I > > understand the proposed structuring to be: > > > > > samples/bingbank > > > > > das/samples/companyweb > > > > > sca/samples/calculator > > > > > sca/services/containers/container.javascript/src/samples/ > > > calculator > > > > To me this means: > > > > 1. Samples which are designed to illustrate multiple Tuscany sub- > > projects (SCA/SDO/DAS) working together go under java/samples. These > > are generally "applications" or as some people like to refer to them > > "business samples" > > > > 2. Samples which are applications that are designed to illustrate one > > Tuscany sub-project go under their respective sub-project samples > > directory. For example, das/samples/companyweb or sca/samples/bigbank > > for a version of BigBank that only uses SCA. > > > > 3. SCA samples that illustrate a particular Java SCA runtime > > extension go in a samples folder under the extension, e.g. sca/ > > services/containers/container.javascript/src/samples/calculator. SDO > > and DAS may choose to follow a similar scheme if it makes sense for > > those projects. > > > > Does that align with what you are saying? > > > > Jim > > > > > > > - Venkat > > > > > > > > > > > > On 10/7/06, ant elder <[EMAIL PROTECTED]> wrote: > > >> > > >> I guess I was thinking that the technology type samples would be > > >> the ones > > >> that are now moved further down into the folder hierarchy so the only > > >> thing > > >> left up at the top would be the business samples so there wasn't > > >> the need > > >> for the two folders 'samples' and 'sampleapps' so sampleapps might > > >> as well > > >> just be renamed to samples to keep everything consistent. > > >> > > >> Please anyone say if they disagree with that. I'd also still like > > >> to hear > > >> comments or suggestions on all this from others who've expressed an > > >> interest > > >> in the samples in the past before I make the changes - Jim , > > >> Rick, Simon? > > >> > > >>...ant > > >> > > >> On 10/6/06, Brent Daniel <[EMAIL PROTECTED]> wrote: > > >> > > > >> > Previously we had discussed having a "sampleapps" directory to > > >> > distinguish "business samples" from technology samples.[1] Do we > > >> want > > >> > to continue this distinction? > > >> > > > >> > Brent > > >> > > > >> > > > >> > [1] - > > >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html > > >> > > > >> > On 10/6/06, ant elder < [EMAIL PROTECTED]> wrote: > > >> > > Ok I think we're getting some agreement but I'd like to be clear > > >> > everyone > > >> > > agrees and is happy before I make any changes. Sounds like for > > >> things > > >> > lik
Re: Big Bank Failing - with weekend updates
Hi Jojo, Not the issue in this case BB always included that for sometime now. Thanks. Jojo wrote: Hi, I don't know if this is anyway related to your problem, but I also had a web app not working this morning. But for me it was evident that, the class "TuscanyContextListener" was missing. I guess it is renamed to (or replaced with ?) WebappRuntimeImpl. However the samples still referes to org.apache.tuscany.runtime.webapp.TuscanyContextListener. For exmple web.xmlin sample-helloworldws has the old reference. On 10/9/06, Rick <[EMAIL PROTECTED]> wrote: Hello, BB was running on Friday. With this morning updates it's now failing to boot the webapp in TC. I'm trying to isolate, but not quite there yet. I think it's related to the maven artifact resolution put in. It maybe as simple as a missing jar. Unfortunately, it seems the exception on the server side are being lost even to the TC log making it a tad more difficult to isolate. Anyone familiar with this changes have any hints ? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. -- Jeremy On Oct 9, 2006, at 7:12 AM, Rick wrote: What is the reasoning behind not wanting to build samples? You can always go in a subdir while developing and only re-build a particular extension or the core. I'm worried that this will lead the samples to go out of date. ant elder wrote: A final part of this is how the samples get built. One thing Jim wanted was for the samples to not get built with a regular build. If there's a (or some?) sample in sca/services/containers/container.javascript/src/samples/ calculator how does that fit in with the maven build? ...ant On 10/9/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi, So can we finalize on this and start moving the samples. While doing this can we also do the following: - - Go up to the wiki http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the samples section - If the sample is tried and includes a readme that explains how to go about setting it up and running it mark the sample as complete. - If there are issues related to the sample, please update the issues that are pending or being worked upon. Thoughts ? - Venkat On 10/8/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Yes Jim.. so that the pattern is clear to the user. i.e the user would > see and feel in the samples at a particular level, only those features that > exist at that level. > > For example a user could get a feel of individual extensions from the > various samples, be able to digest them and then move out to the SCA level > to get a feel of how the extensions could be combined. Then moving futher > out to the base wherein the samples there demonstrate the roles of SCA, SDO > and DAS in providing uniform service access, data proecessing and data > access mechanism for SOA based applications. > > - Venkat > > On 10/8/06, Jim Marino < [EMAIL PROTECTED]> wrote: > > > > > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: > > > > > Hi, > > > > > > I'd prefer to have business samples under 'samples' itself. I > > > perceive that > > > technology samples will go to the respective project directories > > > and all > > > others are to demonstrate the cool things of combining containers, > > > transports - the integration story and they would all get under > > > samples i.e. > > > samples/BigBang, samples/SupplyChain .. and so on. > > > > > I want to check that we are saying the same thing. Here is what I > > understand the proposed structuring to be: > > > > > samples/bingbank > > > > > das/samples/companyweb > > > > > sca/samples/calculator > > > > > sca/services/containers/container.javascript/src/samples/ > > > calculator > > > > To me this means: > > > > 1. Samples which are designed to illustrate multiple Tuscany sub- > > projects (SCA/SDO/DAS) working together go under java/ samples. These > > are generally "applications" or as some people like to refer to them > > "business samples" > > > > 2. Samples which are applications that are designed to illustrate one > > Tuscany sub-project go under their respective sub-project samples > > directory. For example, das/samples/companyweb or sca/samples/ bigbank > > for a version of BigBank that only uses SCA. > > > > 3. SCA samples that illustrate a particular Java SCA runtime > > extension go in a samples folder under the extension, e.g. sca/ > > services/containers/container.javascript/src/samples/ calculator. SDO > > and DAS may choose to follow a similar scheme if it makes sense for > > those projects. > > > > Does that align with what you are saying? > > > > Jim > > > > > > > - Venkat > > > > > > > > > > > > On 10/7/06, ant elder <[EMAIL PROTECTED]> wrote: > > >> > > >> I guess I was thinking that the technology type samples would be > > >> the ones > > >> that are now moved further down into the folder hierarchy so the only > > >> thing > > >> left up at the top would be the business samples so there wasn't > > >> the need > > >> for the two folders 'samples' and 'sampleapps' so sampleapps might > > >> as well > > >> just be renamed to samples to keep everything consistent. > > >> > > >> Please anyone say if they disagree with that. I'd also still like > > >> to hear > > >> comments or suggestions on all this from others who've expressed an > > >> interest > > >> in the samples in the past before I make the changes - Jim , > > >> Rick, Simon? > > >> > > >>...ant > > >> > > >> On 10/6/06, Brent Daniel <[EMAIL PROTECTED]> wrote: > > >> > > > >> > Previ
Re: SCA Java samples for M2
I see value that we know they still build and we may have in the future some unit tests for these too. I agree the was is still lacking is an integration test - which does not run during normal build. Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. -- Jeremy On Oct 9, 2006, at 7:12 AM, Rick wrote: What is the reasoning behind not wanting to build samples? You can always go in a subdir while developing and only re-build a particular extension or the core. I'm worried that this will lead the samples to go out of date. ant elder wrote: A final part of this is how the samples get built. One thing Jim wanted was for the samples to not get built with a regular build. If there's a (or some?) sample in sca/services/containers/container.javascript/src/samples/calculator how does that fit in with the maven build? ...ant On 10/9/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi, So can we finalize on this and start moving the samples. While doing this can we also do the following: - - Go up to the wiki http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the samples section - If the sample is tried and includes a readme that explains how to go about setting it up and running it mark the sample as complete. - If there are issues related to the sample, please update the issues that are pending or being worked upon. Thoughts ? - Venkat On 10/8/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Yes Jim.. so that the pattern is clear to the user. i.e the user would > see and feel in the samples at a particular level, only those features that > exist at that level. > > For example a user could get a feel of individual extensions from the > various samples, be able to digest them and then move out to the SCA level > to get a feel of how the extensions could be combined. Then moving futher > out to the base wherein the samples there demonstrate the roles of SCA, SDO > and DAS in providing uniform service access, data proecessing and data > access mechanism for SOA based applications. > > - Venkat > > On 10/8/06, Jim Marino < [EMAIL PROTECTED]> wrote: > > > > > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: > > > > > Hi, > > > > > > I'd prefer to have business samples under 'samples' itself. I > > > perceive that > > > technology samples will go to the respective project directories > > > and all > > > others are to demonstrate the cool things of combining containers, > > > transports - the integration story and they would all get under > > > samples i.e. > > > samples/BigBang, samples/SupplyChain .. and so on. > > > > > I want to check that we are saying the same thing. Here is what I > > understand the proposed structuring to be: > > > > > samples/bingbank > > > > > das/samples/companyweb > > > > > sca/samples/calculator > > > > > sca/services/containers/container.javascript/src/samples/ > > > calculator > > > > To me this means: > > > > 1. Samples which are designed to illustrate multiple Tuscany sub- > > projects (SCA/SDO/DAS) working together go under java/samples. These > > are generally "applications" or as some people like to refer to them > > "business samples" > > > > 2. Samples which are applications that are designed to illustrate one > > Tuscany sub-project go under their respective sub-project samples > > directory. For example, das/samples/companyweb or sca/samples/bigbank > > for a version of BigBank that only uses SCA. > > > > 3. SCA samples that illustrate a particular Java SCA runtime > > extension go in a samples folder under the extension, e.g. sca/ > > services/containers/container.javascript/src/samples/calculator. SDO > > and DAS may choose to follow a similar scheme if it makes sense for > > those projects. > > > > Does that align with what you are saying? > > > > Jim > > > > > > > - Venkat > > > > > > > > > > > > On 10/7/06, ant elder <[EMAIL PROTECTED]> wrote: > > >> > > >> I guess I was thinking that the technology type samples would be > > >> the ones > > >> that are now moved further down into the folder hierarchy so the only > > >> thing > > >> left up at the top would be the business samples so there wasn't > > >> the need > > >> for the two folders 'samples' and 'sampleapps' so sampleapps might > > >> as well > > >> just be renamed to samples to keep everything consistent. > > >> > > >> Please anyone say if they disagree with that. I'd also still like > > >> to hear > > >> comments or suggestions on all this from others who've expressed an > > >> interest > > >> in the samples in the past be
Re: SCA Java samples for M2
At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SDO can't load an XML doc with no namespace
We'd be interested to make use of this feature in the PHP SDO project, too. I can see one possible workaround and one possible fix for this. The workaround is that you provide an xsd that defines just the root element giving it open content. In your case that would be something like http://www.w3.org/2001/XMLSchema";> Then the root element has a type and will be processed normally, and everything it contains will be processed as open content. I tried this and it seems to work. The fix would be for me to hack the code so that when we find that a root element has no corresponding type (or possibly when there are no user defined types at all) then I could automagically create an open type for it. This would give the same behaviour as the previous case but spare you the need to provide the .xsd I'm inclined to just go ahead and do that since its not obviously any worse than the current behaviour but I'm open to other ideas. Regards, Geoff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
I was pointing out the reasoning behind (which is what Rick asked) which should be fairly well known given the number of times we have had this particular discussion. IMO we need integration tests that pass. That would include testing the samples. Given the resources required to run real integration tests it is impractical to run them as part of a developer build. They should run on a ongoing basis, perhaps using a framework like Continuum. A plea to everyone - let's not rehash this all over again unless something has changed to make it a productive discussion. -- Jeremy On Oct 9, 2006, at 7:28 AM, Andy Piper wrote: At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. Simon Jeremy Boynes wrote: I was pointing out the reasoning behind (which is what Rick asked) which should be fairly well known given the number of times we have had this particular discussion. IMO we need integration tests that pass. That would include testing the samples. Given the resources required to run real integration tests it is impractical to run them as part of a developer build. They should run on a ongoing basis, perhaps using a framework like Continuum. A plea to everyone - let's not rehash this all over again unless something has changed to make it a productive discussion. -- Jeremy On Oct 9, 2006, at 7:28 AM, Andy Piper wrote: At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
I agree. Andy Piper wrote: At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
And where was I advocating that? I was *pointing out the reasoning* which was Rick's question so helpfully cut from this thread. Sorry for trying to be helpful, I'll shut up now. -- Jeremy On Oct 9, 2006, at 8:37 AM, Simon Nash wrote: I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. Simon Jeremy Boynes wrote: I was pointing out the reasoning behind (which is what Rick asked) which should be fairly well known given the number of times we have had this particular discussion. IMO we need integration tests that pass. That would include testing the samples. Given the resources required to run real integration tests it is impractical to run them as part of a developer build. They should run on a ongoing basis, perhaps using a framework like Continuum. A plea to everyone - let's not rehash this all over again unless something has changed to make it a productive discussion. -- Jeremy On Oct 9, 2006, at 7:28 AM, Andy Piper wrote: At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp- based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Jeremy, I understand the reasoning (thanks for restating it) and as I said, this is a good long term goal. The question had been raised (not by you) about whether or not the samples should continue to be built as part of the regular build, and I was responding to that discussion. Simon Jeremy Boynes wrote: And where was I advocating that? I was *pointing out the reasoning* which was Rick's question so helpfully cut from this thread. Sorry for trying to be helpful, I'll shut up now. -- Jeremy On Oct 9, 2006, at 8:37 AM, Simon Nash wrote: I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. Simon Jeremy Boynes wrote: I was pointing out the reasoning behind (which is what Rick asked) which should be fairly well known given the number of times we have had this particular discussion. IMO we need integration tests that pass. That would include testing the samples. Given the resources required to run real integration tests it is impractical to run them as part of a developer build. They should run on a ongoing basis, perhaps using a framework like Continuum. A plea to everyone - let's not rehash this all over again unless something has changed to make it a productive discussion. -- Jeremy On Oct 9, 2006, at 7:28 AM, Andy Piper wrote: At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp- based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-797) standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files
[ http://issues.apache.org/jira/browse/TUSCANY-797?page=comments#action_12440911 ] Simon Nash commented on TUSCANY-797: This change has resolved the problems that I was having and seeing. The zip and tar.gz files are both being built correctly now. This JIRA can now be closed. > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files > --- > > Key: TUSCANY-797 > URL: http://issues.apache.org/jira/browse/TUSCANY-797 > Project: Tuscany > Issue Type: Bug > Components: Build System, Java SCA Core >Affects Versions: Java-M2 > Environment: Windows XP SP2, Sun JDK 1.5.0_06-b5 >Reporter: Simon Nash > Assigned To: Jeremy Boynes > Fix For: Java-M2 > > > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing the following jar > files from its bin directory: >tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar >tuscany-api-1.0-incubator-M2-SNAPSHOT.jar > These jars are present in the bin directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz. > Without these jars, attempting to run the calculator sample produces the error > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/tuscany/host/RuntimeInfo > With these jars, the calculator sample runs OK > I checked the contents of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip and > standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz for other differences and I > found that the same 2 jars >tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar >tuscany-api-1.0-incubator-M2-SNAPSHOT.jar > are present in the boot directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz but not in the boot directory > of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip. > Having these jars missing from the boot directory does not impact successful > execution of the calculator sample. > It appears that the following actions are needed: > 1. Add these 2 jars to the bin directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip > 2. Determine whether or not these jars are also needed in the boot > directory. If so, add them to the boot directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip. If not, remove them from the > boot directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-797) standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files
[ http://issues.apache.org/jira/browse/TUSCANY-797?page=all ] Jeremy Boynes closed TUSCANY-797. - Assignee: (was: Jeremy Boynes) Thanks Simon > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files > --- > > Key: TUSCANY-797 > URL: http://issues.apache.org/jira/browse/TUSCANY-797 > Project: Tuscany > Issue Type: Bug > Components: Build System, Java SCA Core >Affects Versions: Java-M2 > Environment: Windows XP SP2, Sun JDK 1.5.0_06-b5 >Reporter: Simon Nash > Fix For: Java-M2 > > > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing the following jar > files from its bin directory: >tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar >tuscany-api-1.0-incubator-M2-SNAPSHOT.jar > These jars are present in the bin directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz. > Without these jars, attempting to run the calculator sample produces the error > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/tuscany/host/RuntimeInfo > With these jars, the calculator sample runs OK > I checked the contents of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip and > standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz for other differences and I > found that the same 2 jars >tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar >tuscany-api-1.0-incubator-M2-SNAPSHOT.jar > are present in the boot directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz but not in the boot directory > of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip. > Having these jars missing from the boot directory does not impact successful > execution of the calculator sample. > It appears that the following actions are needed: > 1. Add these 2 jars to the bin directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip > 2. Determine whether or not these jars are also needed in the boot > directory. If so, add them to the boot directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip. If not, remove them from the > boot directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strawman of revised SDO distribution
Hi Jeremy * getting the sdo-api doc in there would be tricker as that's outside the source tree. it may be possible to reference it, I think there's is it an absolute constraint that we have one shared Tuscany wide spec folder for all subprojects? Could I for instance have ... java/sdo java/sdo/spec ... ... java/sdo/implementation java/sdo/implementation/impl java/sdo/implementation/tools java/sdo/implementation/plugin java/sdo/implementation/sample I know you were reluctant to move the java/spec/sdo project into the java/sdo hierarchy in discussions we had a week or so ago when we moved the samples, but it would make my life much easier if I could aggregate spec and impl javadoc using a pom at the java/sdo level Regards, Kelvin. On 06/10/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: Re the javadoc, * including custom overview etc. is just configuration that can be played with (like you did with the samples) * getting the sdo-api doc in there would be tricker as that's outside the source tree. it may be possible to reference it, I think there's config for that (some form of external javadoc reference) * it may be possible to filter the source files that are included (e.g. to cut out impl details, sample source) I've not got any experience with that. Re the sample source - I included that to match what you have. It's easy to exclude by excluding the sample module. It would be fairly easy to add another assembly config that just included the sample source (which sounded like what Simon was suggesting). For that matter, you could also to that to package the javadoc separately. -- Jeremy On Oct 6, 2006, at 11:48 AM, kelvin goodson wrote: > Jeremy, > > that looks like a great improvement, thanks. After the full build > I see a > binary distro containing a javadoc folder as a peer of the lib > folder, and > it has merged javadoc for the all of the implementation projects. > (I need to > resolve the fact that there is a sample-sdo folder in there, on the > basis of > Simon Nash's comments on the RC2, but I think that's my problem.) > > So I have a few thoughts that you may have further ideas about. > > Let me tell you what I think the ideal situation is for javadoc in the > binary distribution, and where I hope we can get to with this > release. > Ideally the javadoc that a user finds in the binary distribution > documents > just the interfaces an SDO user is interested in, i.e. the SDO > API, + our > Tuscany specific extensions like SDOUtil, + our tooling, like > XSD2JavaGenerator. I didn't think I could get to that situation in > the time > available, so my plan is to get a merged javadoc that includes all > those > things, + a lot of stuff the user is not interested in, and then > provide > an overview.html that gets sucked in by the javadoc executable to > form part > of the top level index.html. This overview would provide links to the > things of interest to a user. So what you have provided is infinitely > better than what I had provided in RC2 (i.e. nothing), but if we > were able > to get the sdo-api javadoc in there too, and the process also > catered for > adding a hand crafted overview.html, as we have in the samples > project, > then that would be a great advance. > > Best Regards, Kelvin. > > On 06/10/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> >> On IRC Kelvin mentioned possibly re-jigging the SDO distribution >> format to include the assembly phase in the parent pom. The idea was >> that would make it easier to aggregate things like JavaDoc across the >> modules. >> >> I've taken a swag at this in my sandbox: >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/jboynes/ >> sdo >> >> This builds two ways: one to produce local artifacts, the other to >> produce a distribution. >> >> The first way is what we had before and allows you to build SDO as >> part of a larger reactor build (i.e. what we do when we build sdo, >> das and sca together). The default goal is "install" set by the >> reactor and that puts the binary jars in your local maven repo as >> usual. You can run this from the command line using "mvn package" or >> "mvn install" >> >> The second way does that, followed by a packaging step. That build >> aggregate javadoc across the modules (which is a slow step) and then >> builds the distribution bundles. This is intended to be run just to >> cut the release. You run this with "mvn package javadoc:javadoc >> assembly:assembly" and it: >> * builds and tests the jars as usual >> * generates javadoc aggregated across all the sdo modules >> * builds zip and tgz archives containing legal, jar files, the sample >> source and the javadoc - we can fine tune this as needed >> >> Kelvin, can you give this a go and see if it's what you want in the >> distro. >> Any other comments? Is this something we might want to do for DAS and >> SCA as well? >> >> -- >> Jeremy >> >> >> - >> To unsubscri
[jira] Created: (TUSCANY-810) JPA Support
JPA Support --- Key: TUSCANY-810 URL: http://issues.apache.org/jira/browse/TUSCANY-810 Project: Tuscany Issue Type: New Feature Affects Versions: Java-Mx Reporter: Meeraj Kunnumpurath Assigned To: Meeraj Kunnumpurath Fix For: Java-Mx Initial support for injecting @PersistenceContext and @PersistenceUnit annotations in implementation classes/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build failure in echo.databinding sample
Hi, Please see my comments inline below. Thanks, Raymond - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Saturday, October 07, 2006 1:14 PM Subject: Re: Build failure in echo.databinding sample I looked into this and the cause was the checkin I did to have DataType.equals() account for supertype compatibility (a problem I ran into yesterday doing something). I think we need to accommodate two aspects which are not completely captured today: 1. Service Contract compatibility at the logical level, which will vary depending on whether they are remote or local (the former do not support operation overloading, local services, the SCA default, do). Agree. 2. Whether a wire needs to have a physical mediation (datatypes, operations) based on the source and target side service contracts Yes. I also noticed it appears that mediation checks are performed at runtime (DataBindingInterceptor, the mediator service). Can't we do that at wire post-processing time and avoid these dynamic checks? I'll take a look. Probably we can fix it (at least optimize it) post M2. (As a separate issue, I believe this issue also highlights the need for integration level testing to catch these things) Agree. There's also a discussion on the mailing list on the intergation testing. Raymond (and others), what do you think? Jim On Oct 7, 2006, at 8:10 AM, Jeremy Boynes wrote: I'm seeing a build failure in the echo.databinding sample: testTransform(echo.DataBindingIntegrationTestCase) Time elapsed: 1.403 sec <<< ERROR! org.apache.tuscany.spi.wire.InvocationRuntimeException: java.lang.IllegalArgumentException: argument type mismatch at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke( DataBindingInteceptor.java:76) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke (AbstractOutboundInvocationHandler.java:60) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke (JDKOutboundInvocationHandler.java:121) at $Proxy20.call(Unknown Source) at echo.ComponentAImpl.call(ComponentAImpl.java:50) at echo.DataBindingIntegrationTestCase.testTransform (DataBindingIntegrationTestCase.java:34) This seems to have crept in between r453850 (which works for me) and r453900 (which doesn't) - I suspect r453857 may be causing this. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
On Oct 9, 2006, at 8:37 AM, Simon Nash wrote: I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. The samples are not part of the "regular" build, they are part of the root one. The root build should never have to be run for a checkin of Java SCA as it includes SDO and DAS, which we agreed should not be required by the former for modularity. I'm not going to rehash old ground but I will state that we need an integration test framework run as part of a continuous integration process that will include samples testing but goes well beyond that. In addition, the check-in build should contain test cases that verify basic things like bootstrapping (standalone, webapp); this can all be done using EasyMock without the need for code to execute in- container. The reason the samples are breaking is not because we don't run them as part of the build, it's because our basic test coverage is lacking. I propose we work to resolve this by the following: 1. Put testcases that verify bootstrapping in the checkin build. these should only use EasyMock and not run any containers (e.g. Jetty) 2. Move to a continuous integration framework, perhaps Continuum. These tests should - Run the samples in a number of container hosts we support (Tomcat, Jetty, Standalone, etc.) - Perform a deeper level of integration tests between various subsystems, such as wiring between component implementation types, interop testing, etc. - Be run periodically. We may eventually want to break them into parts. Some which run every 15 minutes or so, others (more resource intensive) which run around twice a day I'm willing to help out if there are some volunteers. Any volunteers? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-805) Document how to run standalone sca applications
[ http://issues.apache.org/jira/browse/TUSCANY-805?page=comments#action_12440918 ] Lee Surprenant commented on TUSCANY-805: I have created a very small howto and included it in a patch for Tuscany-780 (http://issues.apache.org/jira/browse/TUSCANY-780). > Document how to run standalone sca applications > --- > > Key: TUSCANY-805 > URL: http://issues.apache.org/jira/browse/TUSCANY-805 > Project: Tuscany > Issue Type: Improvement > Components: Website >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > > I was playing with SCA and could not find any documentation on how to use the > standalone distribution to run standalone applications that use SCA. This > JIRA is to produce some documentation and post on the website. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-805) Document how to run standalone sca applications
[ http://issues.apache.org/jira/browse/TUSCANY-805?page=comments#action_12440919 ] Simon Nash commented on TUSCANY-805: Lee Surprenant posted a patch for TUSCANY-780 that provided instructions for how to run the standalone calc sample. I have verified that these instructions work.. > Document how to run standalone sca applications > --- > > Key: TUSCANY-805 > URL: http://issues.apache.org/jira/browse/TUSCANY-805 > Project: Tuscany > Issue Type: Improvement > Components: Website >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > > I was playing with SCA and could not find any documentation on how to use the > standalone distribution to run standalone applications that use SCA. This > JIRA is to produce some documentation and post on the website. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build failure in echo.databinding sample
I also noticed it appears that mediation checks are performed at runtime (DataBindingInterceptor, the mediator service). Can't we do that at wire post-processing time and avoid these dynamic checks? I'll take a look. Probably we can fix it (at least optimize it) post M2. Yep sounds like the right thing to do. I commented some of the unit tests out but we have them to do development from when were are ready. (As a separate issue, I believe this issue also highlights the need for integration level testing to catch these things) Agree. There's also a discussion on the mailing list on the intergation testing. Yes, this type of thing would be a primary candidate for the itests. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-780) Numerous broken links at http://incubator.apache.org/tuscany/java-projects.html
[ http://issues.apache.org/jira/browse/TUSCANY-780?page=comments#action_12440921 ] Lee Surprenant commented on TUSCANY-780: Any reason this patch has not yet been applied? Could someone please apply or update this issue so that it is labelled with the Website component? > Numerous broken links at > http://incubator.apache.org/tuscany/java-projects.html > --- > > Key: TUSCANY-780 > URL: http://issues.apache.org/jira/browse/TUSCANY-780 > Project: Tuscany > Issue Type: Improvement >Affects Versions: Java-M2 >Reporter: Lee Surprenant > Fix For: Java-M2 > > Attachments: sitePatch.patch > > > There are a number of broken links at > http://incubator.apache.org/tuscany/java-projects.html including the internal > links in the opening "Tuscany JAVA Project" section, as well as an external > link to GettingStarted.htm in the "Running The Samples" section. Not sure if > we are waiting until M2 to update the site, but as a new user, these broken > links were very discouraging to me. In particular, the "GettingStarted.htm" > which results in a 404:Page not Found error was quite frustrating. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to handle some special files was Fwd: Files with license problems....
Luciano, I just deleted the ecore and genmodel files. These are old EMF artifacts left over from our original SDO model generation. Brent On 10/9/06, Luciano Resende <[EMAIL PROTECTED]> wrote: Some of the files reported by ARAT, at least on the DAS directory structure, are special files like derby phisical database for DAS Compnayweb sample, MDL files, ECORE files, GENMODEL files, etc How should these files be treated ? - Luciano -- Forwarded message -- From: Daniel Kulp <[EMAIL PROTECTED]> Date: Oct 8, 2006 10:54 AM Subject: Files with license problems To: tuscany-dev@ws.apache.org I've been playing around with the ARAT tool that a couple of the incubator folks are working on: http://code.google.com/p/arat/ It found a BUNCH of files that don't have the proper Apache license header stuck to them. We should start looking into them. (especially the one in buildtools if we re-vote to release) Note: a couple of the files have a BEA copyright and license header in them. One of the BEA folks needs to investigate what to do with those. Anyway, this tool would be run when anything we release gets to the iPMC vote. Thus, periodically running the tool and seeing what it says is a good thing. Enjoy! Dan trunk !? BUILDING.txt !? GettingStarted.htm trunk/buildtools/src/main/resources !? configuration_1_2.dtd !? suppressions_1_0.dtd trunk/das/rdb/src/main/resources !? dasmodel4.mdl trunk/das/rdb/src/main/resources/META-INF !? MANIFEST.MF trunk/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test !? ImpliedRelationshipTests.java trunk/das/rdb/src/test/resources !? company.ecore !? company.genmodel !? customer.ecore !? customer.genmodel trunk/das/samples/companyweb/dastest !? db.lck !? service.properties trunk/das/samples/companyweb/dastest/log !? log.ctrl !? logmirror.ctrl trunk/das/samples/companyweb/src/main/resources !? log4j.properties trunk/das/samples/testing/tomcat !? datasource.xsl trunk/etc !? replaceheaders.rb !? set_svn_properties.sh !? svn-ignores !? svn-props !? tuscany-eclipse-codestyle.xml !? tuscany-idea-codestyle.xml trunk/javadoc/css !? maven-base.css !? maven-classic.css !? maven-theme.css !? print.css trunk/sampleapps/bigbank/docs !? Show.Image.html trunk/samples/sca/calculator-ws/src/main/webapp !? index.html trunk/samples/sca/calculator-ws/src/main/webapp/WEB-INF !? web.xml trunk/samples/sca/eagerinit !? .ruleset !? run.bat trunk/samples/sca/echo.databinding/src/test/resources/wsdl !? echo.wsdl trunk/samples/sca/helloworld.rmiReference/src/main/resources !? HelloWorldImpl.componentType trunk/samples/sca/helloworld.rmiService/src/main/resources !? HelloWorldImpl.componentType trunk/samples/sca/helloworldJavaScript/src/main/resources !? HelloWorld.componentType !? HelloWorld.js trunk/samples/sca/helloworldws !? .ruleset !? setup.bat trunk/samples/sca/helloworldws-async !? .ruleset !? setup.bat trunk/samples/sca/helloworldws-celtix !? run.bat !? server.xml trunk/samples/sca/helloworldwsOM !? setup.bat trunk/samples/sca/helloworldwsclient !? run.bat !? run_celtix.bat trunk/samples/sca/helloworldwsclient-async !? run.bat !? run_celtix.bat trunk/samples/sca/helloworldwsclient-async/src/test/java/helloworld !? HelloWorldWSAsyncClient.java trunk/samples/sca/helloworldwsclientOM !? run.bat trunk/samples/sca/inner.composite/src/main/java/innercomposite !? InnerCompositeClient.java trunk/samples/sca/local.wire !? .ruleset trunk/samples/sca/local.wire.cdi !? .ruleset trunk/samples/sca/spring/client/src/main/java/sample !? TestBean.java !? TestComponent.java trunk/samples/sca/spring/client/src/main/webapp !? test.jsp trunk/samples/sca/spring/client/src/main/webapp/WEB-INF !? applicationContext.xml trunk/samples/sca/spring/client/src/main/webapp/WEB-INF/classes !? application-context.xml trunk/samples/sca/spring/server/src/main/java/sample !? TestBean.java !? TestComponent.java trunk/samples/sca/spring/server/src/main/webapp !? test.jsp trunk/samples/sca/spring/server/src/main/webapp/WEB-INF !? web.xml trunk/samples/sca/spring/server/src/main/webapp/WEB-INF/classes !? application-context.xml trunk/samples/sca/supplychain !? run.bat trunk/samples/sca/webapp/src/main/webapp !? index.html trunk/samples/sca/webapp/src/main/webapp/WEB-INF !? web.xml trunk/sca/doc !? extending.tuscany.ppt !? tuscany.architecture.ppt !? tuscany.architecture.v4.ppt trunk/sca/kernel/core/src/main/java/org/apache/tuscany/core/implementation/composite !? AbstractOperationOutboundInvocationHandler.java trunk/sca/kernel/core/src/test/java/org/apache/tuscany/core/implementation/composite !? CompositeReferenceCallbackTargetInvokerInvocationExceptionTestCase.java trunk/sca/kernel/core/src/test/java/org/apache/tuscany/core/
Re: Voting
Jeremy with a week or so more maven experience under my belt, and having revisited the parent and buildtools pom files I feel I am now sufficiently well informed on the maven technical side to +1 a vote if it were to be reinitiated. Best Regards, Kelvin. On 08/10/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: I was asked off-list why I would abandon the release vote when I had the necessary +1's. The answer is tied to the decision making process at the ASF. One of the benefits the ASF provides to its projects is that it is a corporation, an actual legal entity that can perform legally binding actions. This makes the Foundation legally responsible for those actions rather than the individuals themselves. If someone sues, for example for patent or copyright violation, then they would being suing the Foundation rather than the individual. IANAL so there may be exceptions but in general, this is a good thing for the contributors. For this to work, the Foundation must provide adequate oversight over its actions. It does this through delegation from the Board to the Vice-Presidents that Chair the various Project Management Committees. Executive actions are taken by the Chair based on decisions made by the PMC membership. These decisions are made by Vote of the PMC membership, subject to overrule by the PMC Chair and the Board. Releasing software is one of those legal actions. The Foundation is entering into a contract with the user in the form of the Apache License agreement. It is also entering into agreements with suppliers to that software - for example, it must comply with the redistribution provisions of any included software. The PMC Chair acts to release the software based on a vote of the PMC members with a +1 indicating that they support the release. For the PMC Chair to be able to respect that vote they must have confidence that the member had performed their duty of care - for example, that they had reviewed the software and did not know of any issue that affected the Foundation (such as containing third-party software that was not in compliance with Board policy). An Incubator Podling like us is not a recognized committee of the Foundation and to that extent the votes that we cast are not binding on the Foundation. To release the software that we produce we need action by the Chair of the Incubator PMC (IPMC) who will act based on the votes of IPMC members. The IPMC delegates responsibility for this to our community through an informal Podling PMC (PPMC) that in our case comprises all active committers. It is our responsibility to produce a release and vote as if we were on an actual PMC and were responsible for the decision. The outcome of that vote is evaluated by the IPMC members as part of their duty of care over the release; they also do their own review of the content to ensure that we did not miss anything. The more confidence they have in us having acted appropriately, the easier the IPMC vote. In this case, we had enough votes on the content to indicate that there had been review of the code and that it could be presented to the IPMC for a vote. However, during the course of the vote it became apparent that there was considerable confusion in the community about what we were voting on and why; that there were several people who were unclear on the technical aspects of the content or on the process that we would be following. I do not believe that someone can exercise due care when they are unclear on the matter under review and as such that would be sufficient to cause me to change my vote to a -1; as the vote initiator and Release Manager, it was enough uncertainty for me to consider the result inappropriate to present to the IPMC. Voting based on trust of someone else's review is something I consider OK if clearly stated (assuming enough people actually do a review to provide quorum), voting +1 just to get it out I view as questionable. I think the next step here is to clear up the confusion over the content and process so that all interested community members can vote clearly. If we think we are in that position now we can just vote again. However, based on comments this weekend and remaining abstentions I think there are still some issues to be cleared up first. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using Axis2 SOAPMonitor?
I am trying to use the SOAP Monitor in Axis2 as per http://ws.apache.org/axis2/1_0/soapmonitor-module.html However, I am not sure where to find the code needed for the last part of the recipe: Finally, compile the applet classes and place them at the root of the war - for example axis2/SOAPMonitorApplet*.class/WEB-INF : javac -classpath axis2-soapmonitor.jar SOAPMonitorApplet.java I have axis2-std-1.0-src.zip but the applet does not seem to be there. I changed the axis2.xml and web.xml (for the helloworldws-async sample) according to the instructions, but after deploying and starting tomcat, going to http://localhost:8080/sample-helloworldws-async-1.0-incubator-M2-SNAPSHOT/SOAPMonitor from a browser says that the service is not available. Has anyone tried this? .. . . .. . . . . . . . Ignacio Silva-Lepe [EMAIL PROTECTED] Phone: (914) 784 7003 Fax: (914) 784 6807
[jira] Updated: (TUSCANY-807) DAS Header Files Updates
[ http://issues.apache.org/jira/browse/TUSCANY-807?page=all ] Luciano Resende updated TUSCANY-807: Attachment: tuscany807.lresende.20061009.txt Header updates > DAS Header Files Updates > > > Key: TUSCANY-807 > URL: http://issues.apache.org/jira/browse/TUSCANY-807 > Project: Tuscany > Issue Type: Bug > Components: Java DAS RDB >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende >Priority: Critical > Fix For: Java-M2 > > Attachments: tuscany807.lresende.20061009.txt > > > As reported by Daniel Kulp, some DAS files are missing legal header >http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09256.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-808) DAS Samples Header files updates
[ http://issues.apache.org/jira/browse/TUSCANY-808?page=all ] Luciano Resende updated TUSCANY-808: Attachment: tuscany808.lresende.20061009.txt Header updates > DAS Samples Header files updates > > > Key: TUSCANY-808 > URL: http://issues.apache.org/jira/browse/TUSCANY-808 > Project: Tuscany > Issue Type: Bug > Components: Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende >Priority: Critical > Fix For: Java-M2 > > Attachments: tuscany808.lresende.20061009.txt > > > As reported by Daniel Kulp, some DAS files are missing legal header >http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09256.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-807) DAS Header Files Updates
[ http://issues.apache.org/jira/browse/TUSCANY-807?page=all ] Brent Daniel resolved TUSCANY-807. -- Resolution: Fixed > DAS Header Files Updates > > > Key: TUSCANY-807 > URL: http://issues.apache.org/jira/browse/TUSCANY-807 > Project: Tuscany > Issue Type: Bug > Components: Java DAS RDB >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende >Priority: Critical > Fix For: Java-M2 > > Attachments: tuscany807.lresende.20061009.txt > > > As reported by Daniel Kulp, some DAS files are missing legal header >http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09256.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-808) DAS Samples Header files updates
[ http://issues.apache.org/jira/browse/TUSCANY-808?page=all ] Brent Daniel resolved TUSCANY-808. -- Resolution: Fixed > DAS Samples Header files updates > > > Key: TUSCANY-808 > URL: http://issues.apache.org/jira/browse/TUSCANY-808 > Project: Tuscany > Issue Type: Bug > Components: Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende >Priority: Critical > Fix For: Java-M2 > > Attachments: tuscany808.lresende.20061009.txt > > > As reported by Daniel Kulp, some DAS files are missing legal header >http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09256.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring commonality amongst Script containers in Java SCA
On Oct 9, 2006, at 3:42 AM, ant elder wrote: On 10/7/06, Jim Marino <[EMAIL PROTECTED]> wrote: On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: > > On Oct 7, 2006, at 7:22 AM, ant elder wrote: > >> This is all working quite well now so i'd like to move it from my >> sandbox to >> be with the other containers. BSF 2.4 has just come out and the >> jar is >> available from a proper maven repo and the script container >> supports all the >> SCA things like references, properties and async, also the start of a >> website page describing it which I'll move to the site once its a >> bit more >> done: >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/doc/sca-java-container-script.xml >> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/ >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.easy/ >> > I'm fine with this as long as the name of "container.easy" can be > changed to something that denotes it has to do with scripting, > something like "container.bsf". > After looking at the code more instead of having something separate, why wouldn't we look to see if we can merge the "easy container" into the extension API? I'd like to get a clearer direction on this before we move things around. Specifically, I have a few questions related to this: 1. Is this container just for scripting? It appears not to be tied to scripting 2. What value does this container provide over the extension API? Does it automate certain coding tasks only relevant to a subset of containers or all containers? Could we just merge such automation with AtomicComponentExtension 3. There appears to be a bit of code duplication, some of which may be a vestige from the Groovy container which needs to be refactored. For example, AsyncInvoker. In a merge, maybe we could eliminate the need for this? Jim Way back I was moaning about the complexity of the SPI and it was suggested having a separate extension project for a simplified SPI for extensions with simpler requirements. Could you outline where you think core is too complex for "simple requirements"? I'd like to get an extension into core. What I specifically want to avoid is creating a parallel extension mechanism. I can't find a link, maybe the 1st sandbox phone call or an old IRC chat? Thats where this came from. Its not quite finished yet, there's some parts that could be simplified further. I'd also like to do the same thing for bindings but haven't got to that yet. This is not necessarily tied to only scripting containers but thats all we've tried it with so far, and as Venkat suggests there likely is a bit more work required to make it more generally useful. There probably are some parts that could be moved to existing SPI classes, but there are also parts that may be a bit inflexible to be made part of the general extension SPI. As you point out the async bit does seem pretty isolated so that probably could be easily moved out. Given we're trying to get an M2 release out real soon I'm not sure about messing with the existing SPI classes now. How about for now moving the obvious bits like async out but keeping the rest in say a separate container.helperproject or in a separate SPI package like org.apache.tuscany.spi.extension.container? What parts are you suggesting to move up? I definitely do not want to create another SPI package. Perhaps you could list the parts of the classes you would move into a helper library as well as the areas they are trying to simplify? This way we could decide whether the core spi can be simplified directly? To start with, I assume the following would not be included: - AsyncTargetInvoker - AsyncMonitor - EasyInstanceFactory since that can be done using an ObjectFactory Some specific questions I have are: - How are script scopes handled? I'm assuming we want to have the runtime manage statefull scripts, as we get that for free. - I also noticed the scope is set by default to Module. The default SCA Java is stateless. I agree module scope may be a better default but do you think we should be consistent with other SCA language specs here? - EasyComponentType encapsulates another ComponentType. I would have thought there would be an inheritance relationship. Was this because we need a specialization of ComponentType to be created by the generic side-file loader? If so, I think we should fix that in core. - More generally on component types, I haven't been following the PHP spec work but my understanding based on proposals from the people working on it to the assembly group is that the trend is to move away from having to author side-files and more towards code-level metadata and defaults. Would we want to emphasize that? Maybe you could ping Graham Charters who has been working on these issues? - Do scripts need to be defined by the Java idl or could I use WSDL or JSON
Re: SCA Java samples for M2
Not really part of this thread, but a question that came to mind because of it; would an integration test deploy and use Tomcat like we had before? If we ever got to using a continuum type build in apache would that be an issue ? Opening and sending through a socket at build/test time ? Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. -- Jeremy On Oct 9, 2006, at 7:12 AM, Rick wrote: What is the reasoning behind not wanting to build samples? You can always go in a subdir while developing and only re-build a particular extension or the core. I'm worried that this will lead the samples to go out of date. ant elder wrote: A final part of this is how the samples get built. One thing Jim wanted was for the samples to not get built with a regular build. If there's a (or some?) sample in sca/services/containers/container.javascript/src/samples/calculator how does that fit in with the maven build? ...ant On 10/9/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi, So can we finalize on this and start moving the samples. While doing this can we also do the following: - - Go up to the wiki http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the samples section - If the sample is tried and includes a readme that explains how to go about setting it up and running it mark the sample as complete. - If there are issues related to the sample, please update the issues that are pending or being worked upon. Thoughts ? - Venkat On 10/8/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Yes Jim.. so that the pattern is clear to the user. i.e the user would > see and feel in the samples at a particular level, only those features that > exist at that level. > > For example a user could get a feel of individual extensions from the > various samples, be able to digest them and then move out to the SCA level > to get a feel of how the extensions could be combined. Then moving futher > out to the base wherein the samples there demonstrate the roles of SCA, SDO > and DAS in providing uniform service access, data proecessing and data > access mechanism for SOA based applications. > > - Venkat > > On 10/8/06, Jim Marino < [EMAIL PROTECTED]> wrote: > > > > > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: > > > > > Hi, > > > > > > I'd prefer to have business samples under 'samples' itself. I > > > perceive that > > > technology samples will go to the respective project directories > > > and all > > > others are to demonstrate the cool things of combining containers, > > > transports - the integration story and they would all get under > > > samples i.e. > > > samples/BigBang, samples/SupplyChain .. and so on. > > > > > I want to check that we are saying the same thing. Here is what I > > understand the proposed structuring to be: > > > > > samples/bingbank > > > > > das/samples/companyweb > > > > > sca/samples/calculator > > > > > sca/services/containers/container.javascript/src/samples/ > > > calculator > > > > To me this means: > > > > 1. Samples which are designed to illustrate multiple Tuscany sub- > > projects (SCA/SDO/DAS) working together go under java/samples. These > > are generally "applications" or as some people like to refer to them > > "business samples" > > > > 2. Samples which are applications that are designed to illustrate one > > Tuscany sub-project go under their respective sub-project samples > > directory. For example, das/samples/companyweb or sca/samples/bigbank > > for a version of BigBank that only uses SCA. > > > > 3. SCA samples that illustrate a particular Java SCA runtime > > extension go in a samples folder under the extension, e.g. sca/ > > services/containers/container.javascript/src/samples/calculator. SDO > > and DAS may choose to follow a similar scheme if it makes sense for > > those projects. > > > > Does that align with what you are saying? > > > > Jim > > > > > > > - Venkat > > > > > > > > > > > > On 10/7/06, ant elder <[EMAIL PROTECTED]> wrote: > > >> > > >> I guess I was thinking that the technology type samples would be > > >> the ones > > >> that are now moved further down into the folder hierarchy so the only > > >> thing > > >> left up at the top would be the business samples so there wasn't > > >> the need > > >> for the two folders 'samples' and 'sampleapps' so sampleapps might > > >> as well > > >> just be renamed to samples to keep everything consistent. > > >> > > >> Please anyone say if they disagree with that. I'd also still like > > >> to hear > > >> comments or suggestions on all thi
Re: SDO for Java M2 RC2 posted
Two quick question around SDO source distribution - Should the source distribution have a NOTICE and LICENSE file on the root of the distribution, looks like you only have the ones exported from the distribution project. Or should the source distribution be a clean export from svn ? - Should the distribution project be available on the source distribution ? - Should STATUS be checked in in the sdo subtree ? - Luciano On 10/5/06, kelvin goodson <[EMAIL PROTECTED]> wrote: I have made available an RC2 release candidate for SDO for Java at http://people.apache.org/~kelvingoodson/sdo_java/RC2/ The main differences from RC1a are Tuscany JIRAs 115 and 755 are fixed The source distribution has been split (re-split) into specification and implementation archives after discussion on the tuscany-dev mailing list The samples are distributed as a separate standalone archive containing sample source code, java doc and all required binary artifacts. The EMF dependency jar is now the non-snapshot 2.2.1 version. Best Regards, Kelvin.
Setting up Eclipse 3.2 for Tuscany projects
I'm looking for information on how to best fully setup Eclipse for Tuscany Development.Some Issues that come to mind are: How to Create a Tomcat Server that uses the Tuscany built-in apachee server, JDK, and Tuscany Libraries How to Set up the Buildtime environment of Eclipse use Tuscany Libraries. Is it necessary? Are there any special considerations for SCA.or SDO.or DAS in terms of buildtime or runtime envs while using Eclipse How to set up the Project Settings for projects that will do SCA, SDO, DAS development Building, Running, Debugging both inside the Eclipse env and outside for "remotely" debugging. (Remote Tomcat doesn't seem to hit break points in Eclipse) How to run the "manager" and "admin" while using Eclipse with Tomcat. If there is already some documentation on how to fully integration Eclipse with Tuscany and Tomcat for build, deploy, run, test, debug, then please send the documentation or links to the documentation. Thanks, Terry
[C++] M2 RC1 status
Hi all, Just a quick one to find out where we are with items for C++ M2 RC1. From recent commits I think the status is: SDO - Stdcxx as a build option on Linux and Windows - done, aside from Linux support, probably not going to include Linux support - Support for an identified level of the SDO spec (2.01) - readme updated, but needs checking SCA - CPP, WS, Python, Ruby builds in source & binary release - Linux: done. Windows: CPP & WS done, Python & Ruby to do - Support for an identified level of the SCA assembly (0.96) and C++ C&I specs (0.95) - readme updated, but needs checking & adding to. Samples - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - documentation & deploy scripts done, Calculator windows build script done, BigBank windows build script to do. Docs - How to build SDO (with or without stdcxx) and SCA - done - How to deploy WS service/module to Axis2C - done - How to build/run the samples for SDO/SCA - done - Describe the new SCA language extensions progamming models - done - Release notes - updated, needs checking/adding to (see above) - How to turn existing C and/or C++ code into an SCA component - updated the "How to create a C++ component" doc - is this sufficient? Deployment - Simplify and open our tuscany-root folder structure to allow people to choose the structure that best fits their environment - done Release Requirements - Update Licence text in source files to the new Apache wording - done Does that look about right to people? Any other updates? Anything else to go in? Cheers! Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Integration test environment: SCA Java samples for M2
On Oct 9, 2006, at 12:52 PM, Rick wrote: Not really part of this thread, but a question that came to mind because of it; would an integration test deploy and use Tomcat like we had before? If we ever got to using a continuum type build in apache would that be an issue ? Opening and sending through a socket at build/test time ? I think doing that kind of thing would be an important part of an integration test environment. For example, we would want to deploy webapps not only to Tomcat but also Geronimo, Jetty, GlassFish, JBoss, WebLogic, WebSphere, etc. We'd also want to get integration between e.g. Tuscany and raw Axis2 or Geronimo with J2EE1.4 webservices or between the Java, C++, PHP, etc variations of Tuscany. That's one big reason why I think this needs to be separate from the developer build. Not everyone is going to be able to install all those environments, or run the suite in an environment where they all work (think about trying to do development on an airplane). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting up Eclipse 3.2 for Tuscany projects
Comments inline Please let me know if you have further questions On 10/9/06, Terry Heath <[EMAIL PROTECTED]> wrote: I'm looking for information on how to best fully setup Eclipse for Tuscany Development.Some Issues that come to mind are: How to Create a Tomcat Server that uses the Tuscany built-in apachee server, JDK, and Tuscany Libraries I might be little confused with your question, Tuscany does not have a built-in apache server, basically, you can run applications that use Tuscany in any application server. An example is DAS company web application (das/samples/companyweb), that is going to create a WAR file with all dependencies in the WEB-INF\lib directory and you would be able to deploy it in any J2EE app server (probably would only have to setup the datasources there) I think this would also hold true for SDO, meaning that, providing you have put the necessary dependencies inside your application WEB-INF\lib directory you should be all set... please SDO guys, correct me if I'm wrong.. As for SCA, it's little more complicated, but the guys have created a plugin that will put the right artifacts in the right place in your web-app, so, if you start from a tuscany sca sample, you should have a complete WAR file with all dependencies needed... Examples of tuscany applications running in tomcat : das/samples/companyweb sampleapps/bigbank How to Set up the Buildtime environment of Eclipse use Tuscany Libraries. Is it necessary? You could start from : http://incubator.apache.org/tuscany/java-projects.html DAS specific steps here : http://incubator.apache.org/tuscany/java_das_overview.html SDO specific steps here : http://incubator.apache.org/tuscany/java_sdo_overview.html Are there any special considerations for SCA.or SDO.or DAS in terms of buildtime or runtime envs while using Eclipse After you have setup you environment, you can use maven to create eclipse projects mvn -Peclipse eclipse:eclipse or to clean eclipse projects mvn -Peclipse eclipse:clean Once that is done, go into eclipse and import existing projects into workspace... How to set up the Project Settings for projects that will do SCA, SDO, DAS development Hope the steps above will answer this... Building, Running, Debugging both inside the Eclipse env and outside for "remotely" debugging. (Remote Tomcat doesn't seem to hit break points in Eclipse) I always used eclipse and never had big issues.. For remote debugging, there are some instructions at the end of the followig page http://wiki.apache.org/ws/Tuscany/TuscanyJava/SCA_Java How to run the "manager" and "admin" while using Eclipse with Tomcat. Not sure... here... If there is already some documentation on how to fully integration Eclipse with Tuscany and Tomcat for build, deploy, run, test, debug, then please send the documentation or links to the documentation. deploying to tomcat from command line mvn tomcat:deploy Thanks, Terry
Re: Big Bank Failing - with weekend updates
Using CATALINA_BASE: E:\dev\tuscany\java\sampleapps\bigbank\test\apache-tomcat-5.5.17 Using CATALINA_HOME: E:\dev\tuscany\java\sampleapps\bigbank\test\apache-tomcat-5.5.17 Using CATALINA_TMPDIR: E:\dev\tuscany\java\sampleapps\bigbank\test\apache-tomcat-5.5.17\temp Using JRE_HOME:E:\bin\java\jdk1.5.0_09 Listening for transport dt_socket at address: 3720 log4j:WARN No appenders could be found for logger (org.apache.commons.digester.Digester). log4j:WARN Please initialize the log4j system properly. [INFO] snapshot org.apache.ws.commons:XmlSchema:SNAPSHOT: checking for updates from http://repo1.maven.org/maven2/ org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to store local copy of metadata: Error updating group repository metadata org.apache.ws.commons:XmlSchema:jar:SNAPSHOT at org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:65) at org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForResolve(DefaultArtifactTransformationManager.java:40) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:104) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.tuscany.services.maven.MavenHelper.resolve(MavenHelper.java:199) at org.apache.tuscany.services.maven.MavenHelper.resolveTransitively(MavenHelper.java:177) at org.apache.tuscany.services.maven.MavenArtifactRepository.resolve(MavenArtifactRepository.java:69) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:97) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:53) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:109) at org.apache.tuscany.core.loader.IncludeLoader.loadFromSidefile(IncludeLoader.java:106) at org.apache.tuscany.core.loader.IncludeLoader.load(IncludeLoader.java:93) at org.apache.tuscany.core.loader.IncludeLoader.load(IncludeLoader.java:48) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:79) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:53) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:109) at org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.loadFromSidefile(SystemCompositeComponentTypeLoader.java:68) at org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:59) at org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159) at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76) at org.apache.tuscany.core.services.extension.AbstractExtensionDeployer.deployExtension(AbstractExtensionDeployer.java:101) at org.apache.tuscany.runtime.webapp.WebResourceScanExtender.init(WebResourceScanExtender.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.core.injection.MethodEventInvoker.invokeEvent(MethodEventInvoker.java:42) at org.apache.tuscany.core.implementation.PojoAtomicComponent.init(PojoAtomicComponent.java:94) at org.apache.tuscany.core.component.scope.InstanceWrapperImpl.start(InstanceWrapperImpl.java:49) at org.apache.tuscany.core.component.scope.ModuleScopeContainer.eagerInitComponents(ModuleScopeContainer.java:145) at org.apache.tuscany.core.component.scope.ModuleScopeContainer.onEvent(ModuleScopeContainer.java:72) at org.apache.tuscany.spi.component.AbstractSCAObject.publish(AbstractSCAObject.java:94) at org.apache.tuscany.core.implementation.composite.AbstractCompositeComponent.publish(AbstractCompositeComponent.java:139) at org.apache.tuscany.core.implementation.composite.AbstractCompositeComponent.start(AbstractCompositeComponent.java:106) at org.apache.tuscany.runtime.webapp.WebappRuntimeImpl.initialize(WebappRuntimeImpl.java:127) at org.apache.tusca
Re: Setting up Eclipse 3.2 for Tuscany projects
One other scenario I forgot... If you are using the Web Tools Platform distribution, you could create a Web Project and provided the necessary dependencies in WEB-INF\Lib (at least for DAS and SDO apps) and that would give you a different user experience, where you can get a better tomcat integration from inside eclipse. Not sure what the store would be here for the SCA dependencies artifacts, as they use a different directory structure. - Luciano On 10/9/06, Luciano Resende <[EMAIL PROTECTED]> wrote: Comments inline Please let me know if you have further questions On 10/9/06, Terry Heath <[EMAIL PROTECTED] > wrote: > > I'm looking for information on how to best fully setup Eclipse for > Tuscany > Development.Some Issues that come to mind are: > > How to Create a Tomcat Server that uses the Tuscany built-in apachee > server, JDK, and Tuscany Libraries I might be little confused with your question, Tuscany does not have a built-in apache server, basically, you can run applications that use Tuscany in any application server. An example is DAS company web application (das/samples/companyweb), that is going to create a WAR file with all dependencies in the WEB-INF\lib directory and you would be able to deploy it in any J2EE app server (probably would only have to setup the datasources there) I think this would also hold true for SDO, meaning that, providing you have put the necessary dependencies inside your application WEB-INF\lib directory you should be all set... please SDO guys, correct me if I'm wrong.. As for SCA, it's little more complicated, but the guys have created a plugin that will put the right artifacts in the right place in your web-app, so, if you start from a tuscany sca sample, you should have a complete WAR file with all dependencies needed... Examples of tuscany applications running in tomcat : das/samples/companyweb sampleapps/bigbank How to Set up the Buildtime environment of Eclipse use Tuscany Libraries. > Is it necessary? You could start from : http://incubator.apache.org/tuscany/java-projects.html DAS specific steps here : http://incubator.apache.org/tuscany/java_das_overview.html SDO specific steps here : http://incubator.apache.org/tuscany/java_sdo_overview.html Are there any special considerations for SCA.or SDO.or DAS in > terms of buildtime or runtime envs while using Eclipse After you have setup you environment, you can use maven to create eclipse projects mvn -Peclipse eclipse:eclipse or to clean eclipse projects mvn -Peclipse eclipse:clean Once that is done, go into eclipse and import existing projects into workspace... How to set up the Project Settings for projects that will do SCA, SDO, DAS > development Hope the steps above will answer this... Building, Running, Debugging both inside the Eclipse env and outside > for "remotely" debugging. (Remote Tomcat doesn't seem to hit break > points > in Eclipse) I always used eclipse and never had big issues.. For remote debugging, there are some instructions at the end of the followig page http://wiki.apache.org/ws/Tuscany/TuscanyJava/SCA_Java How to run the "manager" and "admin" while using Eclipse with Tomcat. Not sure... here... If there is already some documentation on how to fully integration Eclipse > > with Tuscany and Tomcat for build, deploy, run, test, debug, then please > send the documentation or links to the documentation. deploying to tomcat from command line mvn tomcat:deploy Thanks, > Terry >
[jira] Created: (TUSCANY-811) README.txt and LICENSE.txt from Companyweb WAR\META-INF need updates
README.txt and LICENSE.txt from Companyweb WAR\META-INF need updates Key: TUSCANY-811 URL: http://issues.apache.org/jira/browse/TUSCANY-811 Project: Tuscany Issue Type: Bug Components: Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Fix For: Java-M2 Obsolet README.txt with information from M1 release need updates LICENSE.txt need updates -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-811) README.txt and LICENSE.txt from Companyweb WAR\META-INF need updates
[ http://issues.apache.org/jira/browse/TUSCANY-811?page=all ] Luciano Resende updated TUSCANY-811: Attachment: tuscany811.lresende.20061009.txt Necessary updates to license, readme and notice files. > README.txt and LICENSE.txt from Companyweb WAR\META-INF need updates > > > Key: TUSCANY-811 > URL: http://issues.apache.org/jira/browse/TUSCANY-811 > Project: Tuscany > Issue Type: Bug > Components: Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany811.lresende.20061009.txt > > > Obsolet README.txt with information from M1 release need updates > LICENSE.txt need updates -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-812) CompanyWeb readme.html needs update
CompanyWeb readme.html needs update --- Key: TUSCANY-812 URL: http://issues.apache.org/jira/browse/TUSCANY-812 Project: Tuscany Issue Type: Bug Components: Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Fix For: Java-M2 CompanyWeb readme.html still talks about the scenario available during M1. For M2, we have simplified the usage of the companyweb app by making deployment easier and adding dependencies inside the app war itself. We have also removed some deployment scenarios. The readme.html needs to be updated to reflect these changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-812) CompanyWeb readme.html needs update
[ http://issues.apache.org/jira/browse/TUSCANY-812?page=all ] Luciano Resende updated TUSCANY-812: Attachment: tuscany812.lresende.20061009.txt Necessary updates for companyweb readme.htm > CompanyWeb readme.html needs update > --- > > Key: TUSCANY-812 > URL: http://issues.apache.org/jira/browse/TUSCANY-812 > Project: Tuscany > Issue Type: Bug > Components: Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany812.lresende.20061009.txt > > > CompanyWeb readme.html still talks about the scenario available during M1. > For M2, we have simplified the usage of the companyweb app by making > deployment easier and adding dependencies inside the app war itself. We have > also removed some deployment scenarios. The readme.html needs to be updated > to reflect these changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-769) Improve DAS distribution to include any provided legal text file into the distribution
[ http://issues.apache.org/jira/browse/TUSCANY-769?page=all ] Luciano Resende resolved TUSCANY-769. - Resolution: Fixed Thanks for applying the patch. > Improve DAS distribution to include any provided legal text file into the > distribution > -- > > Key: TUSCANY-769 > URL: http://issues.apache.org/jira/browse/TUSCANY-769 > Project: Tuscany > Issue Type: Improvement > Components: Java DAS RDB, Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany769.lresende.20060930.txt > > > Currently DAS distribution only look for LICENSE and NOTICE text files. > I want to update the distribution assembly to get any provided text files > into the distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-813) Improve DAS distribution to include any provided html (e.g readme.html) into the distribution
Improve DAS distribution to include any provided html (e.g readme.html) into the distribution - Key: TUSCANY-813 URL: http://issues.apache.org/jira/browse/TUSCANY-813 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB, Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Fix For: Java-M2 As per comments to RC1, we want to be able to include readme.htm to das sample distribution : http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00255.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-813) Improve DAS distribution to include any provided html (e.g readme.html) into the distribution
[ http://issues.apache.org/jira/browse/TUSCANY-813?page=all ] Luciano Resende updated TUSCANY-813: Attachment: tuscany813.lresende.20061009.txt Update distribution assemblies to include htm and html files provided > Improve DAS distribution to include any provided html (e.g readme.html) into > the distribution > - > > Key: TUSCANY-813 > URL: http://issues.apache.org/jira/browse/TUSCANY-813 > Project: Tuscany > Issue Type: Improvement > Components: Java DAS RDB, Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany813.lresende.20061009.txt > > > As per comments to RC1, we want to be able to include readme.htm to das > sample distribution : > http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00255.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-813) Improve DAS distribution to include any provided html (e.g readme.html) into the distribution
[ http://issues.apache.org/jira/browse/TUSCANY-813?page=all ] Luciano Resende reassigned TUSCANY-813: --- Assignee: Luciano Resende > Improve DAS distribution to include any provided html (e.g readme.html) into > the distribution > - > > Key: TUSCANY-813 > URL: http://issues.apache.org/jira/browse/TUSCANY-813 > Project: Tuscany > Issue Type: Improvement > Components: Java DAS RDB, Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany813.lresende.20061009.txt > > > As per comments to RC1, we want to be able to include readme.htm to das > sample distribution : > http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00255.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-564) Tomcat test integration POM points to BEA jar file download
[ http://issues.apache.org/jira/browse/TUSCANY-564?page=all ] Luciano Resende resolved TUSCANY-564. - Fix Version/s: Java-M2 Resolution: Fixed Thanks for applaying the patch > Tomcat test integration POM points to BEA jar file download > --- > > Key: TUSCANY-564 > URL: http://issues.apache.org/jira/browse/TUSCANY-564 > Project: Tuscany > Issue Type: Bug > Components: Java DAS Samples >Affects Versions: Java-M1, Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany-564.lresende.20061006.txt > > > I was trying to run java/testing/tomcat/bigbank > When you don't have jsr173 dependency available, you will get the following > from the mvn command line >Missing: > -- > 1) javax.xml:jsr173:jar:1.0 > Try downloading the file manually from: > http://ftpna2.bea.com/pub/downloads/jsr173.jar >Then, install it using the command: > mvn install:install-file -DgroupId=javax.xml -DartifactId=jsr173 > -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file > After some investigation, I found out that the > /java/testing/tomcat/readme.htm file have instructions on how to download > this dependency from XML Bean Distribution. > Jeremy also pointed that we could exclude this one and use stax-api > dependency already available for other parts of the project. > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05206.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-813) Improve DAS distribution to include any provided html (e.g readme.html) into the distribution
[ http://issues.apache.org/jira/browse/TUSCANY-813?page=all ] Kevin Williams resolved TUSCANY-813. Resolution: Fixed > Improve DAS distribution to include any provided html (e.g readme.html) into > the distribution > - > > Key: TUSCANY-813 > URL: http://issues.apache.org/jira/browse/TUSCANY-813 > Project: Tuscany > Issue Type: Improvement > Components: Java DAS RDB, Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany813.lresende.20061009.txt > > > As per comments to RC1, we want to be able to include readme.htm to das > sample distribution : > http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00255.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-811) README.txt and LICENSE.txt from Companyweb WAR\META-INF need updates
[ http://issues.apache.org/jira/browse/TUSCANY-811?page=all ] Kevin Williams resolved TUSCANY-811. Resolution: Fixed > README.txt and LICENSE.txt from Companyweb WAR\META-INF need updates > > > Key: TUSCANY-811 > URL: http://issues.apache.org/jira/browse/TUSCANY-811 > Project: Tuscany > Issue Type: Bug > Components: Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany811.lresende.20061009.txt > > > Obsolet README.txt with information from M1 release need updates > LICENSE.txt need updates -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-812) CompanyWeb readme.html needs update
[ http://issues.apache.org/jira/browse/TUSCANY-812?page=all ] Kevin Williams resolved TUSCANY-812. Resolution: Fixed > CompanyWeb readme.html needs update > --- > > Key: TUSCANY-812 > URL: http://issues.apache.org/jira/browse/TUSCANY-812 > Project: Tuscany > Issue Type: Bug > Components: Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany812.lresende.20061009.txt > > > CompanyWeb readme.html still talks about the scenario available during M1. > For M2, we have simplified the usage of the companyweb app by making > deployment easier and adding dependencies inside the app war itself. We have > also removed some deployment scenarios. The readme.html needs to be updated > to reflect these changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-815) Update DAS Sample distribution with updated legal files and new documentation files
Update DAS Sample distribution with updated legal files and new documentation files --- Key: TUSCANY-815 URL: http://issues.apache.org/jira/browse/TUSCANY-815 Project: Tuscany Issue Type: Improvement Components: Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Fix For: Java-M2 Update DAS Sample distribution with updated legal files and new documentation files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-814) Update DAS binary distribution with updated legal files and new documentation files
Update DAS binary distribution with updated legal files and new documentation files --- Key: TUSCANY-814 URL: http://issues.apache.org/jira/browse/TUSCANY-814 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Fix For: Java-M2 Update DAS binary distribution with updated legal files and new documentation files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-815) Update DAS Sample distribution with updated legal files and new documentation files
[ http://issues.apache.org/jira/browse/TUSCANY-815?page=all ] Luciano Resende reassigned TUSCANY-815: --- Assignee: Luciano Resende > Update DAS Sample distribution with updated legal files and new documentation > files > --- > > Key: TUSCANY-815 > URL: http://issues.apache.org/jira/browse/TUSCANY-815 > Project: Tuscany > Issue Type: Improvement > Components: Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > > Update DAS Sample distribution with updated legal files and new documentation > files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-814) Update DAS binary distribution with updated legal files and new documentation files
[ http://issues.apache.org/jira/browse/TUSCANY-814?page=all ] Luciano Resende updated TUSCANY-814: Attachment: tuscany814.lresende.20061009.zip Updated files in zip format > Update DAS binary distribution with updated legal files and new documentation > files > --- > > Key: TUSCANY-814 > URL: http://issues.apache.org/jira/browse/TUSCANY-814 > Project: Tuscany > Issue Type: Improvement > Components: Java DAS RDB >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany814.lresende.20061009.zip > > > Update DAS binary distribution with updated legal files and new documentation > files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-815) Update DAS Sample distribution with updated legal files and new documentation files
[ http://issues.apache.org/jira/browse/TUSCANY-815?page=all ] Luciano Resende updated TUSCANY-815: Attachment: tuscany815.lresende.20061009.zip Updated files in zip format > Update DAS Sample distribution with updated legal files and new documentation > files > --- > > Key: TUSCANY-815 > URL: http://issues.apache.org/jira/browse/TUSCANY-815 > Project: Tuscany > Issue Type: Improvement > Components: Java DAS Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany815.lresende.20061009.zip > > > Update DAS Sample distribution with updated legal files and new documentation > files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strawman of revised SDO distribution
I believe the discussions referred to by Kelvin about whether the java/spec/sdo project should be moved to java/sdo/spec are the following: Jeremy and I had a chat on IRC and here is the outcome, which Jeremy is going to act on while I get some sleep spec/sdo stays where it is samples/sdo gets moved to sdo/samples ditto distribution/sdo (If there was something on the list explaining why java/spec/sdo is better, I apologize for missing it.) I would appreciate a summary of the rationale for java/spec/sdo being better. I did see discussion on the list about releasing the spec jars separately from the implementation, but I don't see why this requires the spec project to be under java/spec/sdo. Simon kelvin goodson wrote: Hi Jeremy * getting the sdo-api doc in there would be tricker as that's outside the source tree. it may be possible to reference it, I think there's is it an absolute constraint that we have one shared Tuscany wide spec folder for all subprojects? Could I for instance have ... java/sdo java/sdo/spec ... ... java/sdo/implementation java/sdo/implementation/impl java/sdo/implementation/tools java/sdo/implementation/plugin java/sdo/implementation/sample I know you were reluctant to move the java/spec/sdo project into the java/sdo hierarchy in discussions we had a week or so ago when we moved the samples, but it would make my life much easier if I could aggregate spec and impl javadoc using a pom at the java/sdo level Regards, Kelvin. On 06/10/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: Re the javadoc, * including custom overview etc. is just configuration that can be played with (like you did with the samples) * getting the sdo-api doc in there would be tricker as that's outside the source tree. it may be possible to reference it, I think there's config for that (some form of external javadoc reference) * it may be possible to filter the source files that are included (e.g. to cut out impl details, sample source) I've not got any experience with that. Re the sample source - I included that to match what you have. It's easy to exclude by excluding the sample module. It would be fairly easy to add another assembly config that just included the sample source (which sounded like what Simon was suggesting). For that matter, you could also to that to package the javadoc separately. -- Jeremy On Oct 6, 2006, at 11:48 AM, kelvin goodson wrote: > Jeremy, > > that looks like a great improvement, thanks. After the full build > I see a > binary distro containing a javadoc folder as a peer of the lib > folder, and > it has merged javadoc for the all of the implementation projects. > (I need to > resolve the fact that there is a sample-sdo folder in there, on the > basis of > Simon Nash's comments on the RC2, but I think that's my problem.) > > So I have a few thoughts that you may have further ideas about. > > Let me tell you what I think the ideal situation is for javadoc in the > binary distribution, and where I hope we can get to with this > release. > Ideally the javadoc that a user finds in the binary distribution > documents > just the interfaces an SDO user is interested in, i.e. the SDO > API, + our > Tuscany specific extensions like SDOUtil, + our tooling, like > XSD2JavaGenerator. I didn't think I could get to that situation in > the time > available, so my plan is to get a merged javadoc that includes all > those > things, + a lot of stuff the user is not interested in, and then > provide > an overview.html that gets sucked in by the javadoc executable to > form part > of the top level index.html. This overview would provide links to the > things of interest to a user. So what you have provided is infinitely > better than what I had provided in RC2 (i.e. nothing), but if we > were able > to get the sdo-api javadoc in there too, and the process also > catered for > adding a hand crafted overview.html, as we have in the samples > project, > then that would be a great advance. > > Best Regards, Kelvin. > > On 06/10/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> >> On IRC Kelvin mentioned possibly re-jigging the SDO distribution >> format to include the assembly phase in the parent pom. The idea was >> that would make it easier to aggregate things like JavaDoc across the >> modules. >> >> I've taken a swag at this in my sandbox: >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/jboynes/ >> sdo >> >> This builds two ways: one to produce local artifacts, the other to >> produce a distribution. >> >> The first way is what we had before and allows you to build SDO as >> part of a larger reactor build (i.e. what we do when we build sdo, >> das and sca together). The default goal is "install" set by the >> reactor and that puts the binary jars in your local maven repo as >> usual. You can run this from the command line using "mvn package" or >> "mvn install" >> >> The second way does that, followed by a packaging step. That build >> aggregate javad
[jira] Created: (TUSCANY-816) Memory violation returning a DataObject from a Web Service
Memory violation returning a DataObject from a Web Service -- Key: TUSCANY-816 URL: http://issues.apache.org/jira/browse/TUSCANY-816 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M2 Reporter: Jean-Sebastien Delfino Assigned To: Jean-Sebastien Delfino Fix For: Cpp-M2 DataObjects returned by Axis2Client are allocated on the stack instead of the heap, so unless you're lucky you'll get a memory access violation when you try to access them in a client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lightning talk at ApacheCon
I'm willing to do this unless there are any other volunteers. The prospect of trying to get a clear and useful message across in 5 minutes is a scary thought, but this is all the more reason for me to learn the art of how to do a lightning talk :-) Simon Jeremy Boynes wrote: I had volunteered to do a lightning talk on Tuscany in the Incubator session at ApacheCon. Unfortunately I won't be attending - would someone be able to take over? The sign up sheet is here: http://wiki.apache.org/incubator/ApacheConFastTrack -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] M2 RC1 status
Andrew Borley wrote: Hi all, Just a quick one to find out where we are with items for C++ M2 RC1. From recent commits I think the status is: SDO - Stdcxx as a build option on Linux and Windows - done, aside from Linux support, probably not going to include Linux support - Support for an identified level of the SDO spec (2.01) - readme updated, but needs checking SCA - CPP, WS, Python, Ruby builds in source & binary release - Linux: done. Windows: CPP & WS done, Python & Ruby to do - Support for an identified level of the SCA assembly (0.96) and C++ C&I specs (0.95) - readme updated, but needs checking & adding to. Samples - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - documentation & deploy scripts done, Calculator windows build script done, BigBank windows build script to do. Docs - How to build SDO (with or without stdcxx) and SCA - done - How to deploy WS service/module to Axis2C - done - How to build/run the samples for SDO/SCA - done - Describe the new SCA language extensions progamming models - done - Release notes - updated, needs checking/adding to (see above) - How to turn existing C and/or C++ code into an SCA component - updated the "How to create a C++ component" doc - is this sufficient? Deployment - Simplify and open our tuscany-root folder structure to allow people to choose the structure that best fits their environment - done Release Requirements - Update Licence text in source files to the new Apache wording - done Does that look about right to people? Any other updates? Anything else to go in? Cheers! Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yes, On the plane on my way to ApacheCon I was playing around with our Web Services support (adding a Web Services client to BigBank) and found a serious problem in Axis2Client and WSServiceProxy, which allocate the DataObject pointers they return on the stack instead of doing a new DataObjectPtr. This causes a memory violation if a client tries to access a DataObject returned from a Web service. I raised JIRA TUSCANY-816 for this, have the fix but need to do a little more testing before I commit it. If things go well I should be able to commit it later this evening. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-814) Update DAS binary distribution with updated legal files and new documentation files
[ http://issues.apache.org/jira/browse/TUSCANY-814?page=all ] Kevin Williams resolved TUSCANY-814. Resolution: Fixed > Update DAS binary distribution with updated legal files and new documentation > files > --- > > Key: TUSCANY-814 > URL: http://issues.apache.org/jira/browse/TUSCANY-814 > Project: Tuscany > Issue Type: Improvement > Components: Java DAS RDB >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany814.lresende.20061009.zip > > > Update DAS binary distribution with updated legal files and new documentation > files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Today's IRC log
Hi, The following is a log from today's IRC chat. Thanks, Raymond (8:34:25 AM) cr22rc: I guess we're going into IRC chat time (8:34:43 AM) jboynes: when we release we won't have snapshot references (8:34:59 AM) jboynes: but meeraj is also looking at support for a repo in the war (8:35:07 AM) jboynes: so that all deps can be included (8:36:28 AM) cr22rc: well it sounds like I have two options always clean out my local repo (if that does fix it) and run bb or just say it's broken till that option comes available. (8:37:09 AM) Venkat [EMAIL PROTECTED] entered the room. (8:37:20 AM) jboynes: sigh (8:37:49 AM) jboynes: just trying to help (8:37:51 AM) cr22rc: at least frow what i know thats the opetions (8:37:55 AM) cr22rc: yes (8:39:02 AM) jboynes: FWIW it wasn't working before (8:39:21 AM) cr22rc: could run it (8:39:28 AM) jboynes: there was a problem in the scdl with the elements being in the wrong namespace (8:39:44 AM) jboynes: and we didn't report any kind of problem if we could not resolve things (8:40:00 AM) jboynes: sorry that fixing those is causing so much trauma (8:40:07 AM) cr22rc: are these seperate issues ? (8:40:24 AM) cr22rc: maybe we should get on with the regular irc ? (8:40:33 AM) cr22rc: for the sake of the others (8:41:12 AM) jboynes: ok (8:43:04 AM) lresende [EMAIL PROTECTED] entered the room. (8:44:01 AM) rfen1: do we have any topics for today's IRC? (8:44:53 AM) Venkat: yes.. can we please take stock of where we are with the release items (8:45:14 AM) kgoodson: i've been relooking at the parent pom stuff in order to try to pose specific questions (8:46:21 AM) halehM: should we go through samples and see what is running and what is not? (8:46:47 AM) Venkat: also :) (8:47:16 AM) rfen1: samples for SCA Java? (8:47:18 AM) simonnash [EMAIL PROTECTED] entered the room. (8:47:28 AM) halehM: we can start there (8:47:55 AM) jmarino [EMAIL PROTECTED] entered the room. (8:48:47 AM) rfen1: AFIW, the samples in the main build are working (8:49:39 AM) cr22rc: including all the webservices ones ? (8:50:07 AM) rfen1: there is also a discussion on the mailing list on how can we verify the samples in real environment (8:50:30 AM) rfen1: cr22rc, not including the interop cases (8:50:55 AM) cr22rc: k (8:51:33 AM) Venkat: rfen1, has those samples been tested out of the build... say setting up the env and running them..? (8:52:24 AM) rfen1: We're in the process of doing that (8:52:46 AM) cr22rc: I don't see how helloworldws could not be caught up with the same issue bb is seeing (8:53:03 AM) rfen1: at least for me, I'm trying to build the ws samples using war plugin and run with tomcat (8:53:58 AM) Venkat: there is also Jojo who is facing some problem with that Calculator combo sample... where the WS thing comes (8:54:05 AM) cr22rc: rfeng maybe we should skip this now and compare notes later -- spare others that may have more general interests? (8:54:17 AM) rfen1: ok (8:56:19 AM) cr22rc: there was the issue on the vote for parent and build pom... maybe that's more general ? (8:56:27 AM) rfen1: venkat, you're proposing that we go through the status of release items? (8:58:13 AM) Venkat: yes... for example with those on the wiki ... or if there is any other better list (8:58:28 AM) Venkat: just to let us know where we must team up a bit to pull things forward... (8:59:11 AM) rfen1: yes, maybe it's simpler to speak out what areas need help for making the release (8:59:59 AM) rfen1: let's start with me (9:00:59 AM) halehM: OK rfen1? (9:01:02 AM) lresende: one of the things i noticed, is that someone new to sca that want's to create a simple service and consume it using SCA... will have little hard time.. i found very little doco available and mostly where the spec... but didn't cover things like how to run a standalone app for example (9:01:27 AM) lresende: we might want to add some more doco and contents to the sca part of the tuscanywebsite (9:01:33 AM) cr22rc: this is the wiki list http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview (9:01:48 AM) rfen1: 1) I started to a full-cycle test the distribution for the ws samples with the help from jboynes and we made some progress last Friday and I'll continue (9:01:57 AM) Venkat: yes (9:02:12 AM) rfen1: 2) I also worked with Ignacio on the async ws feature (9:03:02 AM) Venkat: (yes was for cr22rc) (9:03:06 AM) rfen1: we got a path for client side as well as one for server side working, but there's a remaining issue on how the client side receives the response (9:04:15 AM) rfen1: I can help with other things if you speak out :-) (9:04:35 AM) Venkat: so can I say that ... (9:04:46 AM) kgoodson is now known as kgoodson_away (9:04:50 AM) Venkat: 1) Async work (categorized under kernel) is ongoing (9:05:21 AM) rfen1: maybe we should be clear: async inter-component and async ws (9:05:22 AM) Venkat: 2) Web distribution (all that it is to do with the plugin war etc.) is underway (9:05:42 AM) Venkat: 3) There is WS Samples that
Re: Can JAXB/XMLBeans work with axis binding now
Hi,
Please see my comments below.
Thanks,
Raymond
- Original Message -
From: "Li Shen" <[EMAIL PROTECTED]>
To:
Sent: Sunday, October 08, 2006 6:54 PM
Subject: Can JAXB/XMLBeans work with axis binding now
Hi,
I noticed that in the helloworldws sample, now only SDO gets used. If I
want
to use JAXB/XMLBeans instead of SDO, what shall I do then?
It's simple, just declare a component reference wired to the composite
reference with the ws (axis2) binding. For the interface of your component
reference, annotate it with @DataType(name="org.apache.xmlbeans.XmlObject")
or @DataType(name="javax.xml.bind.JAXBElement").
For example,
@Remotable
@DataType(name="javax.xml.bind.JAXBElement")
public interface JAXBInterface {
Address getAddress(Customer);
}
@Remotable
@DataType(name="org.apache.xmlbeans.XmlObject")
public interface XMLBeansInterface {
Address getAddress(Customer);
}
To be honest, I haven't had a chance to perform the integration test for
JAXB and XMLBeans. But I would be glad to help you if you run into any
issues.
Basically, I know I may need to register the SCDL of JAXB/XMLBeans to my
Tuscany runtime, and replace some configurations such as
@DataType(name="commonj.sdo.DataObject") and in helloworldws with
JAXB/XMLBeans specific stuff. Is that correct? How will and
look like? The same as SDO? Also, looks like for now there is
still no SCDL available for JAXB/XMLBeans, do you guys have any plan to
add
them?
The SCDL extension dbsdo is used to import the model for SDO which requires
a type system. For JAXB and XMLBeans, it may not be required. If you see any
requirements for such extensions, please post this list.
Thanks,
Li
-
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]
Release Process
I started a writeup of the release process on the wiki: http://wiki.apache.org/ws/Tuscany/TuscanyJava/ReleaseProcess Please add any improvements or ask questions if anything is unclear. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can JAXB/XMLBeans work with axis binding now
On Oct 9, 2006, at 6:12 PM, Raymond Feng wrote:
Hi,
Please see my comments below.
Thanks,
Raymond
- Original Message - From: "Li Shen" <[EMAIL PROTECTED]>
To:
Sent: Sunday, October 08, 2006 6:54 PM
Subject: Can JAXB/XMLBeans work with axis binding now
Hi,
I noticed that in the helloworldws sample, now only SDO gets used.
If I want
to use JAXB/XMLBeans instead of SDO, what shall I do then?
It's simple, just declare a component reference wired to the
composite reference with the ws (axis2) binding. For the interface
of your component reference, annotate it with @DataType
(name="org.apache.xmlbeans.XmlObject") or @DataType
(name="javax.xml.bind.JAXBElement").
This reminded me to pick up the discussion of where we specify the
data binding. I think this only should be specified when using Java
as an IDL really. I know Jeremy is going to add that we should allow
this to be specified in the implementation for people that cast from
a strongly typed parameter to a loosely typed one (e.g. DataObject)
so I'm going to pre-empt him ;-) I'm pretty sure people agree this is
bad programming practice/design so the question is whether we
accommodate them. While we may "support" this in terms of it works,
we should never advertise it in practice. Anyway, this sounds like we
should spin this discussion into a separate thread so Raymond, maybe
you want to pick it back up in another email?
For example,
@Remotable
@DataType(name="javax.xml.bind.JAXBElement")
public interface JAXBInterface {
Address getAddress(Customer);
}
@Remotable
@DataType(name="org.apache.xmlbeans.XmlObject")
public interface XMLBeansInterface {
Address getAddress(Customer);
}
To be honest, I haven't had a chance to perform the integration
test for JAXB and XMLBeans. But I would be glad to help you if you
run into any issues.
Li, I think it would be great if we can get some of the JAXB and
XMLBeans stuff working.
Basically, I know I may need to register the SCDL of JAXB/XMLBeans
to my
Tuscany runtime, and replace some configurations such as
@DataType(name="commonj.sdo.DataObject") and in
helloworldws with
JAXB/XMLBeans specific stuff. Is that correct? How will and
look like? The same as SDO? Also, looks like for now
there is
still no SCDL available for JAXB/XMLBeans, do you guys have any
plan to add
them?
The SCDL extension dbsdo is used to import the model for SDO which
requires a type system. For JAXB and XMLBeans, it may not be
required. If you see any requirements for such extensions, please
post this list.
I have a feeling it may be required for XBeans. Li, do you know
offhand how custom types are loaded in XBeans (and the JAXB RI for
that matter)?
Jim
Thanks,
Li
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can JAXB/XMLBeans work with axis binding now
Thanks Raymond. I will try to test the XMLBeans/JAXB stuff with WS binding.
> -Original Message-
> From: Raymond Feng [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 10, 2006 9:13 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Can JAXB/XMLBeans work with axis binding now
>
> Hi,
>
> Please see my comments below.
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Li Shen" <[EMAIL PROTECTED]>
> To:
> Sent: Sunday, October 08, 2006 6:54 PM
> Subject: Can JAXB/XMLBeans work with axis binding now
>
>
> > Hi,
> >
> > I noticed that in the helloworldws sample, now only SDO gets used. If I
> > want
> > to use JAXB/XMLBeans instead of SDO, what shall I do then?
> >
>
> It's simple, just declare a component reference wired to the composite
> reference with the ws (axis2) binding. For the interface of your component
> reference, annotate it with
@DataType(name="org.apache.xmlbeans.XmlObject")
> or @DataType(name="javax.xml.bind.JAXBElement").
>
> For example,
>
> @Remotable
> @DataType(name="javax.xml.bind.JAXBElement")
> public interface JAXBInterface {
>Address getAddress(Customer);
> }
>
> @Remotable
> @DataType(name="org.apache.xmlbeans.XmlObject")
> public interface XMLBeansInterface {
>Address getAddress(Customer);
> }
>
> To be honest, I haven't had a chance to perform the integration test for
> JAXB and XMLBeans. But I would be glad to help you if you run into any
> issues.
>
> > Basically, I know I may need to register the SCDL of JAXB/XMLBeans to my
> > Tuscany runtime, and replace some configurations such as
> > @DataType(name="commonj.sdo.DataObject") and in helloworldws
> with
> > JAXB/XMLBeans specific stuff. Is that correct? How will and
> > look like? The same as SDO? Also, looks like for now there
is
> > still no SCDL available for JAXB/XMLBeans, do you guys have any plan to
> > add
> > them?
> >
>
> The SCDL extension dbsdo is used to import the model for SDO which
requires
> a type system. For JAXB and XMLBeans, it may not be required. If you see
any
> requirements for such extensions, please post this list.
>
> > Thanks,
> > Li
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Lightning talk at ApacheCon
I blogged about ApacheCon but wasn't aware of this event, could you please send me the details of this Lightning talk, and if there is any other Tuscany related sessions or events in ApacheCon that anyone is about, so i can update the blog entry : http://apache-tuscany.blogspot.com/2006/10/apache-tuscany-at-apachecon-us-2006.html#links - Luciano -- Forwarded message -- From: Jeremy Boynes <[EMAIL PROTECTED]> Date: Oct 8, 2006 10:08 PM Subject: Lightning talk at ApacheCon To: tuscany-dev@ws.apache.org I had volunteered to do a lightning talk on Tuscany in the Incubator session at ApacheCon. Unfortunately I won't be attending - would someone be able to take over? The sign up sheet is here: http://wiki.apache.org/incubator/ApacheConFastTrack -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can JAXB/XMLBeans work with axis binding now
> -Original Message- > From: Jim Marino [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 10, 2006 9:26 AM > To: tuscany-dev@ws.apache.org > Subject: Re: Can JAXB/XMLBeans work with axis binding now > > Li, I think it would be great if we can get some of the JAXB and > XMLBeans stuff working. I think I can have a try later. > I have a feeling it may be required for XBeans. Li, do you know > offhand how custom types are loaded in XBeans (and the JAXB RI for > that matter)? I've not yet worked with JAXB/XMLBeans. >From the JAXB tutorial, I saw that to load custom types, looks like JAXB requires the package name of the pre-generated classes: JAXBContext jc = JAXBContext.newInstance( "primer.po" ); Not sure if we need to tell the data binding framework the package name "primer.po". For regular XMLBeans usage, looks like we may directly use the pre-generated classes to do marshalling/unmarshalling: customType.Factory.parse(); // unmarshal customType.newXMLStreamReader() // marshal But when doing unmarshalling, the data binding framework simply use the generic XmlObject.Factory.parse() instead of the pre-generated class, and I don't know how it works? Raymond, would you please clarify? Thanks > > Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] M2 RC1 status
On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: On the plane on my way to ApacheCon I was playing around with our Web Services support (adding a Web Services client to BigBank) and found a serious problem in Axis2Client and WSServiceProxy, which allocate the DataObject pointers they return on the stack instead of doing a new DataObjectPtr. This causes a memory violation if a client tries to access a DataObject returned from a Web service. I raised JIRA TUSCANY-816 for this, have the fix but need to do a little more testing before I commit it. If things go well I should be able to commit it later this evening. Having a quick glance at this code I was wondering who frees up the memory allocated by Axis2Client and set in the Operation? For DataObjectPtr we could have the Operation::setParameter/setReturnValue methods new up a DataObjectPtr and free it in the destructor. This would work nicely with this as it is reference counted. A different solution would be needed for the other types. Cheers, -- Pete
Re: [C++] M2 RC1 status
Sounds about right. I need to add Ruby and Python extensions into the windows command line build. Hopefully this will be done today. Cheers, On 09/10/06, Andrew Borley <[EMAIL PROTECTED]> wrote: Hi all, Just a quick one to find out where we are with items for C++ M2 RC1. From recent commits I think the status is: SDO - Stdcxx as a build option on Linux and Windows - done, aside from Linux support, probably not going to include Linux support - Support for an identified level of the SDO spec (2.01) - readme updated, but needs checking SCA - CPP, WS, Python, Ruby builds in source & binary release - Linux: done. Windows: CPP & WS done, Python & Ruby to do - Support for an identified level of the SCA assembly (0.96) and C++ C&I specs (0.95) - readme updated, but needs checking & adding to. Samples - Calculator, PythonCalculator, RubyCalculator, BigBank, RubyBank - documentation & deploy scripts done, Calculator windows build script done, BigBank windows build script to do. Docs - How to build SDO (with or without stdcxx) and SCA - done - How to deploy WS service/module to Axis2C - done - How to build/run the samples for SDO/SCA - done - Describe the new SCA language extensions progamming models - done - Release notes - updated, needs checking/adding to (see above) - How to turn existing C and/or C++ code into an SCA component - updated the "How to create a C++ component" doc - is this sufficient? Deployment - Simplify and open our tuscany-root folder structure to allow people to choose the structure that best fits their environment - done Release Requirements - Update Licence text in source files to the new Apache wording - done Does that look about right to people? Any other updates? Anything else to go in? Cheers! Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] M2 RC1 status
Pete Robbins wrote: On 10/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: On the plane on my way to ApacheCon I was playing around with our Web Services support (adding a Web Services client to BigBank) and found a serious problem in Axis2Client and WSServiceProxy, which allocate the DataObject pointers they return on the stack instead of doing a new DataObjectPtr. This causes a memory violation if a client tries to access a DataObject returned from a Web service. I raised JIRA TUSCANY-816 for this, have the fix but need to do a little more testing before I commit it. If things go well I should be able to commit it later this evening. Having a quick glance at this code I was wondering who frees up the memory allocated by Axis2Client and set in the Operation? Currently, nobody :) We had already started to discuss this issue in this thread: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL PROTECTED] but we don't have a definitive solution for it yet. For DataObjectPtr we could have the Operation::setParameter/setReturnValue methods new up a DataObjectPtr and free it in the destructor. This would work nicely with this as it is reference counted. A different solution would be needed for the other types. I think you're right, but we need to take a close look at the lifecycle of the data flowing through the runtime. For example, data to a client component returned from a service invocation cannot be freed until the client component finishes. Here's a first analysis of how we could handle the data set into an Operation parameters or returnValue. It may not be completely right but it's a starting point to help trigger some ideas... Parameters: - a DataObjectPtr set into the parameter --> can be freed when the Operation is deleted (in the ServiceProxy::invoke method just before returning) - the DataObject pointed to by that DataObjectPtr --> will be freed when its reference count goes down to 0 - a string* or int* or char** set into the parameter --> can be freed when the Operation is deleted - the string or int pointed to by that string* or int* --> can be freed when the Operation is deleted - the char* --> document that the component getting the char* is responsible for freeing it? or free it when the Operation is deleted? Return value: - a DataObjectPtr set into the return value --> can be freed when the Operation is deleted - the DataObject pointed to by that DataObjectPtr --> will be freed when its reference count goes down to 0 - a string* or int* or char** set into the parameter --> can be freed when the Operation is deleted - the string or int pointed to by that string* or int* --> can be freed when the Operation is deleted - the char* --> document that the component getting the char* is responsible for freeing it? or? Anyway, I'm not sure what you guys think, but unless we have a very clear view of how to fix this, I'd suggest to tackle this problem after the M2 release and live with the small memory leak for now. Thoughts? Cheers, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-816) Memory violation returning a DataObject from a Web Service
[ http://issues.apache.org/jira/browse/TUSCANY-816?page=all ] Jean-Sebastien Delfino resolved TUSCANY-816. Resolution: Fixed Fixed the memory violation. There is still a memory leak issue remaining. > Memory violation returning a DataObject from a Web Service > -- > > Key: TUSCANY-816 > URL: http://issues.apache.org/jira/browse/TUSCANY-816 > Project: Tuscany > Issue Type: Bug > Components: C++ SCA >Affects Versions: Cpp-M2 >Reporter: Jean-Sebastien Delfino > Assigned To: Jean-Sebastien Delfino > Fix For: Cpp-M2 > > > DataObjects returned by Axis2Client are allocated on the stack instead of the > heap, so unless you're lucky you'll get a memory access violation when you > try to access them in a client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
