date:20070417


Hi Frank,

SNIP

If you look at class ChangeSummaryImpl, you'll notice that in Tuscany we 
actually implement this with three separate lists under the covers. The 
isDeleted() method, for example, looks like this:


  public boolean isDeleted(DataObject dataObject)
  {
return getCachedDeletedObjects().contains(dataObject);
  }


Oh - Great - I like that :-).


I know that there is a proposed SDO 3 work item to revisit ChangeSummary 
to see if the API could be improved. Perhaps you'd like to get involved in 
the spec discussion on this issue, when it begins? 


Absolutely and thank you for the detailed explanation and OSOA link.

Cheers,
- Ole

SNIP

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

Tuscany Weekly IRC chat log - April 16 2007


Here's the log from Monday's IRC chat. Main topics discussed were the up
coming SDO and DAS releases and whether they should be called M3 or if
they're ready to be beta releases.

  ...ant

[11:35]  hi, are we having a chat today?
[11:36]  i think so...
[11:36]  is it now, or has the time chnaged?
[11:37]  hi
[11:37]  it's about now :)
[11:38]  can we start talking about SDO RC ?
[11:39]  they are still based on artifact version incubator
[11:39]  and now that we are all going to incubating style, should
they need to respin ?
[11:39]  the release candidate ?
[11:39]  is kgoodson here?
[11:39]  hi ant
[11:39]  that was a question from kgoodson?
[11:40]  ok, just checking those involved are here
[11:40]  what's the user inpact of the mismatch?
[11:40]  on the chance there's a respin,
[11:41]  how about the next DAS and SDO release are called something
closer to 1.0 than M3, maybe beta1 or something like that?
[11:42]  or should atleast for SDO this one go out as M3 and look at
the name later for teh nxt release?
[11:42]  for SDO, is this going to cause confusion around the spec
version, as they are 2x ?
[11:43]  to be clear,  SDO uses a parent with an incubating
version tag,  but its own ersion s in the release candidate uses incubator
-- i don't think there would be a user impact
[11:43]  id go along with ant_ suggestion that we go to something
alpha-ish next time round
[11:43]  if there's no user impact then a respin just for this
does not seem justified
[11:43]  kgoodson: if you are already using the incubating parent,
we are going to have to release that, right ?
[11:44]  milestone and alpha names can be a real off putter to get
people to try them
[11:44]  no,  that's my thinking too
[11:44]  my last comment was to somonnash
[11:44]  didn't we just tell a user on th elist that these are about
production ready?
[11:44]  simonnash
[11:44]  we seem to have ahad a few brave souls trying M2 for
both SCA and SDO :-)
[11:45]  ok msg received.. thanks
[11:46]  ant_  -- your comment on production ready,  was that
suggestion that beta would be a better tag than alpha -- i could go along
with that for SDO
[11:46]  yes, thats what i think
[11:46]  sure,  yes,  as i hit return i thought "beta" would have
been a better thing to say
[11:47]  what needs to get done to make it 1.0?
[11:47]  +1 SDO is getting really stable now, so beta seems right
to me too
[11:47]  lresende your comment above --- kgoodson: if you are
already using the incubating parent, we are going to have to release that,
right
[11:47]  we already have voted on the 2-incubating parent
[11:48]  are we saying beta for this release, or the next time?
i thought kgoodson was saying the next one.
[11:48]  kgoodson: but jeremy removed the voting thread from the
iPMC, no ?
[11:48]  ah,  i need to look back
[11:49]  i'd say for this one, but i know that causes a complete
respin and update so fine if thats to much work and we just want to get this
out as M3
[11:49]  right, we would have to put that up for IPMC vote
together with the SDO IPMC vote
[11:50]  when do we expect the next SDO release?  what is coming
along in SDO's near future?
[11:53]  we have to finish the 2.1 features,  things like
nullable, demand created properties and a couple of other things
[11:53]  right now i am concentrating on making tuscany compliant
against the CTS
[11:54]  so once the 2.1 features are done would that be ready for a
1.0 tuscany release?
[11:54]  sounds like there are opportunities for a beta release
soon... either to finish the 2.1 features or to claim CTS compliance
[11:54]  we havent discussed a next release date for the next
release or content
[11:55]  i raised this to see if we could defer beta until next
release.  if the next release is soon that could be OK.
[11:58]  somonnash i'm not sure if you are suggesting deferring
the current release process in favour of stalling until we can have a beta.
My feeling is that we should get out whatever we have now,  whether it be
called M3 or beta,  then follow it up as soon as possible with a rleease
that has all 2.1 features in it
[11:59]  That seems quite reasonable to me. I was just trying to get
people thinking about the path to beta's and 1.0
[12:00]  no i am defnitely not suggesting deferring the current
release
[12:01]  the question was abot the naming
[12:01]  if it is good to be on something called beta in terms of
attracting user interest, then we would not want to wait a very long time to
have such a release
[12:02]  i suppose I would go with M3 for now since we already
have that in the can, then beta for the next one
[12:03]  How about DAS, is it ready to beta1 for the next release?
[12:03]  ok,  i think the apache way is to release little and
often,  but it would seem sensible to time the next release with having at
least a first cut at implementation of all 2.1 features.  I would hope that
these two criteria would be compatible
[12:05]  as long as we don't need a specification to be a 1.0, i
think DAS is ok gett

Re: Scoping SDO metadata, was: How to access a composite's data model scope in an application?

Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote on 04/17/2007 03:53:43 
PM:

[snip]

> To help feed this discussion with concrete data, could the SDO folks 
> jump in here, and describe the various ways of maintaining SDO metadata 
> scopes in a server environment, running with multiple classloaders and 
> threads?

Here's what we have today.

1) HelperProvider.getDefaultContext()

This returns a special HelperContext that manages multiple 
ClassLoader-specific scopes behind the scene. All metadata get() calls 
will use the scope associated with the TCCL or a parent CL if not found in 
the child's scope. The put() calls will be associated with the TCCL scope.

2) SDOUtil.createHelperContext()

This returns a HelperContext representing a single local scope. It is 
completely independent of CLs. Any chaining of scope would need to be done 
somewhere else.

3) Hierarchical HelperContexts - TBD

I am expecting that we will provide ways to chain HelperContexts - e.g. 
HelperContext.addParent() - or maybe even some way to construct them based 
on a CL-hierarchy - e.g. createHelperContext(ClassLoader cl). These are 
the kinds of things I'd like to work out with you guys, implement them in 
Tuscany, and then take them back to the next verion of the spec. Note that 
everything I've described (1, 2, and 3) is outside of the spec.

Frank.


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

[jira] Commented: (TUSCANY-1194) Improve SCA SDO databinding serialization performance

2007-04-17 Thread Raymond Feng (JIRA)


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

Raymond Feng commented on TUSCANY-1194:
---

The databinding-sdo-axiom module provides the direct transformation from SDO to 
AXIOM. 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-sdo-axiom/.
 But if I remember correctly, it requires a newer version of the AXIOM to take 
the full performance advantage.

We could probably move to the latest AXIOM level as Axis2 1.2 release is on the 
way out.


> Improve SCA SDO databinding serialization performance
> -
>
> Key: TUSCANY-1194
> URL: https://issues.apache.org/jira/browse/TUSCANY-1194
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Kernel
>Affects Versions: Java-SCA-M2
>Reporter: Fuhwei Lwo
>
> Currently a web service response with SDO databinding is first transformed 
> from SDO to an XMLStreamReader and then to a fuly inflated OM element which 
> is serialized to SOAP/XML.  There are opportunities for two significant 
> performance improvements:  First, use the OMDataSource approach to provide 
> for the possibility of a single transformation and to also eliminate the 
> inflation of the OM element.  Second, directly transform the SDO to SOAP/XML 
> without the intermediate transformation to XMLStreamReader.

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


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

Re: Require more context for URLArtifactProcessorExtension.read()

Hi,

I was refering to artifact URI instead of contribution URI. For example, if 
a jar contribution is deployed, the URI of a class named a.b.MyClass in the 
jar will be "a/b/MyClass.class".

ContributionContext is one way to pass more context to the processors. But I 
don't think it will go through injection. It should be on the method 
signature of the SPI.

Thanks,
Raymond

- Original Message - 
From: "Luciano Resende" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, April 17, 2007 1:43 PM
Subject: Re: Require more context for URLArtifactProcessorExtension.read()

Hi Raymond

  I'm not sure if the Contribution URI will really work for your
requirements, as of today, the URL that the artifactProcessor receives is
the actual artifact URL location, and it's not based on the Contribution 
URI

and also can be normalized based on the contribution package type (e.g jar
will have a jar URL). Thinking on the second requirement, if we create a
contribution context with some basic contribution information
(e.gcontribution uri, contribution base location, normalized
contribution base
location, and the contribution classloader) and "inject" it on the
processor, then you would have the necessary information to perform the
necessary actions you need?

  Once we agree on a solution, I can get it implemented.

Thoughts ?

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

Hi,

I think you already got it right. I want to contribute a processor to 
scan
the classes to figure out available generated SDO factory 
interface/class.

During the "read" phase, the processor will capture the classname by a
naming pattern. The class will be loaded during "resolve" phase and the
factory will be registered with a HelperContext.

I see two requirements here:
1) read: Pass in the URI of the artifact which can be used to derive the
class name
2) resolve: Pass in a contribution classloader which can be used to
resolve
java classes

Thanks,
Raymond

- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 17, 2007 11:22 AM
Subject: Re: Require more context for 
URLArtifactProcessorExtension.read()

> Raymond Feng wrote:
>> Hi,
>>
>> When I try to add a URLArtifactProcessorExtension to introspect java
>> classes, I found it impossible to get the class name as only the URL 
>> of
>> the class file is passed to the read() method. To provide such 
>> context,

I
>> suggest that we pass in the DeployedArtifact (which contains the URL)
>> instead of URL to the read() method.
>>
>> Do you agree or do you have a better way?
>>
>> Thanks,
>> Raymond
>>
>
> Could you give more context as well? :) and describe what you're trying
to
> do?
>
> Are you trying to derive a class name from the file name? Are you going
to
> load or read the class file and could you find the class name from its
> contents then?
>
> It's a little difficult to try to answer without more context, but in
> general I would prefer for ArtifactProcessors not to have to know the
> structure of the Contribution or the DeployedArtifacts that represent
it.
> If you need to know the base URL of the contribution and the path of 
> the

> given Artifact inside it, then maybe we could pass these two parameters
to
> the read() method, it would be better than passing the whole
> DeployedArtifact and have the read() method dig into it.
>
> But again, before we do that, could you describe your use case? and 
> then

> hopefully we can find a good solution for it. Thanks.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

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

--
Luciano Resende
http://people.apache.org/~lresende

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

Re: How can I get the Component URI for a service?


[snip]
ant elder wrote:

Cool, that works and gets me the name thanks.

Should Component have a URI? The o.a.t.assembly.Component interface 
doesn't
have a get/setURI which seems to match the schema in the spec, but 
page 53

line 2362 of the Assembly spec makes it sound like it should.

  ...ant



Line 2362 says: The component URI above is for a component that is 
deployed in the SCA Domain. The URI of a component defaults to the name 
of the component.


I'm assuming that this talks about components declared in deployable 
(top-level) composites which are included in the SCA domain and that 
this URI would not apply to components declared in nested composites. 
This is the only place in the whole spec that mentions this so before 
adding a URI to all components I'd like to double check with the spec 
folks that it's not a bug in the spec :)


The good news is that the second sentence allows the default URI to be 
the component name, which we already have in the model :)


--
Jean-Sebastien


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

Re: Require more context for URLArtifactProcessorExtension.read()

2007-04-17 Thread Luciano Resende

Hi Raymond

  I'm not sure if the Contribution URI will really work for your
requirements, as of today, the URL that the artifactProcessor receives is
the actual artifact URL location, and it's not based on the Contribution URI
and also can be normalized based on the contribution package type (e.g jar
will have a jar URL). Thinking on the second requirement, if we create a
contribution context with some basic contribution information
(e.gcontribution uri, contribution base location, normalized
contribution base
location, and the contribution classloader) and "inject" it on the
processor, then you would have the necessary information to perform the
necessary actions you need?

  Once we agree on a solution, I can get it implemented.

Thoughts ?

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

Hi,

I think you already got it right. I want to contribute a processor to scan
the classes to figure out available generated SDO factory interface/class.
During the "read" phase, the processor will capture the classname by a
naming pattern. The class will be loaded during "resolve" phase and the
factory will be registered with a HelperContext.

I see two requirements here:
1) read: Pass in the URI of the artifact which can be used to derive the
class name
2) resolve: Pass in a contribution classloader which can be used to
resolve
java classes

Thanks,
Raymond

- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 17, 2007 11:22 AM
Subject: Re: Require more context for URLArtifactProcessorExtension.read()

> Raymond Feng wrote:
>> Hi,
>>
>> When I try to add a URLArtifactProcessorExtension to introspect java
>> classes, I found it impossible to get the class name as only the URL of
>> the class file is passed to the read() method. To provide such context,
I
>> suggest that we pass in the DeployedArtifact (which contains the URL)
>> instead of URL to the read() method.
>>
>> Do you agree or do you have a better way?
>>
>> Thanks,
>> Raymond
>>
>
> Could you give more context as well? :) and describe what you're trying
to
> do?
>
> Are you trying to derive a class name from the file name? Are you going
to
> load or read the class file and could you find the class name from its
> contents then?
>
> It's a little difficult to try to answer without more context, but in
> general I would prefer for ArtifactProcessors not to have to know the
> structure of the Contribution or the DeployedArtifacts that represent
it.
> If you need to know the base URL of the contribution and the path of the
> given Artifact inside it, then maybe we could pass these two parameters
to
> the read() method, it would be better than passing the whole
> DeployedArtifact and have the read() method dig into it.
>
> But again, before we do that, could you describe your use case? and then
> hopefully we can find a good solution for it. Thanks.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

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

--
Luciano Resende
http://people.apache.org/~lresende

[jira] Commented: (TUSCANY-1204) Support for @requires annotation and requires attribute

2007-04-17 Thread Jean-Sebastien Delfino (JIRA)


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

Jean-Sebastien Delfino commented on TUSCANY-1204:
-

I didn't make changes to support requires and policySets in SCA assembly XML as 
part of this particular JIRA, because it was pretty much already there in the 
new model and artifactprocessors for .composites, .componenttypes etc :) I 
think this support is equivalent to what you were doing as well in your patch.

> Support for @requires annotation and requires attribute
> ---
>
> Key: TUSCANY-1204
> URL: https://issues.apache.org/jira/browse/TUSCANY-1204
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Model
>Reporter: Mark I. Dinges
> Assigned To: Jean-Sebastien Delfino
> Fix For: Java-SCA-Next
>
> Attachments: policyworkdelta.txt
>
>
> The follow patch is to add annotation and attribute suppot to the model. For 
> @Requires annotation on Service implementaion at the class level the intents 
> will be added to the ComponentType model object. For @Requires annotation on 
> the Service implementation at the operation/method level the intents are 
> added to the Operation Model Object. For @Requires annotations on the Service 
> interface at the class level the intents are added to the ServiceContract 
> model object. For @Requires annotations on the Service interface at the 
> operation/method level the intents are added to the Operation model object. 
> For "requires" attribute that is on the Service in the scdl the intents are 
> added to the ServiceDefinition model object. For "requires" attribute that is 
> on the Reference in the scdl the intents are added to the ReferenceDefinition 
> model object. For "requires" attribute that is on the implementation.java in 
> the scdl the intents are added to the Implementation model object.
> I did not want to duplicate code that existed in ServiceProcessor.java so the 
> PolicyProcessor class should be added after the ServiceProcessor in the 
> implementation.scdl. 
> 
>  class="org.apache.tuscany.core.implementation.processor.PolicyProcessor"/>
> 
> PolicyJavaInterfaceProcessor will need to be added as implementation.system 
> Not sure of the most appropiate place to at it with changes that have been 
> happening.

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


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

Re: [DAS] Performance / API / Spec

Hi Ole,

I'm not sure what reasoning was to justify the ChangeSummary API which 
requires you to iterate over the one list returned by 
getChangedDataObjects() and then call isCreated(), isModified(), or 
isDeleted() to see if it was a C, U, or D.

If you look at class ChangeSummaryImpl, you'll notice that in Tuscany we 
actually implement this with three separate lists under the covers. The 
isDeleted() method, for example, looks like this:

  public boolean isDeleted(DataObject dataObject)
  {
return getCachedDeletedObjects().contains(dataObject);
  }

I know that there is a proposed SDO 3 work item to revisit ChangeSummary 
to see if the API could be improved. Perhaps you'd like to get involved in 
the spec discussion on this issue, when it begins? Now that it's moving to 
OASIS (http://osoa.org/display/Main/News+about+SCA+and+SDO), SDO design 
discussions will be open to everyone.

Frank.


Ole Ersoy <[EMAIL PROTECTED]> wrote on 04/17/2007 12:27:58 PM:

> Hi Guys,
> 
> I have a few performance related
> questions with respect to change
> summary processing (Really spec related - hope it's ok that I float it 
> here).
> 
> I just looked at the Change
> summary API and it looks like
> the DataGraph sets the
> isDeleted and isCreated
> flags on each DataObject instance
> that it creates or deletes, and
> then it adds them to the change summary.
> 
> It seems like change summary
> processing would perform better
> if the Change summary had CUD lists.
> 
> So one list for:
> - Created DataObjects
> - Deleted DataObjects
> - Update DataObjects
> 
> Then these lists could be processed directly by the
> DAS and it would not have to check what type CUD
> was done for each object.
> 
> Then the DataGraph only adds objects to these lists
> and does not need to set any flags, which means that
> during processing the flags don't need to be checked
> in order to perform the right type of processing.
> 
> I'm still getting my feet wet here, but I thought I'd throw this out 
> there, since to me it seems like it's simpler and more light weight.
> 
> Thoughts?
> 
> Thanks,
> - Ole
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

[jira] Resolved: (TUSCANY-1216) Sequence.add(index,value) is not working due to a type mismatch problem

2007-04-17 Thread Frank Budinsky (JIRA)


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

Frank Budinsky resolved TUSCANY-1216.
-

Resolution: Fixed

Fixed in revision 529735.

Note that the test program also has a bug. SDO Type "Integer" maps to 
java.math.BigInteger, not java.lang.Integer.


> Sequence.add(index,value) is not working due to a type mismatch problem
> ---
>
> Key: TUSCANY-1216
> URL: https://issues.apache.org/jira/browse/TUSCANY-1216
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M3
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-M3
>
>
> The sample below demonstrates a problem found when adding properties into a 
> sequence object using the property index.  The issue seems to be related to 
> how the property index is acquired and how that index is subsequently used by 
> the BasicSequence object.  BasicSequence.add(int, Object) uses the EMF 
> eClass().getEstructuralFeature(int) method to retrieve the property, based on 
> the index.  The list of properties kept in this array, includes both 
> 'explicit' properties defined by the schema or inline code, and 'implicit' 
> properties defined by the Tuscany SDO framework (in this case, I believe it 
> is actually the underlying EMF that is creating the implicit property).  Once 
> such implicit property is the 'multi' property, defined when a type is 
> identified as containing a sequence.  The core issue here is that the code 
> used to identify the index to use is based on an array of SDO properties, 
> which do not include the implicit properties.  So, the index is derived from 
> a different array than the one being used for updating, this is the root 
> cause of this problem.  A change to how the BasicSequence object obtains the 
> indexed property is probably the correct remedy for this issue.
> Sample code:
> public static void main(String[] args) 
> {
> String URI = "http://example.com/test";;
> 
> HelperContext scope = SDOUtil.createHelperContext();
> TypeHelper typeHelper = scope.getTypeHelper();
> Type integerType = typeHelper.getType("commonj.sdo", "Integer");
> 
> DataObject wrapperType = scope.getDataFactory().create("commonj.sdo", 
> "Type");
> wrapperType.set("uri", URI );
> wrapperType.set("name", "Wrapper");
> wrapperType.setBoolean("sequenced", true);
> 
> // Create Property
> DataObject intProperty = wrapperType.createDataObject("property");
> intProperty.set("name", "Value");
> intProperty.set("type", integerType);
> intProperty.setBoolean("many", true);
> 
> // register the wrapper
> typeHelper.define(wrapperType);
> 
> // get registered type
> Type testType = typeHelper.getType(URI,"Wrapper");
> 
> // Create an instance of the Wrapper Type
> DataObject testDO = scope.getDataFactory().create(testType);
> // Update the sequence using the index
> List properties = testType.getProperties();
> int index = properties.indexOf(testDO.getInstanceProperty("Value"));
> Sequence sequence = testDO.getSequence();
> Integer v = new Integer(10);
> sequence.add(index,v);
> }

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


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

Scoping SDO metadata, was: How to access a composite's data model scope in an application?

Fuhwei Lwo wrote:

Hi,

In my composite, I defined in the
default.scdl file that would prompt the SCA container to register my data types using SDO
databinding. The question I have is what API I should use in my service implementation code to
obtain the registered data types. If I have two composites that are using two different data
type definition but with the same namespace URI, I definitely don't want to obtain the wrong
data type definition. Thanks for your help.

Below is the previous message from Raymond Feng about associating databinding
type system context/scope with a composite. I think this is related to my
question but from Tuscany SCA development perspective.

How to associate some context with a composite?
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200702.mbox/[EMAIL
PROTECTED]

Hi,

The short (and not perfect) answer to your question is. With the current
code in trunk, use:

commonj.sdo.impl.HelperProvider.getDefaultContext()

But I thought about this a bit and your question triggered some
comments, and more questions :)

Import.sdo extension:
I think we should be able to remove that Tuscany extension to SCA
assembly XML, now that we have the SCA contribution service in place. We
know which WSDLs and XSDs are available in a given SCA contribution and,
with sca-contribution.xml import elements, we also know which XML
namespaces are imported from other SCA contributions or other locations
outside of an SCA domain. So we probably don't need another
element duplicating part of this information in .composite files.

Scope of XML metadata:
My understanding of the SCA assembly spec is that the scope of XML
metadata is an SCA contribution (plus what it imports from outside) and
not an individual Composite.

Scope of metadata contributed by Java classes:
Our runtime currently supports SCA contributions packaged as JARs or
file system folders. With these packaging schemes an SCA contribution is
self contained and cannot reference application classes in other SCA
contributions. At some point we'll probably want to support packaging of
SCA contributions as OSGI bundles and then leverage OSGI to allow an
OSGI bundle to see classes in another bundle, but we don't support that
OSGI packaging scheme yet. As a side comment I'd like to see if we could
reactivate some work on the OSGI extensions that we have under
java/sca/contrib/ and are not integrated in our build at the moment. So,
the scope of Java metadata is an SCA contribution as well, with no
external import mechanism.

So the bottom line is:
References to types in SCA artifacts are resolved at the SCA
contribution level. There is no relationship between an SCA composite
and a metadata scope.

More comments, on databinding specific handling of metadata:
We need to support multiple databindings. Each databinding comes with
its own form of metadata and different APIs to get to that metadata and
define metadata scopes. I guess it's important for a databinding
technology to define a way to scope metadata if it wants to be
successfully used in a server environment, and isolate the metadata for
the different applications running on the server.

In such an environment, our SCA runtime should play nicely with the
other pieces of runtime and application code (not necessarily running as
SCA components), and use the metadata scoping mechanism defined by each
databinding in such a way that non-SCA code and SCA component code
running together in the server environment are able to see the same
metadata for a given application.

I'd like to start a discussion to cover this aspect for our various
databindings and make sure that the metadata story for each databinding
holds together.

To help feed this discussion with concrete data, could the SDO folks
jump in here, and describe the various ways of maintaining SDO metadata
scopes in a server environment, running with multiple classloaders and
threads?

Thanks,

--
Jean-Sebastien

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

Re: [XPATH] Getting a DataObject's Path?


Frank, Kelvin,

Thanks - That's exactly what I'm looking for.

Cheers,
- Ole



Frank Budinsky wrote:
There's no standard SDO API, but we have a Tuscany utility method which is 
used in the implementation of Java serialization:


DataObjectUtil.getXPath(DataObject dataObject)

Frank.




Ole Ersoy <[EMAIL PROTECTED]> 
04/17/2007 02:50 PM

Please respond to
tuscany-dev@ws.apache.org


To
tuscany-dev@ws.apache.org
cc

Subject
[XPATH] Getting a DataObject's Path?






Hi,

I've been looking at the SDO Specification
and Javadocs trying to figure out how to get a dataobject's
path (Relative to it's root).

Something like:

String path = DataGraph.getPath(dataObject);

Which would return something like:

"//company/employees[2]/"

Thoughts?

Thanks,
- Ole



-
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: [XPATH] Getting a DataObject's Path?

There's no standard SDO API, but we have a Tuscany utility method which is 
used in the implementation of Java serialization:

DataObjectUtil.getXPath(DataObject dataObject)

Frank.




Ole Ersoy <[EMAIL PROTECTED]> 
04/17/2007 02:50 PM
Please respond to
tuscany-dev@ws.apache.org


To
tuscany-dev@ws.apache.org
cc

Subject
[XPATH] Getting a DataObject's Path?






Hi,

I've been looking at the SDO Specification
and Javadocs trying to figure out how to get a dataobject's
path (Relative to it's root).

Something like:

String path = DataGraph.getPath(dataObject);

Which would return something like:

"//company/employees[2]/"

Thoughts?

Thanks,
- Ole



-
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: SDO project build failure


Not sure,  it worked for me before and after the removel,  so i guess
perhaps your local maven repo somehow had become corrupted.

Kelvin.


On 17/04/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:


Thanks Kelvin. I removed it and that fixed it for me. It must have been
corrupted

Frank.

"kelvin goodson" <[EMAIL PROTECTED]> wrote on 04/17/2007 02:29:24
PM:

> It builds cleanly for me, even after removing
> ~\.m2\repository\org\apache\maven\plugins\maven-dependency-plugin,  so
was
> this an intermittent thing?
>
> regards, Kelvin.
>
>
>
>
> On 17/04/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I just did an svn update of the SDO project, and now it fails to
build.
> > Any ideas?
> >
> > Thanks,
> > Frank.
> >
> > [INFO] Scanning for projects...
> > [INFO] Reactor build order:
> > [INFO]   Tuscany SDO Implementation Project
> > [INFO]   Tuscany SDO Implementation
> > [INFO]   Tuscany SDO Tools
> > [INFO]   Tuscany SDO Maven Plugin
> > [INFO]
> >
-
> > ---
> > [INFO] Building Tuscany SDO Implementation Project
> > [INFO]task-segment: [install]
> > [INFO]
> >
-
> > ---
> > [INFO] Skipping missing optional mojo:
> > org.apache.maven.plugins:maven-site-plugi
> > n:attach-descriptor
> > [INFO]
> >

> > [ERROR] BUILD ERROR
> > [INFO]
> >

> > [INFO] The plugin ' org.apache.maven.plugins:maven-dependency-plugin'
does
> > not ex
> > ist or no valid version could be found
> > [INFO]
> >

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

> > [INFO] Total time: 1 second
> > [INFO] Finished at: Tue Apr 17 11:39:05 EDT 2007
> > [INFO] Final Memory: 2M/5M
> > [INFO]
> >

> >
> >
> >
> > -
> > 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: [XPATH] Getting a DataObject's Path?


P.S. DataObject.getContainmentProperty() would give the path elements.

On 17/04/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:


Hi,

I've been looking at the SDO Specification
and Javadocs trying to figure out how to get a dataobject's
path (Relative to it's root).

Something like:

String path = DataGraph.getPath(dataObject);

Which would return something like:

"//company/employees[2]/"

Thoughts?

Thanks,
- Ole



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

[jira] Created: (TUSCANY-1216) Sequence.add(index,value) is not working due to a type mismatch problem

2007-04-17 Thread David T. Adcox (JIRA)

Sequence.add(index,value) is not working due to a type mismatch problem
---

 Key: TUSCANY-1216
 URL: https://issues.apache.org/jira/browse/TUSCANY-1216
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M3
 Environment: n/a
Reporter: David T. Adcox
 Fix For: Java-SDO-M3


The sample below demonstrates a problem found when adding properties into a 
sequence object using the property index.  The issue seems to be related to how 
the property index is acquired and how that index is subsequently used by the 
BasicSequence object.  BasicSequence.add(int, Object) uses the EMF 
eClass().getEstructuralFeature(int) method to retrieve the property, based on 
the index.  The list of properties kept in this array, includes both 'explicit' 
properties defined by the schema or inline code, and 'implicit' properties 
defined by the Tuscany SDO framework (in this case, I believe it is actually 
the underlying EMF that is creating the implicit property).  Once such implicit 
property is the 'multi' property, defined when a type is identified as 
containing a sequence.  The core issue here is that the code used to identify 
the index to use is based on an array of SDO properties, which do not include 
the implicit properties.  So, the index is derived from a different array than 
the one being used for updating, this is the root cause of this problem.  A 
change to how the BasicSequence object obtains the indexed property is probably 
the correct remedy for this issue.

Sample code:

public static void main(String[] args) 
{
String URI = "http://example.com/test";;

HelperContext scope = SDOUtil.createHelperContext();
TypeHelper typeHelper = scope.getTypeHelper();
Type integerType = typeHelper.getType("commonj.sdo", "Integer");

DataObject wrapperType = scope.getDataFactory().create("commonj.sdo", 
"Type");
wrapperType.set("uri", URI );
wrapperType.set("name", "Wrapper");
wrapperType.setBoolean("sequenced", true);

// Create Property
DataObject intProperty = wrapperType.createDataObject("property");
intProperty.set("name", "Value");
intProperty.set("type", integerType);
intProperty.setBoolean("many", true);

// register the wrapper
typeHelper.define(wrapperType);

// get registered type
Type testType = typeHelper.getType(URI,"Wrapper");

// Create an instance of the Wrapper Type
DataObject testDO = scope.getDataFactory().create(testType);

// Update the sequence using the index
List properties = testType.getProperties();
int index = properties.indexOf(testDO.getInstanceProperty("Value"));
Sequence sequence = testDO.getSequence();
Integer v = new Integer(10);
sequence.add(index,v);
}

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


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

Re: [XPATH] Getting a DataObject's Path?


You'd need to ascend the hierarchy with DataObject.getContainer() until you
reach the root (null return),  and assemble the path string.

Regards, Kelvin.

On 17/04/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:


Hi,

I've been looking at the SDO Specification
and Javadocs trying to figure out how to get a dataobject's
path (Relative to it's root).

Something like:

String path = DataGraph.getPath(dataObject);

Which would return something like:

"//company/employees[2]/"

Thoughts?

Thanks,
- Ole



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

Re: SDO project build failure

Thanks Kelvin. I removed it and that fixed it for me. It must have been 
corrupted

Frank.

"kelvin goodson" <[EMAIL PROTECTED]> wrote on 04/17/2007 02:29:24 
PM:

> It builds cleanly for me, even after removing
> ~\.m2\repository\org\apache\maven\plugins\maven-dependency-plugin,  so 
was
> this an intermittent thing?
> 
> regards, Kelvin.
> 
> 
> 
> 
> On 17/04/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I just did an svn update of the SDO project, and now it fails to 
build.
> > Any ideas?
> >
> > Thanks,
> > Frank.
> >
> > [INFO] Scanning for projects...
> > [INFO] Reactor build order:
> > [INFO]   Tuscany SDO Implementation Project
> > [INFO]   Tuscany SDO Implementation
> > [INFO]   Tuscany SDO Tools
> > [INFO]   Tuscany SDO Maven Plugin
> > [INFO]
> > 
-
> > ---
> > [INFO] Building Tuscany SDO Implementation Project
> > [INFO]task-segment: [install]
> > [INFO]
> > 
-
> > ---
> > [INFO] Skipping missing optional mojo:
> > org.apache.maven.plugins:maven-site-plugi
> > n:attach-descriptor
> > [INFO]
> > 

> > [ERROR] BUILD ERROR
> > [INFO]
> > 

> > [INFO] The plugin ' org.apache.maven.plugins:maven-dependency-plugin' 
does
> > not ex
> > ist or no valid version could be found
> > [INFO]
> > 

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

> > [INFO] Total time: 1 second
> > [INFO] Finished at: Tue Apr 17 11:39:05 EDT 2007
> > [INFO] Final Memory: 2M/5M
> > [INFO]
> > 

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

[XPATH] Getting a DataObject's Path?


Hi,

I've been looking at the SDO Specification
and Javadocs trying to figure out how to get a dataobject's
path (Relative to it's root).

Something like:

String path = DataGraph.getPath(dataObject);

Which would return something like:

"//company/employees[2]/"

Thoughts?

Thanks,
- Ole



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

Re: Require more context for URLArtifactProcessorExtension.read()


Hi,

I think you already got it right. I want to contribute a processor to scan 
the classes to figure out available generated SDO factory interface/class. 
During the "read" phase, the processor will capture the classname by a 
naming pattern. The class will be loaded during "resolve" phase and the 
factory will be registered with a HelperContext.


I see two requirements here:
1) read: Pass in the URI of the artifact which can be used to derive the 
class name
2) resolve: Pass in a contribution classloader which can be used to resolve 
java classes


Thanks,
Raymond

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

To: 
Sent: Tuesday, April 17, 2007 11:22 AM
Subject: Re: Require more context for URLArtifactProcessorExtension.read()



Raymond Feng wrote:

Hi,

When I try to add a URLArtifactProcessorExtension to introspect java 
classes, I found it impossible to get the class name as only the URL of 
the class file is passed to the read() method. To provide such context, I 
suggest that we pass in the DeployedArtifact (which contains the URL) 
instead of URL to the read() method.


Do you agree or do you have a better way?

Thanks,
Raymond



Could you give more context as well? :) and describe what you're trying to 
do?


Are you trying to derive a class name from the file name? Are you going to 
load or read the class file and could you find the class name from its 
contents then?


It's a little difficult to try to answer without more context, but in 
general I would prefer for ArtifactProcessors not to have to know the 
structure of the Contribution or the DeployedArtifacts that represent it. 
If you need to know the base URL of the contribution and the path of the 
given Artifact inside it, then maybe we could pass these two parameters to 
the read() method, it would be better than passing the whole 
DeployedArtifact and have the read() method dig into it.


But again, before we do that, could you describe your use case? and then 
hopefully we can find a good solution for it. Thanks.


--
Jean-Sebastien


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




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

Re: Require more context for URLArtifactProcessorExtension.read()


Raymond Feng wrote:

Hi,

When I try to add a URLArtifactProcessorExtension to introspect java 
classes, I found it impossible to get the class name as only the URL 
of the class file is passed to the read() method. To provide such 
context, I suggest that we pass in the DeployedArtifact (which 
contains the URL) instead of URL to the read() method.


Do you agree or do you have a better way?

Thanks,
Raymond



Could you give more context as well? :) and describe what you're trying 
to do?


Are you trying to derive a class name from the file name? Are you going 
to load or read the class file and could you find the class name from 
its contents then?


It's a little difficult to try to answer without more context, but in 
general I would prefer for ArtifactProcessors not to have to know the 
structure of the Contribution or the DeployedArtifacts that represent 
it. If you need to know the base URL of the contribution and the path of 
the given Artifact inside it, then maybe we could pass these two 
parameters to the read() method, it would be better than passing the 
whole DeployedArtifact and have the read() method dig into it.


But again, before we do that, could you describe your use case? and then 
hopefully we can find a good solution for it. Thanks.


--
Jean-Sebastien


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

Re: How can I get the Component URI for a service?

Hi,

Please see my comments inline.

Thanks,
Raymond

- Original Message - 
From: "ant elder" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, April 17, 2007 10:18 AM
Subject: Re: How can I get the Component URI for a service?

And two further questions:

- Line 2375, page 53 of the assembly spec says if a component only has a
single service then the Service Binding URI is not used, is there any way 
to

tell if the component has multiple services from the BindingBuilder build
method? (note, I'm assuming this is talking about multiple SCDL 
elements on the component not a component exposing multiple services?)

My understanding is that it really talks about the services exposed by a 
component. If there is only one service provided by the component, then 
there's no need to specify the service name. It's also true when we use the 
"target" attribute for

the component reference.

- The section starting at line 2368, page 53 of the assembly spec about
"Servce Binding URI" talks about the binding name but not the service 
name.
Does the service name play any role in the final URI of the exposed 
binding?
In the schema the binding name is optional but the servce name is 
required,
I wondered if  when the binding name is not specified then the service 
name

should be used as the default?

It seems that the spec doesn't answer your question. The same service can 
have more than one bindings. Let's take an example.

baseURI="http://acme.com";
service (name="s1")
   --- binding (name="b1", uri="u1")
   --- binding (name="b2")
service (name="s2")
   --- binding

serviceURI: http://acme.com/

My understanding is that we could get the  by the following order:

1) uri
2) binding name
3) service name if there's only one binding. If there are more than one 
binding, then the either uri or binding name should be provided [my 
imagination :-)]

Then the serviceURIs will be:

s1:
http://acme.com/u1
http://acme.com/b2

s2:
http://acme.com/s2

  ...ant

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

Cool, that works and gets me the name thanks.

Should Component have a URI? The o.a.t.assembly.Component interface
doesn't have a get/setURI which seems to match the schema in the spec, 
but

page 53 line 2362 of the Assembly spec makes it sound like it should.

   ...ant

On 4/17/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> There is a workaround:
>
> SCABinding binding = componentService.getBinding(SCABinding.class)
> Component component = binding.getComponent();
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "ant elder" <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, April 17, 2007 6:44 AM
> Subject: How can I get the Component URI for a service?
>
>
> > The default endpoint for a service using a web service binding should
> be
> > component URI / binding URI, but I can't find a way to get to the
> > Component
> > from a BindingBuilder build method. The CompositeService passed in to
> the
> > build method has a promotedService field which is a ComponentService
> but
> > that doesn't have any reference back to the Component.
> >
> > Any ideas?
> >
> >   ...ant
> >
>
>
> -
> 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: Notifcation of missing extensions


Comments inline.

Raymond Feng wrote:

Hi,

We might have a few options to make it more elegant:

1) By throwing an exception from the extension point when the key 
doesn't hit an entry.

2) The caller will check the null and make a decision on how to proceed.



Option (1) covers critical error cases where it's not possible at all to 
proceed with reading the SCA assembly XML document.


I don't like much option (2) as it will leave users and application 
developers in the dark...


I'd like to suggest a third option:
- Record problems like we have started to do in CompositeUtil, and 
expand on that as discussed in [1].
- After a contribution has been scanned and read, inspect the problems 
list and if we find severe problems, throw an exception, report warnings 
and benign issues using some form of monitoring and/or logging.


Doing this will allow us to defer the handling of these problems out of 
the individual ArtifactProcessors, handle them with more context (as 
we'll have the whole list), and overall provide better error reporting 
to users and application developers, as we'll be able to present a whole 
list instead of throwing up on the first error.


[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16554.html

And for the monitoring/logging, we had a monitoring framework (not 
completely activated ATM). The basic idea is as follows:


1) The class that supports the monitoring will define an interface for 
the monitoring purpose
2) The class use @Monitor annotation to receive an implementation of 
the interface by injection
3) A MonitorFactory is responsible to create a Monitor based on the 
interface


I found it a bit difficult to follow this pattern as the class itself 
have to take care of most of the stuff. Should we explore other 
opportunities such as AOP?


I found our current Monitor stuff difficult to follow as well. I suggest 
that we start a new discussion thread to discuss monitoring in general, 
and try to come up with something that will be more usable and easier to 
adopt through our whole runtime.




Thanks,
Raymond

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

To: "tuscany-dev" 
Sent: Tuesday, April 17, 2007 9:04 AM
Subject: Notifcation of missing extensions


I've been caught out a couple of times now by the runtime silently 
failing
to work properly because I haven't put the correct set of extensions 
on my

classpath. Locally I have just put a printout in to warn me.

DefaultStAXArtifactProcessorExtensionPoint

   public Object read(XMLStreamReader source) throws
ContributionReadException {

   // Delegate to the processor associated with the element qname
   QName name = source.getName();
   StAXArtifactProcessorExtension processor =
(StAXArtifactProcessorExtension)this.getProcessor(name);
   if (processor == null) {
   System.err.print("No extension processor registered for 
element

" + name.toString());
   return null;
   }
   return processor.read(source);
   }

So that if an element is encountered for which there is no loader I 
get to
find out I've made a mistake. So can someone explain how we should be 
doing
logging/montoring in the Tuscany runtime as it would be good to 
report back

to users that this is happening

Regards

Simon




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





--
Jean-Sebastien


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

Re: Problem (?) in sdo2om databinding test case


Hi,

Did you run with "mvn clean install"? It seems that you have some obsolete 
classes in the target folder.


Thanks,
Raymond

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

To: "tuscany-dev" 
Sent: Tuesday, April 17, 2007 10:15 AM
Subject: Problem (?) in sdo2om databinding test case



Just doing a complete build from scratch (repo clean etc.) and I go the
following in the maven build

Running org.apache.tuscany.databinding.sdo2om.DataObject2OMElementTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.011 sec
<<< FA
ILURE!
testTransform(
org.apache.tuscany.databinding.sdo2om.DataObject2OMElementTestCase
)  Time elapsed: 0.891 sec  <<< ERROR!
java.lang.NoSuchFieldError:
org/apache/tuscany/databinding/sdo2om/DataObject2OME
lementTestCase.context
   at
org.apache.tuscany.databinding.sdo2om.DataObject2OMElementTestCase.te
stTransform(DataObject2OMElementTestCase.java:32)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:64)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at junit.framework.TestCase.runTest(TestCase.java:168)
   at junit.framework.TestCase.runBare(TestCase.java:134)
   at junit.framework.TestResult$1.protect(TestResult.java:110)
   at junit.framework.TestResult.runProtected(TestResult.java:128)
   at junit.framework.TestResult.run(TestResult.java:113)

Is anyone else seeing this or should I be looking to start from scratch
again?

Regards

Simon




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

Re: SDO project build failure


It builds cleanly for me, even after removing
~\.m2\repository\org\apache\maven\plugins\maven-dependency-plugin,  so was
this an intermittent thing?

regards, Kelvin.




On 17/04/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:


Hi,

I just did an svn update of the SDO project, and now it fails to build.
Any ideas?

Thanks,
Frank.

[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Tuscany SDO Implementation Project
[INFO]   Tuscany SDO Implementation
[INFO]   Tuscany SDO Tools
[INFO]   Tuscany SDO Maven Plugin
[INFO]
-
---
[INFO] Building Tuscany SDO Implementation Project
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] Skipping missing optional mojo:
org.apache.maven.plugins:maven-site-plugi
n:attach-descriptor
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] The plugin ' org.apache.maven.plugins:maven-dependency-plugin' does
not ex
ist or no valid version could be found
[INFO]

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

[INFO] Total time: 1 second
[INFO] Finished at: Tue Apr 17 11:39:05 EDT 2007
[INFO] Final Memory: 2M/5M
[INFO]




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

Re: Notifcation of missing extensions


Hi,

We might have a few options to make it more elegant:

1) By throwing an exception from the extension point when the key doesn't 
hit an entry.

2) The caller will check the null and make a decision on how to proceed.

And for the monitoring/logging, we had a monitoring framework (not 
completely activated ATM). The basic idea is as follows:


1) The class that supports the monitoring will define an interface for the 
monitoring purpose
2) The class use @Monitor annotation to receive an implementation of the 
interface by injection
3) A MonitorFactory is responsible to create a Monitor based on the 
interface


I found it a bit difficult to follow this pattern as the class itself have 
to take care of most of the stuff. Should we explore other opportunities 
such as AOP?


Thanks,
Raymond

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

To: "tuscany-dev" 
Sent: Tuesday, April 17, 2007 9:04 AM
Subject: Notifcation of missing extensions



I've been caught out a couple of times now by the runtime silently failing
to work properly because I haven't put the correct set of extensions on my
classpath. Locally I have just put a printout in to warn me.

DefaultStAXArtifactProcessorExtensionPoint

   public Object read(XMLStreamReader source) throws
ContributionReadException {

   // Delegate to the processor associated with the element qname
   QName name = source.getName();
   StAXArtifactProcessorExtension processor =
(StAXArtifactProcessorExtension)this.getProcessor(name);
   if (processor == null) {
   System.err.print("No extension processor registered for element
" + name.toString());
   return null;
   }
   return processor.read(source);
   }

So that if an element is encountered for which there is no loader I get to
find out I've made a mistake. So can someone explain how we should be 
doing
logging/montoring in the Tuscany runtime as it would be good to report 
back

to users that this is happening

Regards

Simon




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

Re: How can I get the Component URI for a service?


And two further questions:

- Line 2375, page 53 of the assembly spec says if a component only has a
single service then the Service Binding URI is not used, is there any way to
tell if the component has multiple services from the BindingBuilder build
method? (note, I'm assuming this is talking about multiple SCDL 
elements on the component not a component exposing multiple services?)

- The section starting at line 2368, page 53 of the assembly spec about
"Servce Binding URI" talks about the binding name but not the service name.
Does the service name play any role in the final URI of the exposed binding?
In the schema the binding name is optional but the servce name is required,
I wondered if  when the binding name is not specified then the service name
should be used as the default?

  ...ant

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


Cool, that works and gets me the name thanks.

Should Component have a URI? The o.a.t.assembly.Component interface
doesn't have a get/setURI which seems to match the schema in the spec, but
page 53 line 2362 of the Assembly spec makes it sound like it should.

   ...ant

On 4/17/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> There is a workaround:
>
> SCABinding binding = componentService.getBinding(SCABinding.class)
> Component component = binding.getComponent();
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "ant elder" <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, April 17, 2007 6:44 AM
> Subject: How can I get the Component URI for a service?
>
>
> > The default endpoint for a service using a web service binding should
> be
> > component URI / binding URI, but I can't find a way to get to the
> > Component
> > from a BindingBuilder build method. The CompositeService passed in to
> the
> > build method has a promotedService field which is a ComponentService
> but
> > that doesn't have any reference back to the Component.
> >
> > Any ideas?
> >
> >   ...ant
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Problem (?) in sdo2om databinding test case

2007-04-17 Thread Simon Laws


Just doing a complete build from scratch (repo clean etc.) and I go the
following in the maven build

Running org.apache.tuscany.databinding.sdo2om.DataObject2OMElementTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.011 sec
<<< FA
ILURE!
testTransform(
org.apache.tuscany.databinding.sdo2om.DataObject2OMElementTestCase
)  Time elapsed: 0.891 sec  <<< ERROR!
java.lang.NoSuchFieldError:
org/apache/tuscany/databinding/sdo2om/DataObject2OME
lementTestCase.context
   at
org.apache.tuscany.databinding.sdo2om.DataObject2OMElementTestCase.te
stTransform(DataObject2OMElementTestCase.java:32)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:64)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at junit.framework.TestCase.runTest(TestCase.java:168)
   at junit.framework.TestCase.runBare(TestCase.java:134)
   at junit.framework.TestResult$1.protect(TestResult.java:110)
   at junit.framework.TestResult.runProtected(TestResult.java:128)
   at junit.framework.TestResult.run(TestResult.java:113)

Is anyone else seeing this or should I be looking to start from scratch
again?

Regards

Simon

Re: Databinding problem with WS when service or reference uses interface.java instead of WSDL


Hi,

After the investigation, I found the issue is not really caused by the 
databinding. For bindings like ws, we have the interface contract for the 
binding itself (from the WSDL portType used by the endpoint) in addition to 
the  on the composite service or reference. If the
binding interface contract is not present, then the one from the composite 
service/reference should be used.


I fixed the problem under r529675. Please review.

Thanks,
Raymond

- Original Message - 
From: "ant elder" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, April 17, 2007 3:49 AM
Subject: Databinding problem with WS when service or reference uses 
interface.java instead of WSDL




There's a problem with the databinding when using web services and the
service or reference uses interface.java. It looks like the the
wrapping/unwrapping goes wrong and ends up with a ClassCastException  in
SimpleType2JavaTransformer. Any ideas on how to fix this? I've separated
this case out of the wsdl itests into a single test to make it easier to
debug, see:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdl/src/test/java/org/apache/tuscany/sca/itest/DBFailTestCase.java

  ...ant




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

Notifcation of missing extensions

2007-04-17 Thread Simon Laws


I've been caught out a couple of times now by the runtime silently failing
to work properly because I haven't put the correct set of extensions on my
classpath. Locally I have just put a printout in to warn me.

DefaultStAXArtifactProcessorExtensionPoint

   public Object read(XMLStreamReader source) throws
ContributionReadException {

   // Delegate to the processor associated with the element qname
   QName name = source.getName();
   StAXArtifactProcessorExtension processor =
(StAXArtifactProcessorExtension)this.getProcessor(name);
   if (processor == null) {
   System.err.print("No extension processor registered for element
" + name.toString());
   return null;
   }
   return processor.read(source);
   }

So that if an element is encountered for which there is no loader I get to
find out I've made a mistake. So can someone explain how we should be doing
logging/montoring in the Tuscany runtime as it would be good to report back
to users that this is happening

Regards

Simon

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Hi Andy,

Maybe this is a stupid question (my junit ignorance showing through :-), 
but couldn't you have run your simple test harness (main) even if MyTest 
extended from TestCase? Is there something about having the base class 
that prevents you from simply invoking the test methods directly?

Frank.

"Andy Grove" <[EMAIL PROTECTED]> wrote on 04/17/2007 11:21:49 AM:

> 
> To better understand this myself, I just put a simple test case together
> using junit 4.1 with annotations and made use of the junit assertion
> calls e.g.
> 
> public class MyTest {
> @Test
> public void testSomething() {
> // this test will fail
> assertEquals( "numbers are same", 1, 2 );
> }
> }
> 
> I then wrote a simple test harness to load the test class using
> reflection and invoke any methods starting with "test". 
> 
>  public static void main(String[] args) throws Exception {
> Class testClass = Class.forName( "test.MyTest" );
> Object testObject = testClass.newInstance();
> Method method[] = testClass.getMethods();
> for (int i = 0; i < method.length; i++) {
> if (method[i].getName().startsWith("test")) {
> System.out.println("Running " + method[i].getName());
> try {
> method[i].invoke( testObject );
> } catch (Throwable th) {
> th.printStackTrace();
> }
> }
> }
> }
> 
> This ran the above test method and caught the following exception:
> 
> java.lang.AssertionError: numbers are same expected:<1> but was:<2>
> 
> For me, this seems to demonstrate that using junit 4.1 style tests will
> allow people to call their tests from their own test harnesses without
> requiring junit-users to have to go to any special effort. The junit
> Assert.* methods simply check some criteria and then call fail() if that
> criteria is false. The fail() method simply throws an AssertionError. 
> 
> Writing the CTS tests using junit with annotations (rather than
> extending TestCase) does seem to provide everything required to allow
> users to run the tests outside of junit, albeit with a dependency on
> junit.jar but I don't see why that would be a problem for anyone? We
> could write our own versions of the assert* methods but they would do
> exactly the same thing as the junit implementation so this seems rather
> pointless.
> 
> My conclusion is that we should continue writing SDO CTS tests using
> junit, but ensure we use the annotation pattern rather than extending
> TestCase. Is everyone happy with this?
> 
> Thanks,
> 
> Andy.
> 
> 
> -Original Message-
> From: kelvin goodson [mailto:[EMAIL PROTECTED] 
> Sent: 17 April 2007 14:53
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes don't inherit from TestCase
> 
> Yes, I was about to write to the list on this subject. I'd like to
> understand more of how the test harness agnosticism was intended, and
> whether its really practical. As it stands there is still junit through
> and through,  in particular, each test method still references junit
> assertion calls.  Even if we could do assertions from annotations (as
> per JML pre and post conditions),  we still have all the junit imports.
> If that were possible, then I guess each of the test methods could be
> invoked by something other than the junit test harness,  but they would
> have trouble asserting anything about the success of the method
> invocation,  since there are no artifacts available before or after the
> method invocation to make assertions about.
> 
> Kelvin
> 
> On 17/04/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> > If the goal is to make the tests "harness agnostic", then I don't see 
> > much difference between a JUnit-specific inheritance dependency and a 
> > JUnit-specific annotation dependency.  Is the annotation dependency 
> > less troublesome for some reason?
> >
> >Simon
> >
> > kelvin goodson wrote:
> >
> > > Thanks for this Andy,  I'll play with it tomorrow.
> > >
> > > Regards, Kelvin.
> > >
> > > On 16/04/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> > >
> > >>
> > >>
> > >> I believe you just need to annotate the setUp method with @Before. 
> > >> This is described in the junit cookbook, here:
> > >>
> > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > >>
> > >> I'm currently working on submitting some more XSD test cases in the
> 
> > >> CTS so I'll try this method out. Hopefully I can then remove the 
> > >> current dependency on TestCase in those tests.
> > >>
> > >> Thanks,
> > >>
> > >> Andy.
> > >>
> > >>
> > >> -Original Message-
> > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf
> > >> Of kelvin goodson
> > >> Sent: 16 April 2007 14:42
> > >> To: tuscany-dev@ws.apache.org
> > >> Cc: Robbie Minshall
> > >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> > classes
> > >> don'

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Hi Andy,

Java allows you make something more visible in a derived class than in the 
base, so declaring setUp() public in MyTest wouldn't seem to be a problem. 


Frank

"Andy Grove" <[EMAIL PROTECTED]> wrote on 04/17/2007 12:19:37 PM:

> Hi Frank,
> 
> The TestCase class defines setUp and tearDown as protected methods,
> forcing the child class to also declare them as protected methods and
> this means they can't be loaded using reflection.
> 
> Using junit 4.1 means we can declare the methods as public.
> 
> Thanks,
> 
> Andy.
> 
> -Original Message-
> From: Frank Budinsky [mailto:[EMAIL PROTECTED] 
> Sent: 17 April 2007 17:03
> To: tuscany-dev@ws.apache.org
> Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes don't inherit from TestCase
> 
> Hi Andy,
> 
> Maybe this is a stupid question (my junit ignorance showing through :-),
> but couldn't you have run your simple test harness (main) even if MyTest
> extended from TestCase? Is there something about having the base class
> that prevents you from simply invoking the test methods directly?
> 
> Frank.
> 
> "Andy Grove" <[EMAIL PROTECTED]> wrote on 04/17/2007 11:21:49 AM:
> 
> > 
> > To better understand this myself, I just put a simple test case 
> > together using junit 4.1 with annotations and made use of the junit 
> > assertion calls e.g.
> > 
> > public class MyTest {
> > @Test
> > public void testSomething() {
> > // this test will fail
> > assertEquals( "numbers are same", 1, 2 );
> > }
> > }
> > 
> > I then wrote a simple test harness to load the test class using 
> > reflection and invoke any methods starting with "test".
> > 
> >  public static void main(String[] args) throws Exception {
> > Class testClass = Class.forName( "test.MyTest" );
> > Object testObject = testClass.newInstance();
> > Method method[] = testClass.getMethods();
> > for (int i = 0; i < method.length; i++) {
> > if (method[i].getName().startsWith("test")) {
> > System.out.println("Running " + method[i].getName());
> > try {
> > method[i].invoke( testObject );
> > } catch (Throwable th) {
> > th.printStackTrace();
> > }
> > }
> > }
> > }
> > 
> > This ran the above test method and caught the following exception:
> > 
> > java.lang.AssertionError: numbers are same expected:<1> but was:<2>
> > 
> > For me, this seems to demonstrate that using junit 4.1 style tests 
> > will allow people to call their tests from their own test harnesses 
> > without requiring junit-users to have to go to any special effort. The
> 
> > junit
> > Assert.* methods simply check some criteria and then call fail() if 
> > that criteria is false. The fail() method simply throws an
> AssertionError.
> > 
> > Writing the CTS tests using junit with annotations (rather than 
> > extending TestCase) does seem to provide everything required to allow 
> > users to run the tests outside of junit, albeit with a dependency on 
> > junit.jar but I don't see why that would be a problem for anyone? We 
> > could write our own versions of the assert* methods but they would do 
> > exactly the same thing as the junit implementation so this seems 
> > rather pointless.
> > 
> > My conclusion is that we should continue writing SDO CTS tests using 
> > junit, but ensure we use the annotation pattern rather than extending 
> > TestCase. Is everyone happy with this?
> > 
> > Thanks,
> > 
> > Andy.
> > 
> > 
> > -Original Message-
> > From: kelvin goodson [mailto:[EMAIL PROTECTED]
> > Sent: 17 April 2007 14:53
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when 
> > classes don't inherit from TestCase
> > 
> > Yes, I was about to write to the list on this subject. I'd like to 
> > understand more of how the test harness agnosticism was intended, and 
> > whether its really practical. As it stands there is still junit 
> > through and through,  in particular, each test method still references
> 
> > junit assertion calls.  Even if we could do assertions from 
> > annotations (as per JML pre and post conditions),  we still have all
> the junit imports.
> > If that were possible, then I guess each of the test methods could be 
> > invoked by something other than the junit test harness,  but they 
> > would have trouble asserting anything about the success of the method 
> > invocation,  since there are no artifacts available before or after 
> > the method invocation to make assertions about.
> > 
> > Kelvin
> > 
> > On 17/04/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > >
> > > If the goal is to make the tests "harness agnostic", then I don't 
> > > see much difference between a JUnit-specific inheritance dependency 
> > > and a JUnit-specific annotation dependency.  Is the annotation 
> > > dependency less troublesome for some r

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Hi Frank,

The TestCase class defines setUp and tearDown as protected methods,
forcing the child class to also declare them as protected methods and
this means they can't be loaded using reflection.

Using junit 4.1 means we can declare the methods as public.

Thanks,

Andy.

-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED] 
Sent: 17 April 2007 17:03
To: tuscany-dev@ws.apache.org
Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

Hi Andy,

Maybe this is a stupid question (my junit ignorance showing through :-),
but couldn't you have run your simple test harness (main) even if MyTest
extended from TestCase? Is there something about having the base class
that prevents you from simply invoking the test methods directly?

Frank.

"Andy Grove" <[EMAIL PROTECTED]> wrote on 04/17/2007 11:21:49 AM:

> 
> To better understand this myself, I just put a simple test case 
> together using junit 4.1 with annotations and made use of the junit 
> assertion calls e.g.
> 
> public class MyTest {
> @Test
> public void testSomething() {
> // this test will fail
> assertEquals( "numbers are same", 1, 2 );
> }
> }
> 
> I then wrote a simple test harness to load the test class using 
> reflection and invoke any methods starting with "test".
> 
>  public static void main(String[] args) throws Exception {
> Class testClass = Class.forName( "test.MyTest" );
> Object testObject = testClass.newInstance();
> Method method[] = testClass.getMethods();
> for (int i = 0; i < method.length; i++) {
> if (method[i].getName().startsWith("test")) {
> System.out.println("Running " + method[i].getName());
> try {
> method[i].invoke( testObject );
> } catch (Throwable th) {
> th.printStackTrace();
> }
> }
> }
> }
> 
> This ran the above test method and caught the following exception:
> 
> java.lang.AssertionError: numbers are same expected:<1> but was:<2>
> 
> For me, this seems to demonstrate that using junit 4.1 style tests 
> will allow people to call their tests from their own test harnesses 
> without requiring junit-users to have to go to any special effort. The

> junit
> Assert.* methods simply check some criteria and then call fail() if 
> that criteria is false. The fail() method simply throws an
AssertionError.
> 
> Writing the CTS tests using junit with annotations (rather than 
> extending TestCase) does seem to provide everything required to allow 
> users to run the tests outside of junit, albeit with a dependency on 
> junit.jar but I don't see why that would be a problem for anyone? We 
> could write our own versions of the assert* methods but they would do 
> exactly the same thing as the junit implementation so this seems 
> rather pointless.
> 
> My conclusion is that we should continue writing SDO CTS tests using 
> junit, but ensure we use the annotation pattern rather than extending 
> TestCase. Is everyone happy with this?
> 
> Thanks,
> 
> Andy.
> 
> 
> -Original Message-
> From: kelvin goodson [mailto:[EMAIL PROTECTED]
> Sent: 17 April 2007 14:53
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when 
> classes don't inherit from TestCase
> 
> Yes, I was about to write to the list on this subject. I'd like to 
> understand more of how the test harness agnosticism was intended, and 
> whether its really practical. As it stands there is still junit 
> through and through,  in particular, each test method still references

> junit assertion calls.  Even if we could do assertions from 
> annotations (as per JML pre and post conditions),  we still have all
the junit imports.
> If that were possible, then I guess each of the test methods could be 
> invoked by something other than the junit test harness,  but they 
> would have trouble asserting anything about the success of the method 
> invocation,  since there are no artifacts available before or after 
> the method invocation to make assertions about.
> 
> Kelvin
> 
> On 17/04/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> > If the goal is to make the tests "harness agnostic", then I don't 
> > see much difference between a JUnit-specific inheritance dependency 
> > and a JUnit-specific annotation dependency.  Is the annotation 
> > dependency less troublesome for some reason?
> >
> >Simon
> >
> > kelvin goodson wrote:
> >
> > > Thanks for this Andy,  I'll play with it tomorrow.
> > >
> > > Regards, Kelvin.
> > >
> > > On 16/04/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> > >
> > >>
> > >>
> > >> I believe you just need to annotate the setUp method with
@Before. 
> > >> This is described in the junit cookbook, here:
> > >>
> > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > >>
> > >> I'm currently working on submitting some

[DAS] Performance / API / Spec


Hi Guys,

I have a few performance related
questions with respect to change
summary processing (Really spec related - hope it's ok that I float it 
here).


I just looked at the Change
summary API and it looks like
the DataGraph sets the
isDeleted and isCreated
flags on each DataObject instance
that it creates or deletes, and
then it adds them to the change summary.

It seems like change summary
processing would perform better
if the Change summary had CUD lists.

So one list for:
- Created DataObjects
- Deleted DataObjects
- Update DataObjects

Then these lists could be processed directly by the
DAS and it would not have to check what type CUD
was done for each object.

Then the DataGraph only adds objects to these lists
and does not need to set any flags, which means that
during processing the flags don't need to be checked
in order to perform the right type of processing.

I'm still getting my feet wet here, but I thought I'd throw this out 
there, since to me it seems like it's simpler and more light weight.


Thoughts?

Thanks,
- Ole






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

Re: How can I get the Component URI for a service?


Cool, that works and gets me the name thanks.

Should Component have a URI? The o.a.t.assembly.Component interface doesn't
have a get/setURI which seems to match the schema in the spec, but page 53
line 2362 of the Assembly spec makes it sound like it should.

  ...ant

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


Hi,

There is a workaround:

SCABinding binding = componentService.getBinding(SCABinding.class)
Component component = binding.getComponent();

Thanks,
Raymond

- Original Message -
From: "ant elder" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 17, 2007 6:44 AM
Subject: How can I get the Component URI for a service?


> The default endpoint for a service using a web service binding should be
> component URI / binding URI, but I can't find a way to get to the
> Component
> from a BindingBuilder build method. The CompositeService passed in to
the
> build method has a promotedService field which is a ComponentService but
> that doesn't have any reference back to the Component.
>
> Any ideas?
>
>   ...ant
>


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

SDO project build failure

Hi,

I just did an svn update of the SDO project, and now it fails to build. 
Any ideas?

Thanks,
Frank.

[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Tuscany SDO Implementation Project
[INFO]   Tuscany SDO Implementation
[INFO]   Tuscany SDO Tools
[INFO]   Tuscany SDO Maven Plugin
[INFO] 
-
---
[INFO] Building Tuscany SDO Implementation Project
[INFO]task-segment: [install]
[INFO] 
-
---
[INFO] Skipping missing optional mojo: 
org.apache.maven.plugins:maven-site-plugi
n:attach-descriptor
[INFO] 

[ERROR] BUILD ERROR
[INFO] 

[INFO] The plugin 'org.apache.maven.plugins:maven-dependency-plugin' does 
not ex
ist or no valid version could be found
[INFO] 

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

[INFO] Total time: 1 second
[INFO] Finished at: Tue Apr 17 11:39:05 EDT 2007
[INFO] Final Memory: 2M/5M
[INFO] 




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

[jira] Updated: (TUSCANY-826) Containment cycle should result in Exception

2007-04-17 Thread Brian Murray (JIRA)


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

Brian Murray updated TUSCANY-826:
-

Attachment: Updated826.zip

Needed to update the statically created package (which had been com.sdo ) 
to be com.example

> Containment cycle should result in Exception
> 
>
> Key: TUSCANY-826
> URL: https://issues.apache.org/jira/browse/TUSCANY-826
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Mx
> Environment: Windows XP, both Sun and IBM JVMs
>Reporter: Brian Murray
> Fix For: Java-SDO-Mx
>
> Attachments: 826.patch, 826.zip, ContainmentCycle.patch, 
> ContainmentCycleError.java, ContainmentTest.zip, Updated826.zip, 
> Updated826.zip
>
>
> Near the bottom of page 19 in the 2.0.1 specification it is stated that 
> "Containment cannot have cycles.  If a set or add would create a containment 
> cycle an exception is thrown."
> However, I have found that no such exception is thrown.  I will attach a test 
> case showing the creation of (and the potential to infinitely loop through) a 
> containment cycle.

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


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

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

To better understand this myself, I just put a simple test case together
using junit 4.1 with annotations and made use of the junit assertion
calls e.g.

public class MyTest {
@Test
public void testSomething() {
// this test will fail
assertEquals( "numbers are same", 1, 2 );
}
}

I then wrote a simple test harness to load the test class using
reflection and invoke any methods starting with "test". 

 public static void main(String[] args) throws Exception {
Class testClass = Class.forName( "test.MyTest" );
Object testObject = testClass.newInstance();
Method method[] = testClass.getMethods();
for (int i = 0; i < method.length; i++) {
if (method[i].getName().startsWith("test")) {
System.out.println("Running " + method[i].getName());
try {
method[i].invoke( testObject );
} catch (Throwable th) {
th.printStackTrace();
}
}
}
}

This ran the above test method and caught the following exception:

java.lang.AssertionError: numbers are same expected:<1> but was:<2>

For me, this seems to demonstrate that using junit 4.1 style tests will
allow people to call their tests from their own test harnesses without
requiring junit-users to have to go to any special effort. The junit
Assert.* methods simply check some criteria and then call fail() if that
criteria is false. The fail() method simply throws an AssertionError. 

Writing the CTS tests using junit with annotations (rather than
extending TestCase) does seem to provide everything required to allow
users to run the tests outside of junit, albeit with a dependency on
junit.jar but I don't see why that would be a problem for anyone? We
could write our own versions of the assert* methods but they would do
exactly the same thing as the junit implementation so this seems rather
pointless.

My conclusion is that we should continue writing SDO CTS tests using
junit, but ensure we use the annotation pattern rather than extending
TestCase. Is everyone happy with this?

Thanks,

Andy.

-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED] 
Sent: 17 April 2007 14:53
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

Yes, I was about to write to the list on this subject. I'd like to
understand more of how the test harness agnosticism was intended, and
whether its really practical. As it stands there is still junit through
and through,  in particular, each test method still references junit
assertion calls.  Even if we could do assertions from annotations (as
per JML pre and post conditions),  we still have all the junit imports.
If that were possible, then I guess each of the test methods could be
invoked by something other than the junit test harness,  but they would
have trouble asserting anything about the success of the method
invocation,  since there are no artifacts available before or after the
method invocation to make assertions about.

Kelvin

On 17/04/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> If the goal is to make the tests "harness agnostic", then I don't see 
> much difference between a JUnit-specific inheritance dependency and a 
> JUnit-specific annotation dependency.  Is the annotation dependency 
> less troublesome for some reason?
>
>Simon
>
> kelvin goodson wrote:
>
> > Thanks for this Andy,  I'll play with it tomorrow.
> >
> > Regards, Kelvin.
> >
> > On 16/04/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> >
> >>
> >>
> >> I believe you just need to annotate the setUp method with @Before. 
> >> This is described in the junit cookbook, here:
> >>
> >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> >>
> >> I'm currently working on submitting some more XSD test cases in the

> >> CTS so I'll try this method out. Hopefully I can then remove the 
> >> current dependency on TestCase in those tests.
> >>
> >> Thanks,
> >>
> >> Andy.
> >>
> >>
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf
> >> Of kelvin goodson
> >> Sent: 16 April 2007 14:42
> >> To: tuscany-dev@ws.apache.org
> >> Cc: Robbie Minshall
> >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes
> >> don't inherit from TestCase
> >>
> >> Hi,
> >> I'm looking at doing some work in the CTS. I was looking back at 
> >> Robbie's attached description about how to keep the tests "harness 
> >> agnostic".  I'm assuming that this is still a goal of the CTS 
> >> although
> I
> >> may have missed something in my catching up. In my quest to make 
> >> the
> CTS
> >> better I note that a number of the test case classes still extend 
> >> the junit TestCase class.
> >> This is true for all test classes that have a setUp() method. One 
> >> that doesn't inherit from TestCase is XSDSerializationTest,  and 
> >> adding a setUp

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Andy,
 that's really helpful.  I guess my problem was, and still is to some
extent, knowing whether reliance upon the junit.jar is acceptable to the set
of people we are trying to cater for.  I think your example has made
something clear to me though,  which is that our prime aim would be to cater
for the junit harness or anyone's home grown harness,  but not necessarily
another 3rd party harness.  Do you think this is what the original intention
of the meaning of "harness agnostic" is?

Regards, Kelvin.

On 17/04/07, Andy Grove <[EMAIL PROTECTED]> wrote:

To better understand this myself, I just put a simple test case together
using junit 4.1 with annotations and made use of the junit assertion
calls e.g.

public class MyTest {
@Test
public void testSomething() {
// this test will fail
assertEquals( "numbers are same", 1, 2 );
}
}

I then wrote a simple test harness to load the test class using
reflection and invoke any methods starting with "test".

public static void main(String[] args) throws Exception {
Class testClass = Class.forName( "test.MyTest" );
Object testObject = testClass.newInstance();
Method method[] = testClass.getMethods();
for (int i = 0; i < method.length; i++) {
if (method[i].getName().startsWith("test")) {
System.out.println("Running " + method[i].getName());
try {
method[i].invoke( testObject );
} catch (Throwable th) {
th.printStackTrace();
}
}
}
}

This ran the above test method and caught the following exception:

java.lang.AssertionError: numbers are same expected:<1> but was:<2>

For me, this seems to demonstrate that using junit 4.1 style tests will
allow people to call their tests from their own test harnesses without
requiring junit-users to have to go to any special effort. The junit
Assert.* methods simply check some criteria and then call fail() if that
criteria is false. The fail() method simply throws an AssertionError.

Writing the CTS tests using junit with annotations (rather than
extending TestCase) does seem to provide everything required to allow
users to run the tests outside of junit, albeit with a dependency on
junit.jar but I don't see why that would be a problem for anyone? We
could write our own versions of the assert* methods but they would do
exactly the same thing as the junit implementation so this seems rather
pointless.

My conclusion is that we should continue writing SDO CTS tests using
junit, but ensure we use the annotation pattern rather than extending
TestCase. Is everyone happy with this?

Thanks,

Andy.

-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: 17 April 2007 14:53
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

Yes, I was about to write to the list on this subject. I'd like to
understand more of how the test harness agnosticism was intended, and
whether its really practical. As it stands there is still junit through
and through,  in particular, each test method still references junit
assertion calls.  Even if we could do assertions from annotations (as
per JML pre and post conditions),  we still have all the junit imports.
If that were possible, then I guess each of the test methods could be
invoked by something other than the junit test harness,  but they would
have trouble asserting anything about the success of the method
invocation,  since there are no artifacts available before or after the
method invocation to make assertions about.

Kelvin

On 17/04/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> If the goal is to make the tests "harness agnostic", then I don't see
> much difference between a JUnit-specific inheritance dependency and a
> JUnit-specific annotation dependency.  Is the annotation dependency
> less troublesome for some reason?
>
>Simon
>
> kelvin goodson wrote:
>
> > Thanks for this Andy,  I'll play with it tomorrow.
> >
> > Regards, Kelvin.
> >
> > On 16/04/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> >
> >>
> >>
> >> I believe you just need to annotate the setUp method with @Before.
> >> This is described in the junit cookbook, here:
> >>
> >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> >>
> >> I'm currently working on submitting some more XSD test cases in the

> >> CTS so I'll try this method out. Hopefully I can then remove the
> >> current dependency on TestCase in those tests.
> >>
> >> Thanks,
> >>
> >> Andy.
> >>
> >>
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf
> >> Of kelvin goodson
> >> Sent: 16 April 2007 14:42
> >> To: tuscany-dev@ws.apache.org
> >> Cc: Robbie Minshall
> >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes
> >> don't inherit from TestCase
> >>
> >> Hi,
> >> I'm looking at doing

[jira] Resolved: (TUSCANY-1210) XSDComplexTypeTest

2007-04-17 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson resolved TUSCANY-1210.
-

   Resolution: Fixed
Fix Version/s: Java-SDO-CTS-Mx

Added, tests, thanks Andy

> XSDComplexTypeTest
> --
>
> Key: TUSCANY-1210
> URL: https://issues.apache.org/jira/browse/TUSCANY-1210
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Community Test Suite
>Reporter: Andy Grove
> Fix For: Java-SDO-CTS-Mx
>
> Attachments: complexTypeXsdTests.zip
>
>
> New test case to test spec-compliance of SDO types created from XSD complex 
> types. The patch for JIRA 1209 must be applied first as it adds a new method 
> to XSDBaseTestCase that this new test requires.
> The attached "patch" is simply a zip of the new files and should be extracted 
> from the root of the cts module.

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


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

[jira] Commented: (TUSCANY-1204) Support for @requires annotation and requires attribute

2007-04-17 Thread Mark I. Dinges (JIRA)


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

Mark I. Dinges commented on TUSCANY-1204:
-

Your adaptaion of the test case I supplied appears to do the same type of test. 
Based on the parts changed it does not seem that you put the support in for the 
handling of the requires attribute in the XML/SCDL. Is this the case? Do you 
want a new JIRA for that work? Should I reopen this JIRA? Are you adding in 
under another JIRA?

> Support for @requires annotation and requires attribute
> ---
>
> Key: TUSCANY-1204
> URL: https://issues.apache.org/jira/browse/TUSCANY-1204
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Model
>Reporter: Mark I. Dinges
> Assigned To: Jean-Sebastien Delfino
> Fix For: Java-SCA-Next
>
> Attachments: policyworkdelta.txt
>
>
> The follow patch is to add annotation and attribute suppot to the model. For 
> @Requires annotation on Service implementaion at the class level the intents 
> will be added to the ComponentType model object. For @Requires annotation on 
> the Service implementation at the operation/method level the intents are 
> added to the Operation Model Object. For @Requires annotations on the Service 
> interface at the class level the intents are added to the ServiceContract 
> model object. For @Requires annotations on the Service interface at the 
> operation/method level the intents are added to the Operation model object. 
> For "requires" attribute that is on the Service in the scdl the intents are 
> added to the ServiceDefinition model object. For "requires" attribute that is 
> on the Reference in the scdl the intents are added to the ReferenceDefinition 
> model object. For "requires" attribute that is on the implementation.java in 
> the scdl the intents are added to the Implementation model object.
> I did not want to duplicate code that existed in ServiceProcessor.java so the 
> PolicyProcessor class should be added after the ServiceProcessor in the 
> implementation.scdl. 
> 
>  class="org.apache.tuscany.core.implementation.processor.PolicyProcessor"/>
> 
> PolicyJavaInterfaceProcessor will need to be added as implementation.system 
> Not sure of the most appropiate place to at it with changes that have been 
> happening.

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


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

Re: How can I get the Component URI for a service?


Hi,

There is a workaround:

SCABinding binding = componentService.getBinding(SCABinding.class)
Component component = binding.getComponent();

Thanks,
Raymond

- Original Message - 
From: "ant elder" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, April 17, 2007 6:44 AM
Subject: How can I get the Component URI for a service?



The default endpoint for a service using a web service binding should be
component URI / binding URI, but I can't find a way to get to the 
Component

from a BindingBuilder build method. The CompositeService passed in to the
build method has a promotedService field which is a ComponentService but
that doesn't have any reference back to the Component.

Any ideas?

  ...ant




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

[jira] Commented: (TUSCANY-1212) SDO 2.1 feature: Property.isNullable() and Property.isOpenContent()

2007-04-17 Thread Frank Budinsky (JIRA)


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

Frank Budinsky commented on TUSCANY-1212:
-

Property.isOpenContent() committed in revision 529645. Property.isNullable() is 
still TBD.

> SDO 2.1 feature: Property.isNullable() and Property.isOpenContent()
> ---
>
> Key: TUSCANY-1212
> URL: https://issues.apache.org/jira/browse/TUSCANY-1212
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
>Reporter: Frank Budinsky
>


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


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

[jira] Updated: (TUSCANY-863) CompanyWeb DAS Sample should create and initialize the canned database when app is loaded by first time and db is not available

2007-04-17 Thread Amita Vadhavkar (JIRA)


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

Amita Vadhavkar updated TUSCANY-863:


Attachment: JIRA863-Apr17-Patch-Amita.zip

It has 2 patch files - 1) the utility, 2) the CompanyWeb sample changes using 
this 
utility.

Please review code , readme and let me know the feedback

> CompanyWeb DAS Sample should create and initialize the canned database when 
> app is loaded by first time and db is not available
> ---
>
> Key: TUSCANY-863
> URL: https://issues.apache.org/jira/browse/TUSCANY-863
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS Samples
>Affects Versions: Java-DAS-Mx
>Reporter: Luciano Resende
> Assigned To: Luciano Resende
> Fix For: Java-DAS-Mx
>
> Attachments: JIRA-863-Mar-2-Amita.jar, JIRA863-Apr13-Amita.zip, 
> JIRA863-Apr17-Patch-Amita.zip
>
>
> Today we rely on copying the java/das/samples/companyweb/dasttest database to 
> a tomcat installation, so the canned database is available for DAS sample app 
> companyweb. A better way for doing this would be to have a servlet (dbInit) 
> that would load on app startup and create necessary tables and populate it 
> with canned information if the db is not available. This would make 
> deployment easier, would avoid external dependencies on the sample 
> distribution, and would probably make it easier to execute htmlUnit multiple 
> times, as the htmlUnit could call the servlet to force refresh of the 
> database data.
> For an example on how to do this, please take a look at dbInit servlet in 
> BigBank sample application :
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sampleapps/bigbank/account/src/main/java/bigbank/account/services/accountdb/AccountDBInit.java

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


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

Re: Databinding problem with WS when service or reference uses interface.java instead of WSDL


Hi,

I'll look into this.

Thanks,
Raymond

- Original Message - 
From: "ant elder" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, April 17, 2007 3:49 AM
Subject: Databinding problem with WS when service or reference uses 
interface.java instead of WSDL




There's a problem with the databinding when using web services and the
service or reference uses interface.java. It looks like the the
wrapping/unwrapping goes wrong and ends up with a ClassCastException  in
SimpleType2JavaTransformer. Any ideas on how to fix this? I've separated
this case out of the wsdl itests into a single test to make it easier to
debug, see:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdl/src/test/java/org/apache/tuscany/sca/itest/DBFailTestCase.java

  ...ant




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

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase


Kelvin,

Is it possible to get a copy of Robbie's document that you mentioned in
your earlier email? I didn't see an attachment.

Thanks,

Andy.

-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED] 
Sent: 17 April 2007 14:53
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

Yes, I was about to write to the list on this subject. I'd like to
understand more of how the test harness agnosticism was intended, and
whether its really practical. As it stands there is still junit through
and through,  in particular, each test method still references junit
assertion calls.  Even if we could do assertions from annotations (as
per JML pre and post conditions),  we still have all the junit imports.
If that were possible, then I guess each of the test methods could be
invoked by something other than the junit test harness,  but they would
have trouble asserting anything about the success of the method
invocation,  since there are no artifacts available before or after the
method invocation to make assertions about.

Kelvin

On 17/04/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> If the goal is to make the tests "harness agnostic", then I don't see 
> much difference between a JUnit-specific inheritance dependency and a 
> JUnit-specific annotation dependency.  Is the annotation dependency 
> less troublesome for some reason?
>
>Simon
>
> kelvin goodson wrote:
>
> > Thanks for this Andy,  I'll play with it tomorrow.
> >
> > Regards, Kelvin.
> >
> > On 16/04/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> >
> >>
> >>
> >> I believe you just need to annotate the setUp method with @Before. 
> >> This is described in the junit cookbook, here:
> >>
> >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> >>
> >> I'm currently working on submitting some more XSD test cases in the

> >> CTS so I'll try this method out. Hopefully I can then remove the 
> >> current dependency on TestCase in those tests.
> >>
> >> Thanks,
> >>
> >> Andy.
> >>
> >>
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf
> >> Of kelvin goodson
> >> Sent: 16 April 2007 14:42
> >> To: tuscany-dev@ws.apache.org
> >> Cc: Robbie Minshall
> >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes
> >> don't inherit from TestCase
> >>
> >> Hi,
> >> I'm looking at doing some work in the CTS. I was looking back at 
> >> Robbie's attached description about how to keep the tests "harness 
> >> agnostic".  I'm assuming that this is still a goal of the CTS 
> >> although
> I
> >> may have missed something in my catching up. In my quest to make 
> >> the
> CTS
> >> better I note that a number of the test case classes still extend 
> >> the junit TestCase class.
> >> This is true for all test classes that have a setUp() method. One 
> >> that doesn't inherit from TestCase is XSDSerializationTest,  and 
> >> adding a setUp method to this class doesn't cause junit to invoke 
> >> it in my eclipse environment. I'm trying to work out whether I 
> >> should I expect a 4.1environment to discover and execute the setUp 
> >> method when junit is used in this way. I seem to have Eclipse junit

> >> plugins for 3.8.1 and
> >> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer 
> >> much in the way of configuration, so I can't be sure I'm using 4.1
behaviour.
> >>
> >> I really would like to be XSDSerializationTests to execute setUp so
> that
> >> we can have a fresh HelperContext per test,  and I guess the easy 
> >> way out is to make the test class inherit from TestCase like the 
> >> others, but I'd prefer not to introduce the explicit dependency on 
> >> Junit if I can avoid it.
> >>
> >> Regards Kelvin.
> >>
> >>
> >> On 07/12/06, Robbie Minshall <[EMAIL PROTECTED]> wrote:
> >> >
> >> > This sounds quite good.
> >> >
> >> > I have written some test cases with Brian Murray which I would be

> >> > happy to contribute to tuscany.  Identifying duplication and 
> >> > differences in similar tests would probably be an intersting
> excercise
> >> right off the bat.
> >> >
> >> > One decision that we spent a little time mulling over was the 
> >> > framework to use for our test suite.  Originally we used the much

> >> > loved junit harness which worked well.  Different runtimes ( 
> >> > command line, J2EE Application Server, a Service Container ) have

> >> > different
> >> classloader hierarchies etc.
> >> > Without many modifications to the junit code it was difficult and

> >> > quite ugly testing SDO within the context of a variety of 
> >> > runtimes which the SDO APIs will be used.
> >> >
> >> > We took the approach of writing general test libraries which can 
> >> > then simply be called from a variety of test frameworks such as 
> >> > junit or a simple J2EE or SCA Application test harness.  I like 
> >> > this approach
> for
> >>
> >> > keeping the actual test code very simple,

How can I get the Component URI for a service?


The default endpoint for a service using a web service binding should be
component URI / binding URI, but I can't find a way to get to the Component
from a BindingBuilder build method. The CompositeService passed in to the
build method has a promotedService field which is a ComponentService but
that doesn't have any reference back to the Component.

Any ideas?

  ...ant

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase


Yes, I was about to write to the list on this subject. I'd like to
understand more of how the test harness agnosticism was intended, and
whether its really practical. As it stands there is still junit through and
through,  in particular, each test method still references junit assertion
calls.  Even if we could do assertions from annotations (as per JML pre and
post conditions),  we still have all the junit imports.  If that were
possible, then I guess each of the test methods could be invoked by
something other than the junit test harness,  but they would have trouble
asserting anything about the success of the method invocation,  since there
are no artifacts available before or after the method invocation to make
assertions about.

Kelvin

On 17/04/07, Simon Nash <[EMAIL PROTECTED]> wrote:


If the goal is to make the tests "harness agnostic", then I don't
see much difference between a JUnit-specific inheritance dependency
and a JUnit-specific annotation dependency.  Is the annotation
dependency less troublesome for some reason?

   Simon

kelvin goodson wrote:

> Thanks for this Andy,  I'll play with it tomorrow.
>
> Regards, Kelvin.
>
> On 16/04/07, Andy Grove <[EMAIL PROTECTED]> wrote:
>
>>
>>
>> I believe you just need to annotate the setUp method with @Before. This
>> is described in the junit cookbook, here:
>>
>> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
>>
>> I'm currently working on submitting some more XSD test cases in the CTS
>> so I'll try this method out. Hopefully I can then remove the current
>> dependency on TestCase in those tests.
>>
>> Thanks,
>>
>> Andy.
>>
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
>> Of kelvin goodson
>> Sent: 16 April 2007 14:42
>> To: tuscany-dev@ws.apache.org
>> Cc: Robbie Minshall
>> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes
>> don't inherit from TestCase
>>
>> Hi,
>> I'm looking at doing some work in the CTS. I was looking back at
>> Robbie's attached description about how to keep the tests "harness
>> agnostic".  I'm assuming that this is still a goal of the CTS although
I
>> may have missed something in my catching up. In my quest to make the
CTS
>> better I note that a number of the test case classes still extend the
>> junit TestCase class.
>> This is true for all test classes that have a setUp() method. One that
>> doesn't inherit from TestCase is XSDSerializationTest,  and adding a
>> setUp method to this class doesn't cause junit to invoke it in my
>> eclipse environment. I'm trying to work out whether I should I expect a
>> 4.1environment to discover and execute the setUp method when junit is
>> used in this way. I seem to have Eclipse junit plugins for 3.8.1 and
>> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer much in
>> the way of configuration, so I can't be sure I'm using 4.1 behaviour.
>>
>> I really would like to be XSDSerializationTests to execute setUp so
that
>> we can have a fresh HelperContext per test,  and I guess the easy way
>> out is to make the test class inherit from TestCase like the others,
>> but I'd prefer not to introduce the explicit dependency on Junit if I
>> can avoid it.
>>
>> Regards Kelvin.
>>
>>
>> On 07/12/06, Robbie Minshall <[EMAIL PROTECTED]> wrote:
>> >
>> > This sounds quite good.
>> >
>> > I have written some test cases with Brian Murray which I would be
>> > happy to contribute to tuscany.  Identifying duplication and
>> > differences in similar tests would probably be an intersting
excercise
>> right off the bat.
>> >
>> > One decision that we spent a little time mulling over was the
>> > framework to use for our test suite.  Originally we used the much
>> > loved junit harness which worked well.  Different runtimes ( command
>> > line, J2EE Application Server, a Service Container ) have different
>> classloader hierarchies etc.
>> > Without many modifications to the junit code it was difficult and
>> > quite ugly testing SDO within the context of a variety of runtimes
>> > which the SDO APIs will be used.
>> >
>> > We took the approach of writing general test libraries which can then
>> > simply be called from a variety of test frameworks such as junit or a
>> > simple J2EE or SCA Application test harness.  I like this approach
for
>>
>> > keeping the actual test code very simple, allowing for integration a
>> > variety of test frameworks, and providing ability to test directly
>> > within the different runtimes people care about.
>> >
>> > Any thoughts on this ?
>> >
>> > Robbie
>> >
>> >
>> >
>> >
>> > On 12/1/06, kelvin goodson <[EMAIL PROTECTED] > wrote:
>> > >
>> > > Andy,
>> > >   please attach them to the JIRA for this work and one of us can
>> > > pick them up, thanks.
>> > > Best Regards, Kelvin.
>> > >
>> > > On 01/12/06, Andy Grove (Contractor) <[EMAIL PROTECTED]> wrote:
>> > > >
>> > > >
>> > > > Hi Dan,
>> > > >
>> > > > I was previously working with Kelvin Goodson to donate some junit

[jira] Commented: (TUSCANY-826) Containment cycle should result in Exception

2007-04-17 Thread Brian Murray (JIRA)


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

Brian Murray commented on TUSCANY-826:
--

The only two attachments of interest are Updated826.zip (which contains the 
test case) and 826.patch (which contains the fix). 

> Containment cycle should result in Exception
> 
>
> Key: TUSCANY-826
> URL: https://issues.apache.org/jira/browse/TUSCANY-826
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Mx
> Environment: Windows XP, both Sun and IBM JVMs
>Reporter: Brian Murray
> Fix For: Java-SDO-Mx
>
> Attachments: 826.patch, 826.zip, ContainmentCycle.patch, 
> ContainmentCycleError.java, ContainmentTest.zip, Updated826.zip
>
>
> Near the bottom of page 19 in the 2.0.1 specification it is stated that 
> "Containment cannot have cycles.  If a set or add would create a containment 
> cycle an exception is thrown."
> However, I have found that no such exception is thrown.  I will attach a test 
> case showing the creation of (and the potential to infinitely loop through) a 
> containment cycle.

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


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

[jira] Resolved: (TUSCANY-1209) Remove TestCase dependency from XSDChocieTest

2007-04-17 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson resolved TUSCANY-1209.
-

   Resolution: Fixed
Fix Version/s: Java-SDO-CTS-Mx

> Remove TestCase dependency from XSDChocieTest
> -
>
> Key: TUSCANY-1209
> URL: https://issues.apache.org/jira/browse/TUSCANY-1209
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Community Test Suite
>Reporter: Andy Grove
>Priority: Minor
> Fix For: Java-SDO-CTS-Mx
>
> Attachments: patch.txt
>
>
> The attached patch file updates XSDBaseTestCase / XSDChoice to use junit 4.1 
> annotations and removes the dependency on TestCase. It also improves the 
> setup method to request a new testHelper class on each run.

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


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

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Hi Simon, 

By using the @Before annotation on the setup method and the @Test
annotation on test methods means the test case no longer needs to extend
TestCase and that in turn means that the setUp/teardown methods can be
made public rather than protected, which removes one of the barriers of
using standard junit test classes from another harness, while still
allowing them to be used as native junit tests.

With public methods it is possible to use reflection to load the test
case and then call the setup / test / teardown methods in turn. There is
still a dependency on junit.jar but no dependency on the junit test
runner class.

Hope that helps.

Andy.

-Original Message-
From: Simon Nash [mailto:[EMAIL PROTECTED] 
Sent: 17 April 2007 14:35
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

If the goal is to make the tests "harness agnostic", then I don't see
much difference between a JUnit-specific inheritance dependency and a
JUnit-specific annotation dependency.  Is the annotation dependency less
troublesome for some reason?

   Simon

kelvin goodson wrote:

> Thanks for this Andy,  I'll play with it tomorrow.
> 
> Regards, Kelvin.
> 
> On 16/04/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> 
>>
>>
>> I believe you just need to annotate the setUp method with @Before. 
>> This is described in the junit cookbook, here:
>>
>> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
>>
>> I'm currently working on submitting some more XSD test cases in the 
>> CTS so I'll try this method out. Hopefully I can then remove the 
>> current dependency on TestCase in those tests.
>>
>> Thanks,
>>
>> Andy.
>>
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
>> Behalf Of kelvin goodson
>> Sent: 16 April 2007 14:42
>> To: tuscany-dev@ws.apache.org
>> Cc: Robbie Minshall
>> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when 
>> classes don't inherit from TestCase
>>
>> Hi,
>> I'm looking at doing some work in the CTS. I was looking back at 
>> Robbie's attached description about how to keep the tests "harness 
>> agnostic".  I'm assuming that this is still a goal of the CTS 
>> although I may have missed something in my catching up. In my quest 
>> to make the CTS better I note that a number of the test case classes 
>> still extend the junit TestCase class.
>> This is true for all test classes that have a setUp() method. One 
>> that doesn't inherit from TestCase is XSDSerializationTest,  and 
>> adding a setUp method to this class doesn't cause junit to invoke it 
>> in my eclipse environment. I'm trying to work out whether I should I 
>> expect a 4.1environment to discover and execute the setUp method when

>> junit is used in this way. I seem to have Eclipse junit plugins for 
>> 3.8.1 and
>> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer much 
>> in the way of configuration, so I can't be sure I'm using 4.1
behaviour.
>>
>> I really would like to be XSDSerializationTests to execute setUp so 
>> that we can have a fresh HelperContext per test,  and I guess the 
>> easy way out is to make the test class inherit from TestCase like the

>> others, but I'd prefer not to introduce the explicit dependency on 
>> Junit if I can avoid it.
>>
>> Regards Kelvin.
>>
>>
>> On 07/12/06, Robbie Minshall <[EMAIL PROTECTED]> wrote:
>> >
>> > This sounds quite good.
>> >
>> > I have written some test cases with Brian Murray which I would be 
>> > happy to contribute to tuscany.  Identifying duplication and 
>> > differences in similar tests would probably be an intersting 
>> > excercise
>> right off the bat.
>> >
>> > One decision that we spent a little time mulling over was the 
>> > framework to use for our test suite.  Originally we used the much 
>> > loved junit harness which worked well.  Different runtimes ( 
>> > command line, J2EE Application Server, a Service Container ) have 
>> > different
>> classloader hierarchies etc.
>> > Without many modifications to the junit code it was difficult and 
>> > quite ugly testing SDO within the context of a variety of runtimes 
>> > which the SDO APIs will be used.
>> >
>> > We took the approach of writing general test libraries which can 
>> > then simply be called from a variety of test frameworks such as 
>> > junit or a simple J2EE or SCA Application test harness.  I like 
>> > this approach for
>>
>> > keeping the actual test code very simple, allowing for integration 
>> > a variety of test frameworks, and providing ability to test 
>> > directly within the different runtimes people care about.
>> >
>> > Any thoughts on this ?
>> >
>> > Robbie
>> >
>> >
>> >
>> >
>> > On 12/1/06, kelvin goodson <[EMAIL PROTECTED] > wrote:
>> > >
>> > > Andy,
>> > >   please attach them to the JIRA for this work and one of us can 
>> > > pick them up, thanks.
>> > > Best Regards, Kelvin.
>> > >
>> > > On 01/12/06, Andy Grove (Contractor)

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

2007-04-17 Thread Simon Nash

If the goal is to make the tests "harness agnostic", then I don't
see much difference between a JUnit-specific inheritance dependency
and a JUnit-specific annotation dependency.  Is the annotation
dependency less troublesome for some reason?

  Simon

kelvin goodson wrote:

Thanks for this Andy,  I'll play with it tomorrow.

Regards, Kelvin.

On 16/04/07, Andy Grove <[EMAIL PROTECTED]> wrote:

I believe you just need to annotate the setUp method with @Before. This
is described in the junit cookbook, here:

http://junit.sourceforge.net/doc/cookbook/cookbook.htm

I'm currently working on submitting some more XSD test cases in the CTS
so I'll try this method out. Hopefully I can then remove the current
dependency on TestCase in those tests.

Thanks,

Andy.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of kelvin goodson
Sent: 16 April 2007 14:42
To: tuscany-dev@ws.apache.org
Cc: Robbie Minshall
Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes
don't inherit from TestCase

Hi,
I'm looking at doing some work in the CTS. I was looking back at
Robbie's attached description about how to keep the tests "harness
agnostic".  I'm assuming that this is still a goal of the CTS although I
may have missed something in my catching up. In my quest to make the CTS
better I note that a number of the test case classes still extend the
junit TestCase class.
This is true for all test classes that have a setUp() method. One that
doesn't inherit from TestCase is XSDSerializationTest,  and adding a
setUp method to this class doesn't cause junit to invoke it in my
eclipse environment. I'm trying to work out whether I should I expect a
4.1environment to discover and execute the setUp method when junit is
used in this way. I seem to have Eclipse junit plugins for 3.8.1 and
4.1.0.1 and the preferences tab for Junit doesn't seem to offer much in
the way of configuration, so I can't be sure I'm using 4.1 behaviour.

I really would like to be XSDSerializationTests to execute setUp so that
we can have a fresh HelperContext per test,  and I guess the easy way
out is to make the test class inherit from TestCase like the others,
but I'd prefer not to introduce the explicit dependency on Junit if I
can avoid it.

Regards Kelvin.

On 07/12/06, Robbie Minshall <[EMAIL PROTECTED]> wrote:
>
> This sounds quite good.
>
> I have written some test cases with Brian Murray which I would be
> happy to contribute to tuscany.  Identifying duplication and
> differences in similar tests would probably be an intersting excercise
right off the bat.
>
> One decision that we spent a little time mulling over was the
> framework to use for our test suite.  Originally we used the much
> loved junit harness which worked well.  Different runtimes ( command
> line, J2EE Application Server, a Service Container ) have different
classloader hierarchies etc.
> Without many modifications to the junit code it was difficult and
> quite ugly testing SDO within the context of a variety of runtimes
> which the SDO APIs will be used.
>
> We took the approach of writing general test libraries which can then
> simply be called from a variety of test frameworks such as junit or a
> simple J2EE or SCA Application test harness.  I like this approach for

> keeping the actual test code very simple, allowing for integration a
> variety of test frameworks, and providing ability to test directly
> within the different runtimes people care about.
>
> Any thoughts on this ?
>
> Robbie
>
>
>
>
> On 12/1/06, kelvin goodson <[EMAIL PROTECTED] > wrote:
> >
> > Andy,
> >   please attach them to the JIRA for this work and one of us can
> > pick them up, thanks.
> > Best Regards, Kelvin.
> >
> > On 01/12/06, Andy Grove (Contractor) <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Hi Dan,
> > >
> > > I was previously working with Kelvin Goodson to donate some junit
> > tests
> > > on behalf of Rogue Wave Software.
> > >
> > > These tests are written purely to the SDO API and I have validated
> > that
> > > the tests do run against Tuscany as well as Rogue Wave's
> > implementation.
> > >
> > >
> > > Should I send the tests to Kelvin?
> > >
> > > Thanks,
> > >
> > > Andy.
> > >
> > > -Original Message-
> > > From: Dan Murphy [mailto:[EMAIL PROTECTED] ]
> > > Sent: 30 November 2006 17:44
> > > To: Tuscany Developers; Tuscany Users
> > > Subject: Proposal for a (Java) community test suite for SDO
> > >
> > > I would like to propose starting a community test suite for
> > > service
> > data
> > > objects (SDO CTS) implementations written in Java. Based on
> > > feedback from an earlier post this seems to be the first logical
> > > step in getting interoperable SDO implementations in all
> > > languages. I can see this leading to an interoperability test
> > > suite to check serialisation between implementations also works
> > > (across languages and implementations).
> > >
> > > Proposal for Community Test Suite (CTS) for SDO

Re: Website - Feedback please


I replied to this thread on the tuscany-user list

On 12/04/07, haleh mahbod <[EMAIL PROTECTED]> wrote:


Kelvin,
Thanks for your review.  You mentioned that scopes should be the same when
on a given page.
I agree.  I fixed it.  We now have a  sdo cpp FAQ and a sdo Java FAQ. I
also moved text from some of the mentioned threads to the FAQ. The ones I
did not is because I did not know how to net it down to a question and an
answer.

You mentioned General heading can be called Tuscany or SDO General
heading. The General heading is more a collection of things that I couldn't
find a good title for on that page :) It is not intended to be general for
Tuscany.

Some suggestion for the SDO Java page:

1)  Using SDO Java could move to 'user guide' on this page.
2) Code structure can move to get involved or even to the architecture doc

If there is agreement, I go ahead and make the changes.
Haleh


On 4/12/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>
> Haleh,
>
>   thanks for addressing these issues.  One concern I have after a quick
> look
> is that on arriving at a pages such as
> http://cwiki.apache.org/TUSCANY/sdo-java.html some of the links on the
> left
> under a given heading go off to a scope that is not intuitive from the
> page
> that you were on.  E.g. under the "General" sidebar heading,  the FAQ
> link
> for Java SDO goes to a page that I think is intended to contain generic
> cross language SDO questions, i.e. up one level of abstraction from the
> page
> heading.  It's been that way since version 3 of the file, and I can't
> work
> out whether it's intended that way,  or just a result of copying the
> content
> from an existing C++ page.
>
> The next sidebar heading below FAQ --- "Downloads" --- relates to
> downloading SDO Java (i.e. at the same level of abstraction of the
> current
> page).  I think it would be good if the sidebar headings grouped links
> at
> the same level of abstraction and made this clear from the heading name
> -
> e.g. "Tuscany General", or "SDO General"
>
>
> BTW,  FWIW, this prompted me to just catalogue the set of tuscany-dev
> notes
> that I have put an "FAQ" label against when reading the list. I had the
> intention of reviewing this list to see what was worth refining into
> well
> formed info snippets some time,  but haven't got to it yet.   Maybe we
> can
> divide and conquer to add to the website's FAQ set.  Does anyone else
> have
> anything like this?
>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00469.html
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13291.html
> Ron Gavlin's response to tuscany-user of 5th of Jan (cant find a very
> good
> archive URL for this one)
> My response to Alexander Pankov of  the  26th of Jan on t-user
> (again  URL
> not readily found)
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00560.html
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00610.html
> The thread started by Adriano Crestani on 15th Feb "mvn problem?"
> Unanswered thread from Ignacio on 16th Feb
> Frank's responses to Murtaza Goga in the thread started 20th March
>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200703.mbox/[EMAIL 
PROTECTED]
> The thread entitled "Root property that is not containment" started 29th
> of
> Jan
> The thread entitled "Getting started with Tuscany databinding" started
> on
> 10th April
>
> Regards, Kelvin.
>
>
>
>
>
>
>
>
> On 12/04/07, haleh mahbod < [EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > As mentioned in [1] I started working on the website and the first
> phase
> > is
> > ready for review.
> >
> > My first attempt ended up with something other than what I had
> originally
> > planned; which was to move content.  Instead, I worked on the
> readability
> > of
> > the website.
> > I have tried to use a consistent look and feel  across the pages  to
> make
> > it
> > easier to find information. In addition, I tried to make
> the  information
> > available progressively ( allowing the user to decide if they want to
> > learn
> > more).
> >
> > Here is the layout at a high level for the Tuscany Website (
> > http://cwiki.apache.org/TUSCANY/)
> >
> >- Home page - On this page you will find the general stuff that
> apply
> >to the whole Tuscany as well as links to each subproject and
> Downloads.
> > - Each subproject has an overview page, for example SCA overview
> or
> >DAS overview. On the overview page you find a brief introduction to
> the
> >subproject and links to resources which are introductory
> information on
> > the
> >subproject, for example white papers, articles, webinar links if
> any.
> >- Each subproject also has a more detailed page for those who want
> to
> >get more info about that particular subproject. For example, SCA
> Java,
> > SDO
> >C++, DAS RDB or DAS LDAP.
> >- Each detailed subproject page's navigation bar looks the same and
>
> >provides more detailed information on the project. For example,
> FAQ,
> >Documentation, H

RE: [Java SDO] Running the CTS against the Tuscany impl

Hi Kelvin,

I'm not aware of any special environment set up - I literally just ran
"svn update" then "mvn". The code looks for an environment variable
which provides the name of the test helper class but it defaults to the
Tuscany test helper if no environment variable is set (and I don't have
it set). I'll take a look at the output you sent yesterday and see if I
can figure out what the problem is.

On the second point, I wasn't sure what the plan is for deciding which
suite the tests should go in, so the patch was just for adding the test
as I didn't want to make any assumptions about whether the test was
adopted or under review etc. I guess all new tests are intended to go
into the UnderReviewTestSuite? Do you want me to update the patch to
include that?

Thanks,

Andy.

-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED] 
Sent: 17 April 2007 12:09
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO] Running the CTS against the Tuscany impl

It would be very helpful to get to the bottom of why Frank and I are
seeing no tests being run.  My guess is that somewhere in the
development of the test suite there has been a commonly agreed tweak to
the environment that Frank and I don't have,  and that is a prereq to
running the tests in this way. I think we need some documentation on the
CTS page that describes how to run the tests,  and the status of each
test.  Am I right in thinking that a test is either in the set of
adopted tests or in the under review tests, and every test is in one of
those sets?

I am just trying to apply the patch for Tuscany-1209, and I guess there
is some kind of trick to getting this class running, because at the
moment I have had to edit UnderReviewSuite.class to include the class
reference, and then run OptionalCtsTestSuite in eclipse a junit test
before I can see it
running.   Is this an expected necessary step?

Kelvin.

On 16/04/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
>
> I get the same result as Kelvin. Seems to build, but then it runs 0
tests.
>
> Frank.
>
> [EMAIL PROTECTED] wrote on 04/16/2007 09:55:35 AM:
>
> > Hmmm,   a mystery ...
> >
> > For the record, here's my output, I can see nothing obvious
> >
> > C:\Development\JiraDev\CTS>svn up
> > At revision 529243.
> >
> >
> > C:\Development\JiraDev\CTS>mvn clean [INFO] Scanning for projects...
> > [INFO] Reactor build order:
> > [INFO]   Community Test Suite
> > [INFO]   Community Test Suite for SDO 2.1
> > [INFO]   Tuscany SDO 2.1 CTS
> > [INFO]
> >
>
> --
> --
> >
> > [INFO] Building Community Test Suite
> > [INFO]task-segment: [clean]
> > [INFO] --
> > --
> > [INFO] [clean:clean]
> > [INFO] Deleting directory C:\Development\JiraDev\CTS\target [INFO] 
> > Deleting directory C:\Development\JiraDev\CTS\target\classes
> > [INFO] Deleting directory 
> > C:\Development\JiraDev\CTS\target\test-classes
> > [INFO]
> >
>
> --
> --
> >
> > [INFO] Building Community Test Suite for SDO 2.1
> > [INFO]task-segment: [clean]
> > [INFO]
> >
>
> --
> --
> > [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: 
> > checking
> for
> > updates from apache.incubator
> > [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: 
> > checking
> for
> > updates from codehaus-snapshot
> > [INFO] [clean:clean]
> > [INFO] Deleting directory C:\Development\JiraDev\CTS\sdo2.1\target
> > [INFO] Deleting directory
> C:\Development\JiraDev\CTS\sdo2.1\target\classes
> > [INFO] Deleting directory
> > C:\Development\JiraDev\CTS\sdo2.1\target\test-classes
> > [INFO]
> >
>
> --
> --
> >
> > [INFO] Building Tuscany SDO 2.1 CTS
> > [INFO]task-segment: [clean]
> > [INFO]
> >
>
> --
> --
> > [INFO] [clean:clean]
> > [INFO] Deleting directory
> C:\Development\JiraDev\CTS\sdo2.1-tuscany\target
> > [INFO] Deleting directory
> > C:\Development\JiraDev\CTS\sdo2.1-tuscany\target\classes
> > [INFO] Deleting directory
> > C:\Development\JiraDev\CTS\sdo2.1-tuscany\target\test-classes
> > [INFO]
> > [INFO]
> > [INFO]
> > 
> > 
> > [INFO] Reactor Summary:
> > [INFO]
> > 
> >  [INFO] Community Test Suite .. 
> > SUCCESS [ 1.302s] [INFO] Community Test Suite for SDO 2.1 
> > .. SUCCESS [ 17.586s] [INFO] Tuscany SDO 2.1 CTS

> > ... SUCCESS [ 3.575s] [INFO]
> > 
> > 
> > [INFO]
> >

[SDO Java] RC3 available for testing

I buried a notification on the list about the availability of release
candidate 3 for SDO for Java at the bottom of the vote thread on RC2. I
think perhaps it would have been clearer to start a new thread. So, please
poke and prod at it in advance of me starting a vote thread.

RC3 is at
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC3/
The release audit tool (rat) files and associated exceptions are attached to
the jira under which the release work was done, here
http://issues.apache.org/jira/browse/TUSCANY-1171

The tag for the source code is here .
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubator-M3/

Changes in this release are shown here .
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubator-M3/sdo/distribution/RELEASE_NOTES.txt

For this iteration I have, fixed all the small typos and inaccuracies that
were pointed out in the README, LICENSE and samples documentation. I've
also made sure the jar names are all consistent and rearranged the structure
of the samples archive a little, including putting the correct javadoc in
that archive. This slip caused me to build a script for creating the
distribution (
http://issues.apache.org/jira/secure/attachment/12355518/buildSDORelease.bat)

I still haven't managed to find the time yet to investigate and come to a
conclusion on whether I should be publishing the artifacts to the maven repo
right now, or when I start a new vote, or when that vote is completed.
Ant sent me some links to discussion threads from other projects that have
been coming up against this issue, which I'll digest as soon as I can.
For your ref they are ...
http://marc.info/?t=11760705873&r=1&w=2
http://marc.info/?l=incubator-general&m=117606976901938&w=2

Regards, Kelvin.

Databinding problem with WS when service or reference uses interface.java instead of WSDL


There's a problem with the databinding when using web services and the
service or reference uses interface.java. It looks like the the
wrapping/unwrapping goes wrong and ends up with a ClassCastException  in
SimpleType2JavaTransformer. Any ideas on how to fix this? I've separated
this case out of the wsdl itests into a single test to make it easier to
debug, see:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdl/src/test/java/org/apache/tuscany/sca/itest/DBFailTestCase.java

  ...ant

Re: [Java SDO] Running the CTS against the Tuscany impl