Re: 0.91 release?

[Venkata Krishnan]

Hi Simon, the aggregator demo seemed to throw classdefnotfound exception for
javax.servlet. ServletException.

I guess it would be good to release the demos to give people a better feel
of how things work.

- Venkat

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


I can speak for the following

binding-jms - Works for sychronous, Java object based messages and
implements a part of the spec but not all of it. So it depends on how
comfortable we are with spec incomplete bindings. I would leave it out for
now

binding-sca - part of the distributed runtime. All checked in now with a
working sample but uses binding-jms (as there is a lack of point to point
protocols that I can leverage without change).  Am just writing mail now
to
describe what I've been up to and now you've taken the branch I'll put it
in
the build.

Are we releasing the demos this time? Were you sans aggregator because
there
is a problem with it? I can go fix it if so. I know I should go try it but
I
haven't checked the branch out yet;-)

Simon

Re: 0.91 release?

[Venkata Krishnan]

Yes... I guess it should be possible to have them.  I'd say, at the least
that we have a readme that describes the demo layout, what its intent is and
how you get to run it.  I guess this is something we have already done for
the samples.

- Venkat

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


[snip]
Simon Laws wrote:
> Are we releasing the demos this time? Were you sans aggregator because
> there
> is a problem with it? I can go fix it if so. I know I should go try it
> but I
> haven't checked the branch out yet;-)
>
> Simon
>

Would it be possible to have the demos in the release? What do we need
to do to make it happen?

Thanks.

--
Jean-Sebastien


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

Re: Policy Framework Impl. in Tuscany

[Venkata Krishnan]

Hi Sebastien,

First thanks to you and Dave for responding to my queries.

I always had this one point troubling my mind with this.  Its about creating
those various proxy objects and abandoning them once they are resolved to
the original one. Since we do this right across our model I wonder if it
would do hurt to have so many objects dereferenced this way or am I
imagining too much and that this is actually quite affordable.

Thanks

- Venkat

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


It looks like we're on the same page, I added some clarifications where
you had a question inline.

scabooz wrote:
> Venkat,
> comments embedded...
>
> - Original Message - From: "Jean-Sebastien Delfino"
> <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, June 18, 2007 10:33 AM
> Subject: Re: Policy Framework Impl. in Tuscany
>
>
>> Venkata Krishnan wrote:
>>> Hi,
>>>
>>> I am keen on adding further to the Policy support thats in Tuscany
>>> today. I
>>> recently run thro the Policy Framework specs and was looking into
>>> Tuscany on
>>> how far we had gone on this.  Here's my understanding of all that.  I
>>> request people's perspective on my understanding before I go ahead and
>>> implement things.
>>>
>>> 1.  Policy intents and PolicySets are things that can be defined at
the
>>> domain level.  I propose we have Policy Registry or Repository that
>>> hosts
>>> the set of all intents and policy sets that pertain to a domain.
>>
>> +1 but I think we could start with something simpler than a
>> repository, simply a model for definitions.xml, and a reader for this
>> file.
>>
>
> In addition, you could consider PolicySets packaged with a contribution,
> such that it's not possible (a temporary restriction) to reference a
> policySet from another contribution.  Start simple.
>
>>>
>>> 2. There can be a PolicyRegistryService that can provide interfaces
>>> to add,
>>> retrieve and remove intents and policies to the Policy Registry /
>>> Repository.
>>
>> +1
>>
>>>
>>> 3. The set of intents and policy sets for a domain could be defined
>>> in the
>>> definitions.xml file which could be picked up by the
>>> ContributionsProcessor
>>> (see line 2490 of Assembly Model Spec).  Infact there is more - such
>>> as the
>>> intents that are supported by binding and implementation types in
>>> the domain
>>> and so on.  We could have a processor for the sca definitions that
>>> will read
>>> among other artifacts the policy intents and policy sets and add
>>> them to the
>>> registry.  The model objects to represent policy intents and policy
>>> sets and
>>> the factory to create them are already in place under the policy
>>> module.
>>>
>>
>> Policy administration is independent of SCA contributions. How about
>> a new policy-xml module for the code that will read definitions.xml,
>> independent of the ContributionProcessor?
>>
>
> Right. A long term solution would include a seperation of policy from
> contributions.  The "policy registry" could even be separate from
> the Domain as an entity, but a Domain will have a reference to a
> policy registry.
>
>>> 4. SCA artifacts will have intents and policy sets attached to them.
>>> Presently the artifact processors create the Intents and PolicySet
>>> objects.
>>> I propose that the artifact processor that read these SCA Artifacts
>>> will
>>> just about read the QNames and resolve them in the resolution phase
>>> with the
>>> help of the PolicyRegistryService.  This way we can also check if
>>> the intent
>>> or policy set specified for an artifact is really applicable to the
>>> artifact
>>> or not.
>>>
>>
>> Intents need to be resolved to point to the intents defined in
>> definitions.xml in ArtifactProcessor.resolve(). I'd suggest to adopt
>> to the same approach as for all other objects that need to be resolved:
>> 1. read creates an Intent / PolicySet with unresolved = true
>> 2. resolve replaces it with the resolved Intent / PolicySet
>>
>
> I didn't quite follow this.  Is this different from canonicalizing
> intent and policySet attachments as described in the lengthy algorithm
in
> section 1.4.10 of the spec?

I was describing the general pattern currently used in Tuscany to
represent and resolve relationships between models. Our models need to
be able to represent relationships with objects that are resolved later
or in some cases never resolved at all.

Let's say you have two model classes:

AssemblyThing
Intent

Instead of having:

(a)
interface AssemblyThing {
  QName getIntentName();
  void setIntentName(QName qname);
}

interface Intent {
  QName getName();
  void setName(QName name);
}

or

(b)
interface AssemblyThing {
  QName getIntentName();
  void setIntentName(QName qname);
  Intent getIntent();
  void setIntent(Intent intent);
}

interface Intent {
  QName getName();
  void setName(QName name);
}

We're using the following pattern in our models:

(c)
interface AssemblyThing {
  Intent getIntent();
  void setIntent(Intent intent);
}

interface I

Lazy loading of Tuscany extensions, was: Status of Java SCA 0.90 release

[Jean-Sebastien Delfino]

Jean-Sebastien Delfino wrote:


There has been many commits and good progress the last few days, so I 
spent a little bit of time checking the status of the trunk.


Here's a summary of what I found:
- The code cleanup is almost complete, I think there's a little bit 
work left to refactor one last .spi. package, remove a few dead 
classes, also it looks like Raymond has started to clean up the Scope 
registry and WorkContext I'm not sure if it's finished or not.
- The Java, Script and RMI extensions are now stable, as well as the 
sample implementation, binding, and data binding extensions.
- It looks like we have a reasonable Web app story with a servlet 
context listener, but it may require a little bit of cleanup to avoid 
confusion with sca-contribution.xml. I'm also not sure if it allows to 
expose Web Services from a Web app, or if we even want to do that now.


Main todo's that I could think of:
- Port the Web Service binding extension to the latest code, as it's 
really important to have, and is also used by many integration tests.

- Run RAT and check licenses and notices.
- Check why the itest/spec-api test cases are failing.
- Create a JAR containing the source of our runtime, to help debugging 
in an IDE.

- Are the samples build.xml finished?
- I have ported the Spring extension to the latest code but need to do 
a little bit of cleanup tomorrow before committing it.
- I'm not sure about the JSONRPC binding, wouldn't it be nice to have 
it too?
- Lazy loading of our modules to avoid loading too many dependencies 
when using tuscany-sca-all.jar.
- Rename the packages to *.sca.* but I would suggest to delay this to 
a later point some time next week after our first RC.


And there's probably a few more :)



0.91 is around the corner and I finally found some time to tackle the 
"Lazy loading of modules" issue mentioned in this thread.


The 0.90 release code was pretty aggressive with loading all Tuscany 
extension modules on the classpath. This can be optimized now.


With the changes I have committed today (r549339) an extension does not 
have to register a ModuleActivator anymore (it can still do it but does 
not have to). Instead you can declare your Tuscany extension's 
ArtifactProcessors and ProviderFactories individually, still using the 
same META-INF/services mechanism, but allowing you to specify additional 
metadata when you declare them, like the QName of the XML element and 
the name of the model class you're handling.


If you do that, then you'll give the Tuscany runtime enough information 
to allow it to load your classes dynamically, when your particular 
implementation or binding extension is hit in an SCA assembly. If your 
extension is not used in your application, it will not be loaded at all.


I have committed new extension samples that show how to use this 
improved declaration mechanism:

samples/implementation-crud2-extension
samples/binding-echo2-extension
samples/implementation-pojo2-extension

File 
META_INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor 
registers an artifact processor

syntax:
;type=#name>,model=


File 
META_INF/services/services/org.apache.tuscany.sca.provider.ImplementationProviderFactory 
registers an implementation provider factory

syntax:
;model=

File 
META_INF/services/services/org.apache.tuscany.sca.provider.BindingProviderFactory 
registers a binding provider factory

syntax:
;model=

If people find this new capability useful I can help merge the code into 
the 0.91 branch. The changes are mainly new Lazy*Something classes and a 
little more code in the host-embedded runtime bootstrapping.


--
Jean-Sebastien


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

Re: Which jar files are really needed for the Calculator Sample?

[Jean-Sebastien Delfino]

ant elder wrote:

On 6/20/07, Matthew Peters <[EMAIL PROTECTED]> wrote:


Newbie question and first posting - I hope this gets formatted OK, right
name put on etc.. Also, I have searched the mail archive but cannot find
the answer - please excuse me if this has been asked before..

The calculator sample includes a tuscany-sca-manifest.jar that pulls in
literally dozens of other jars. I want to make a war file that contains
the sample and really only want to include the minimal set of jar files.
So, are they really all needed, and if not, how can I work out exactly
which ones are?



The current distribution and the tuscany-sca-manifest.jar is a point 
in time
thing to make things easy to use for now, there's probably better ways 
for

1.0. You can do what you want now though, in fact, take a look at the
calculator-webapp sample:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp/ 



  ...ant



In general the sample's Maven pom.xml contains the minimum required. To 
let Maven compute the complete set of dependency JARs, do this:

cd samples/calculator-webapp
mvn dependency:copy-dependencies
ls target/dependencies

--
Jean-Sebastien


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

Re: 0.91 release?

[Jean-Sebastien Delfino]

Simon Nash wrote:

I would prefer not to delay SCA 0.91 for the DAS support.  Unless we
are confident that the DAS release can be created quickly, I think
it's better to go ahead with SCA 0.91 as planned and defer the DAS
support.


+1



An alternative packaging approach (which I am starting to think would
be even better) is to reverse the dependency and have the DAS release
ship the pieces identified by Luciano below.  It should be possible
(even desirable) for Tuscany SCA extensions that support another
technology to ship as part of a release of that technology rather than
always making them part of a Tuscany SCA release.



I'm trying to understand this thought.

Here are some of our technology dependencies:

binding-ws -> Axis2
binding-jms -> ActiveMQ
binding-feed -> Rome
databinding-sdo -> SDO
binding-jsonrpc -> json
implementation-das -> DAS
implementation-bpel -> ODE
implementation-spring -> Spring
implementation->osgi -> Equinox
databinding-xmlbeans -> XMLBeans
databinding-jaxb -> JAXB
binding-ejb -> Geronimo
http->jetty -> Jetty
http-tomcat -> Tomcat

tuscany-core -> J2SE 5.0 :) and woodstox

I know that many combinations are possible, but as long as something 
works, I'm not sure why we would exclude it from a Tuscany release.


Which ones are you proposing to pick out and not include in a Tuscany 
SCA release?


--
Jean-Sebastien


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

Re: 0.91 release?

[Jean-Sebastien Delfino]

[snip]
Simon Laws wrote:
Are we releasing the demos this time? Were you sans aggregator because 
there
is a problem with it? I can go fix it if so. I know I should go try it 
but I

haven't checked the branch out yet;-)

Simon



Would it be possible to have the demos in the release? What do we need 
to do to make it happen?


Thanks.

--
Jean-Sebastien


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

Re: Finding the .componentType file

[Jean-Sebastien Delfino]

Mike Edwards wrote:

Ant,

In general, I would agree that there should be a simple and obvious 
relationship between implementation artifact and componentType file.


However, consider the case of languages like C or C++ where multiple 
implementations are bundled into a DLL.  The runtime file is the DLL, 
but there must be multiple componentType files.  So now, what is the 
relationship between them


In these more complex cases, the implementation type defines the 
relationship.


Yours,  Mike.

ant elder wrote:

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



How does that fit with the spec saying - ""A component type file has 
the

> same name as the implementation file but has the extension
> ".componentType""
> ? I'm looking for a way to make the default case easy, it doesn't 
have

to
> deal with every edge case.


Unfortunately, this is no edge case.  There is no reason to expect the
component name to be even close to the implementation name.




AFAICT, unless there's an attribute in the SCDL to explicitly point 
to it
there has to be a way to find these things programatically, and for 
humans
to understand whats going on in a contribution it must be reasonably 
obvious
which .componentType side file is associated with which 
implementation just
by eyeballing the files. Otherwise, what does this line in the spec 
mean:


'A component type file has the same name as the implementation file 
but has

the extension ".componentType"'

  ...ant





Nobody picked up my earlier post to this thread, I thought that my 
concrete examples were interesting though :) so I'll repeat a concrete 
example again here:




componentType file: calculator/CalculatorImpl.componentType

- The relationship is obvious to a human
- There is no SCDL attribute pointing to the componentType
- The relationship class name -> .componentType file location is 
specific to the Java implementation type.


IMHO you need implementation specific code to derive the .componentType 
file location from the attributes of the .


--
Jean-Sebastien


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

Re: Policy Framework Impl. in Tuscany

[Jean-Sebastien Delfino]

It looks like we're on the same page, I added some clarifications where 
you had a question inline.


scabooz wrote:

Venkat,
comments embedded...

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

To: 
Sent: Monday, June 18, 2007 10:33 AM
Subject: Re: Policy Framework Impl. in Tuscany



Venkata Krishnan wrote:

Hi,

I am keen on adding further to the Policy support thats in Tuscany 
today. I
recently run thro the Policy Framework specs and was looking into 
Tuscany on

how far we had gone on this.  Here's my understanding of all that.  I
request people's perspective on my understanding before I go ahead and
implement things.

1.  Policy intents and PolicySets are things that can be defined at the
domain level.  I propose we have Policy Registry or Repository that 
hosts

the set of all intents and policy sets that pertain to a domain.


+1 but I think we could start with something simpler than a 
repository, simply a model for definitions.xml, and a reader for this 
file.




In addition, you could consider PolicySets packaged with a contribution,
such that it's not possible (a temporary restriction) to reference a
policySet from another contribution.  Start simple.



2. There can be a PolicyRegistryService that can provide interfaces 
to add,

retrieve and remove intents and policies to the Policy Registry /
Repository.


+1



3. The set of intents and policy sets for a domain could be defined 
in the
definitions.xml file which could be picked up by the 
ContributionsProcessor
(see line 2490 of Assembly Model Spec).  Infact there is more - such 
as the
intents that are supported by binding and implementation types in 
the domain
and so on.  We could have a processor for the sca definitions that 
will read
among other artifacts the policy intents and policy sets and add 
them to the
registry.  The model objects to represent policy intents and policy 
sets and
the factory to create them are already in place under the policy 
module.




Policy administration is independent of SCA contributions. How about 
a new policy-xml module for the code that will read definitions.xml, 
independent of the ContributionProcessor?




Right. A long term solution would include a seperation of policy from
contributions.  The "policy registry" could even be separate from
the Domain as an entity, but a Domain will have a reference to a
policy registry.


4. SCA artifacts will have intents and policy sets attached to them.
Presently the artifact processors create the Intents and PolicySet 
objects.
I propose that the artifact processor that read these SCA Artifacts 
will
just about read the QNames and resolve them in the resolution phase 
with the
help of the PolicyRegistryService.  This way we can also check if 
the intent
or policy set specified for an artifact is really applicable to the 
artifact

or not.



Intents need to be resolved to point to the intents defined in 
definitions.xml in ArtifactProcessor.resolve(). I'd suggest to adopt 
to the same approach as for all other objects that need to be resolved:

1. read creates an Intent / PolicySet with unresolved = true
2. resolve replaces it with the resolved Intent / PolicySet



I didn't quite follow this.  Is this different from canonicalizing
intent and policySet attachments as described in the lengthy algorithm in
section 1.4.10 of the spec?


I was describing the general pattern currently used in Tuscany to 
represent and resolve relationships between models. Our models need to 
be able to represent relationships with objects that are resolved later 
or in some cases never resolved at all.


Let's say you have two model classes:

AssemblyThing
Intent

Instead of having:

(a)
interface AssemblyThing {
 QName getIntentName();
 void setIntentName(QName qname);
}

interface Intent {
 QName getName();
 void setName(QName name);
}

or

(b)
interface AssemblyThing {
 QName getIntentName();
 void setIntentName(QName qname);
 Intent getIntent();
 void setIntent(Intent intent);
}

interface Intent {
 QName getName();
 void setName(QName name);
}

We're using the following pattern in our models:

(c)
interface AssemblyThing {
 Intent getIntent();
 void setIntent(Intent intent);
}

interface Intent {
 QName getName();
 void setName(QName name);
 boolean isUnresolved();
 void setUnresolved(boolean unresolved);
}

Pattern (a) doesn't look like a model at all. Pattern (b) is confusing. 
So we're using pattern (c), which can use an instance of intent marked 
unresolved to represent the relationship to a "proxy" Intent just 
holding its name, then later change it to point to the actual intent 
object after it's resolved. With pattern (c) models look like real 
models with real relationships instead of beans with names and strings 
or QNames all over the place shadowing model relationships.


That was my point. This doesn't replace, compete with, or get in the way 
of the algorithm described in 1.4.10, it just helps model the 
relationships between

Tuscany/ODE resources questions

[Matthieu Riou]

Hi guys,

I'm starting on the lifecycle part of the Tuscany/ODE integration to get an
engine started with all its necessary resources (transaction, persistence,
...). I can go with in-memory mode and light configuration for now but we'll
want a fully working server sooner or later. So I have a few questions:

1. How can I get server-wide configuration properties to configure the
behavior of the engine? Things like the size of our thread pool, if we
should use an embedded database or try to lookup a datasource, some memory
optimization modes we can run in, ... These would be for the whole ODE
server and not on a per-process basis.

2. How can I get the a transaction manager? I haven't been able to find an
extension point for it. If there are none available, I can still create my
own but it'd be probably be better to reuse the Tuscany one if it's there.

3. In embedded persistence mode, ODE uses a Derby database. Which means
files located somewhere. Is there a way to lookup a given directory under
which the database could be made available? For example when we deploy ODE
in a webapp for example, the database is prepackage in the webapp and we
find it under the context root (or alternatively a path can be configured,
see 1)

I think that's all for now but I'll certainly find more in the coming days
:)

Thanks!
Matthieu

SDO spec compliance/portability: Type

[Michael Yoder]

Hi,

The Tuscany SDO C++ class Type has this public member which does not
appear
in the C++ 2.1 specification:

  static SDO_API const SDOString SDOTypeNamespaceURI;

Would it be appropriate to file a bug to have it removed from the public
API? Or alternatively a bug
for it to be submitted to the spec committee?

Thanks,

Michael Yoder
Software Developer
Rogue Wave Software

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

SDO spec compliance/portability: Type enums

[Michael Yoder]

Hi,

The Tuscany SDO C++ class Type::Types enum has these values which do not
appear
in the C++ 2.1 specification:

  - OpenDataObjectType
  - num_type

Would it be appropriate to file a bug to remove the additional values?
Or alternatively a bug for them to be 
submitted to the spec committee? 

In addition the 2.1 spec renamed the enum value "IntegerType" to
"IntType".

Would it be appropriate to file a bug to have this value renamed?

Thanks,

Michael Yoder
Software Developer
Rogue Wave Software

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

C++ SDO spec compliance/portability: SDORuntimeException

[Michael Yoder]

Hi,

The Tuscany SDO C++ class SDORuntimeException has these public member
functions which do not appear
in the C++ 2.1 specification:


  SDO_API severity_level getSeverity() const;
  SDO_API void setSeverity(severity_level sev);
  SDO_API void setMessageText(const std::string& msg_text);
  SDO_API void setExceptionLocation(const std::string& file,
unsigned long line,
const std::string& function="");
  SDO_API void setLocation(const std::string& file,
   unsigned long line,
   const std::string& function="");
 
  SDO_API void trace(const std::string& text="%1:\n  %3 %4 %2");
 
  SDO_API virtual ostream& PrintSelf(ostream &os) const;
  SDO_API friend ostream& operator<< (ostream &os, const
SDORuntimeException &except);


What's the rational behind these additional member functions? Would it
be appropriate to file a bug to have them removed from the public API?
Or alternatively a bug for them to be submitted to the spec committee?

Thanks,

Michael Yoder
Software Developer
Rogue Wave Software

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

Re: [C++] SDO - preventing SDO from loading schema across the network

[Pete Robbins]

oh.. they are freed later on in the ParsedLocations destructor ??? OK. I
clearly need to look at this when more awake :-(

On 20/06/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


Having just browsed the code in parseIfNot I would be inclined to rewrite
it! It looks like it is over complex and news up a SDOSchemaSax2Parser that
is never freed. I'll maybe take a look at getting that into shape in the
next week.

Cheers,


On 20/06/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> OK, thanks Pete, I'll take a look.
>



--
Pete





--
Pete

Re: [C++] SDO - preventing SDO from loading schema across the network

[Pete Robbins]

Having just browsed the code in parseIfNot I would be inclined to rewrite
it! It looks like it is over complex and news up a SDOSchemaSax2Parser that
is never freed. I'll maybe take a look at getting that into shape in the
next week.

Cheers,


On 20/06/07, Simon Laws <[EMAIL PROTECTED]> wrote:


OK, thanks Pete, I'll take a look.





--
Pete

[jira] Issue Comment Edited: (TUSCANY-1362) Incorrect operation of code that checks whether schema is loaded before going out on the net to retrieve it.

[Pete Robbins (JIRA)]

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

Pete Robbins edited comment on TUSCANY-1362 at 6/20/07 2:57 PM:


I think you need to leave this method asis as it handles  as well as 


I would look at startInclude (line 572) and put logic in above line 587:

if (import)
{
   if (namespace in already imported list)
  return;
   else
  add namespace to imported list;
}


That should do the trick! 

 Just looked at the code and I'm not sure why the list of parsed 
locations is held on the ParserErrorSetter??? It may have been convenient but 
doesn't seem right to me. Anyho.. a simple  "importedNamespaceList" added 
alongside this would be ok I think. I can't see the need for the complicated 
hashmap etc that's used for the locations. Keep It Simple!!!

Cheers 


 was:
I think you need to leave this method asis as it handles  as well as 


I would look at startInclude (line 572) and put logic in above line 587:

if (import)
{
   if (namespace in already imported list)
  return;
   else
  add namespace to imported list;
}


That should do the trick!

> Incorrect operation of code that checks whether schema is loaded before going 
> out on the net to retrieve it. 
> -
>
> Key: TUSCANY-1362
> URL: https://issues.apache.org/jira/browse/TUSCANY-1362
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Java-SDO-M2
> Environment: All
>Reporter: Simon Laws
>Priority: Minor
>
> There is code in SDOSchemeSAX2Parse.cpp that decideds whether to go ahead and 
> parse the referenced file
> SDOSchemaSAX2Parser* ParserErrorSetter::parseIfNot(const void* 
> location, bool loadImportNamespace, const void* base)
> {
> xmlChar*const absoluteUri = xmlBuildURI((xmlChar*)location, 
> (xmlChar*)base);
> if (! absoluteUri)
> SDO_THROW_EXCEPTION("parseIfNot", SDOFileNotFoundException, 
> (char*)location);
> LocationParserMap::iterator iter = 
> parsedLocations.find(absoluteUri);
> if (parsedLocations.end() == iter)
> {
> SDOSchemaSAX2Parser*const schemaParser = new 
> SDOSchemaSAX2Parser(*new SchemaInfo(), this, loadImportNamespace);
>   try {
>   if (0 == 
> schemaParser->parse((char*)absoluteUri))
>  ***   return parsedLocations[ absoluteUri ] = 
> schemaParser;
> }
>   catch (SDORuntimeException e)
>   {}
> schemaParser->free(absoluteUri);
> return 0;
> }
> xmlFree(absoluteUri);
> return iter->second;
> }
> Note the line marked ***. This adds the current URL being parse to the 
> parsedLocations list for future reference. The issue is that, in the case 
> where no schemaLocation is provided and loadImportNamespace is true, this 
> will not work if the schema was orginally loaded from the file system, for 
> example
> /mydir/schema1.xsd  - parsedLocation = "file:///mydir/schema1.xsd
> targetNamespace="http://schemas.xmlsoap.org/wsdl/";
> /mydir/schema2.xsd 
>   http://schemas.xmlsoap.org/wsdl/"; /> - doesn't hit 
> parsedLocation as it not the same URL as was originally used to load schema1
> A solution is to store both the provided location and the target namsepace in 
> parsedLocation

-- 
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: [C++] SDO - preventing SDO from loading schema across the network

[Simon Laws]

OK, thanks Pete, I'll take a look.

Stage 1 Distributed runtime checked into trunk

[Simon Laws]

With the changes associated with
http://issues.apache.org/jira/browse/TUSCANY-1338 I've now put the simple
distributed runtime support into head. The modules I've added are

modules/
 topology/topology-xml - describe and read the node to component mapping
(not actually used at the moment)
 binding.sca - provides and abstraction of a automatically configured
remote runtime
 distributed - the various other infrastructure changes I needed
samples/
 calculator-distributed

Fundamentally what is going on is that there is a new domain class
DistributesSCADomain which has two runtimes in it.

1/ A DistributedRuntime which runs the application assembly
2/ A NodeRuntime which runs the node management services, at this time just
the ComponentRegistry.

The ComponentRegistry implements a simple interface which allows the
component/node mapping to be set and retrieved. Currently it is set from har
coded calls in the sample but as this is in an SCA assmebly any kind of
binding can be used for getting the information in.

The distributed module is worth a closer look. I've added the distributed
support without changing any of the existing runtime code and this is where
I've put the new bits and pieces. If you look inside this module you see the
following packages that map onto our existing packages. Code could be moved
to the right place in the future.

o.a.t.s.d.assembly
  The interface for the distributed SCA binding that allows me to add so
new methods onto the SCA binding

o.a.t.s.d.core
  A specialisation of the CompositeActivator which extends the build
method. This is possible the most interesting bit as this is where the
decision is made about where components run.

o.a.t.s.d.host
 The distributed domain, runtime and node service runtimes. Based heavily
on the existing domains and runtimes. But the existing implementations are
ties down tightly so I had to pretty much copy the code.

o.a.t.s.d.node
 The node model processing as the component registry implementation


The majority of the work in this exercise was just plumbing the right bits
of information to the right place. Anyhow I have a whole list of issues that
I encountered along the way but I will divulge those in bite sized chunk.

If you build all of the modules then calculator-distributed will test
distributed operation (sort of)  from the mvn command. For the real effect
though use the ant file.

ant runC
ant runB
ant runA

will run the three nodes of the the distributed calculator sample (see
calculator-distributed.png). You do need to be running ActiveMQ 4.1.0  to
make this work (the unit test runs it automatically though).

I'm out until later tomorrow so I'll add it to the trunk build then so it
starts getting tested. As I mentioned above I will start separate threads
about what I have found and what I think we should do next.

Simon

[jira] Commented: (TUSCANY-1362) Incorrect operation of code that checks whether schema is loaded before going out on the net to retrieve it.

[Pete Robbins (JIRA)]

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

Pete Robbins commented on TUSCANY-1362:
---

I think you need to leave this method asis as it handles  as well as 


I would look at startInclude (line 572) and put logic in above line 587:

if (import)
{
   if (namespace in already imported list)
  return;
   else
  add namespace to imported list;
}


That should do the trick!

> Incorrect operation of code that checks whether schema is loaded before going 
> out on the net to retrieve it. 
> -
>
> Key: TUSCANY-1362
> URL: https://issues.apache.org/jira/browse/TUSCANY-1362
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Java-SDO-M2
> Environment: All
>Reporter: Simon Laws
>Priority: Minor
>
> There is code in SDOSchemeSAX2Parse.cpp that decideds whether to go ahead and 
> parse the referenced file
> SDOSchemaSAX2Parser* ParserErrorSetter::parseIfNot(const void* 
> location, bool loadImportNamespace, const void* base)
> {
> xmlChar*const absoluteUri = xmlBuildURI((xmlChar*)location, 
> (xmlChar*)base);
> if (! absoluteUri)
> SDO_THROW_EXCEPTION("parseIfNot", SDOFileNotFoundException, 
> (char*)location);
> LocationParserMap::iterator iter = 
> parsedLocations.find(absoluteUri);
> if (parsedLocations.end() == iter)
> {
> SDOSchemaSAX2Parser*const schemaParser = new 
> SDOSchemaSAX2Parser(*new SchemaInfo(), this, loadImportNamespace);
>   try {
>   if (0 == 
> schemaParser->parse((char*)absoluteUri))
>  ***   return parsedLocations[ absoluteUri ] = 
> schemaParser;
> }
>   catch (SDORuntimeException e)
>   {}
> schemaParser->free(absoluteUri);
> return 0;
> }
> xmlFree(absoluteUri);
> return iter->second;
> }
> Note the line marked ***. This adds the current URL being parse to the 
> parsedLocations list for future reference. The issue is that, in the case 
> where no schemaLocation is provided and loadImportNamespace is true, this 
> will not work if the schema was orginally loaded from the file system, for 
> example
> /mydir/schema1.xsd  - parsedLocation = "file:///mydir/schema1.xsd
> targetNamespace="http://schemas.xmlsoap.org/wsdl/";
> /mydir/schema2.xsd 
>   http://schemas.xmlsoap.org/wsdl/"; /> - doesn't hit 
> parsedLocation as it not the same URL as was originally used to load schema1
> A solution is to store both the provided location and the target namsepace in 
> parsedLocation

-- 
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: [C++] SDO - preventing SDO from loading schema across the network

[Pete Robbins]

I just added a comment to the Jira on how I think it should be fixed.

Cheers,


On 20/06/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


Tricky one. My understanding is that s should be for unique
namespaces.  adds types to the same namespace. So I think if you
restrict this logic to the  elements you should be ok.

Cheers,


 On 20/06/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> Posting to tuscany and php lists
>
> I raised a bug ( http://issues.apache.org/jira/browse/TUSCANY-1362) as
> we
> noticed in PHP that C++ SDO was going out across the network to find
> schema
> identified by namespace alone even when the schema had already been
> read.
> The problem is that the list that is used to check whether the schema
> has
> been seen already is based on the location of the schema. So when
> something
> later tries to read the schema based on namespace it can't tell it's
> seen
> it.
>
> I have a fix which involves storing a second list of namespaces seen
> before
> to sit alongside the locations seen before list. This list can then be
> checked as well. Now the worry I have in implementing this is that I
> believe
> if we check schema loads against the previous seen namespaces it means
> that
> we can't load types for a namespace from more than one file. Is this a
> scenario that is important to support?
>
> Regards
>
> Simon
>



--
Pete





--
Pete

Re: [C++] SDO - preventing SDO from loading schema across the network

[Pete Robbins]

Tricky one. My understanding is that s should be for unique
namespaces.  adds types to the same namespace. So I think if you
restrict this logic to the  elements you should be ok.

Cheers,


On 20/06/07, Simon Laws <[EMAIL PROTECTED]> wrote:


Posting to tuscany and php lists

I raised a bug (http://issues.apache.org/jira/browse/TUSCANY-1362) as we
noticed in PHP that C++ SDO was going out across the network to find
schema
identified by namespace alone even when the schema had already been read.
The problem is that the list that is used to check whether the schema has
been seen already is based on the location of the schema. So when
something
later tries to read the schema based on namespace it can't tell it's seen
it.

I have a fix which involves storing a second list of namespaces seen
before
to sit alongside the locations seen before list. This list can then be
checked as well. Now the worry I have in implementing this is that I
believe
if we check schema loads against the previous seen namespaces it means
that
we can't load types for a namespace from more than one file. Is this a
scenario that is important to support?

Regards

Simon





--
Pete

Re: How to get an instance of the read composite file ?

[Luciano Resende]

The implementation.bpel is already based on "the  other" API, similar
to the CRUD sample mentioned by Ant. The .composite is read in the
BPELImplementationProcessor.read

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

On 6/20/07, sam tam <[EMAIL PROTECTED]> wrote:
>
> Hello All,
>
> In the implementation script module, there should be some place where the
> [.composite] file information are read .
>
> Can any one mention where this is read ?
>
> Is it in the AbstractSCATestCase ?
>
>
> Am now trying implementation bpel (ie integrating Apaceh ODE-bpel and
> Tuscany-SCA)
>
> I ll giving a few attributes in .composite file for ode runtime to start
> and
> run, so how to read this attributes from .composite file?
> If the ImplementationActivator does the job of reading the composite file
> then through which instance i could get these attributes which specify in
> the composite file?
>
> In the prev M2 release, we had ImplementationLoader where in we had
> XMLStreamReader .
> Through which we can access the attricutes we give in the scdl.
> Like ( reader.getAttributeValue(..) )
>
> So now how can i do this ?


The script implementation is using the simpler extension spi prototype which
is a bit different from the other spi. It uses a simple pojo class for the
implementation and the getters/setters define which attributes are expected
in the scdl, the runtime automatically calls the setters with the values of
the scdl attribudes. You may be able to do what you need with the Ode
extension with this simple spi but it is still being developed and not
stable so you could also just use the other SPI as shown in the CRUD sample.

   ...ant




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

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

[jira] Updated: (TUSCANY-1364) sdo-impl should export org.apache.tuscany.sdo.model.internal

[Brian Murray (JIRA)]

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

Brian Murray updated TUSCANY-1364:
--

Attachment: 1364.patch

This may have been a case where somebody else made a fix to the build between 
my initial run (seeing the problem) and my adding this fix (and not seeing the 
problem).  I will be unavailable until Monday June 23rd.  I will at that time 
verify that this was indeed the problem and this is indeed the fix.  

> sdo-impl should export org.apache.tuscany.sdo.model.internal
> 
>
> Key: TUSCANY-1364
> URL: https://issues.apache.org/jira/browse/TUSCANY-1364
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
>Reporter: Brian Murray
> Fix For: Java-SDO-1.0
>
> Attachments: 1364.patch, 1364.patch
>
>
> The org.apache.tuscany.sdo.model.internal package was introduced somewhat 
> recently, and is visible in a statically generated class.  The problem is 
> that the impl project does not export this package.  
> For example, I ran the XSD2JavaGenerator tool on 
> sdo\impl\src\test\resources\bank.xsd and here are some snippets from the 
> resulting MybankFactory.impl:
> import org.apache.tuscany.sdo.model.internal.InternalFactory;
> ...
>   public static MybankFactoryImpl init()
>   {
> if (isInited) return 
> (MybankFactoryImpl)FactoryBase.getStaticFactory(MybankFactoryImpl.NAMESPACE_URI);
> MybankFactoryImpl theMybankFactoryImpl = new MybankFactoryImpl();
> isInited = true;
> // Initialize dependencies
> SDOUtil.registerStaticTypes(SDOFactory.class);
> SDOUtil.registerStaticTypes(ModelFactory.class);
> SDOUtil.registerStaticTypes(InternalFactory.class);
> I am providing a patch to the sdo/impl/pom.xml which will export this package.

-- 
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: Domains, runtimes, components and cardinality

[Simon Laws]

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


Hi,

I guess it should be a good start to have SCA domains span across runtimes
and leave the runtimes being shared by SCA domains to the next iteration.

As for the second point, is there a possibility of seeing this as
replication of components across two runtimes instead of nodes?  Anyways,
to
start with, I'd be happy to leave this out for the next iteration.

Thanks

- Venkat


On 6/18/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> Following on from recent discussion on the distributed binding (I've
been
> putting notes here [1])... In a Tuscany SCA runtime what do we expect
the
> cardinality between the various parts of it to be?
>
> A domain notionally runs on a runtime. In the case of a stand-alone
> Tuscany
> SCA runtime this will be a single process (C++ exe, Java VM etc.). In
the
> case of a distributed Tuscany SCA runtime, the runtime is made up of
many
> distributed nodes that each run parts of the domain.
>
> 1/ Can domains share runtimes/nodes?
>
> I.e can components from more than one domain be running inside a single
> Tuscany SCA runtime or is the user expected to start up multiple
runtimes
> to
> run multiple domains.
>
> 2/ How many nodes can a single component run on?.
>
> I.e. is the assignment of a component to multiple nodes, for
performance,
> reliability etc. reasons, explicitly supported as part of the topology
> description of a distributed domain. If so then the  SCA binding chooses
> which node to use. If not then any distribution of workload is
considered
> to
> be a job for the node implementation.
>
> I'd be interested to hear peoples views on this
>
> My starting point is...
>
> 1/ No, we will support multiple domains by starting multiple runtimes.
We
> could add the extra function to support sharing of runtimes between
> domains
> in the future if it's found to be required.
>
> 2/ We shouldn't restrict whatever structure we use to describe the
> component/node association to be 1-1. But we can assume 1 in the first
> instance and consider adding more complex node selection features to the
> SCA
> binding in the future.
>
> Regards
>
> Simon
>
> [1]
http://cwiki.apache.org/confluence/pages/editpage.action?pageId=59826
>


OK,  thanks for your comments. It seems like we agree. In the first instance
then I've checked in my code with the assumption that

a component only runs on one node
a node only supports one domain

Having said that I've built some topology model classes that allow for this
simple case but don't restrict us to this. I'm not using these model classes
yet (in the sample the component to node mapping is hard coded) but the next
job is to plumb it in.

I'm just about to post a quick summary of what I've checked in.

Simon

Re: 0.91 release?

[Luciano Resende]

The extensions that depend on DAS are not going to be a part of this

release and am

excluding them though they have been specifed in the wiki.


Thanks, I have removed these items from the wiki already...

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

I can speak for the following

binding-jms - Works for sychronous, Java object based messages and
implements a part of the spec but not all of it. So it depends on how
comfortable we are with spec incomplete bindings. I would leave it out for
now

binding-sca - part of the distributed runtime. All checked in now with a
working sample but uses binding-jms (as there is a lack of point to point
protocols that I can leverage without change).  Am just writing mail now to
describe what I've been up to and now you've taken the branch I'll put it in
the build.

Are we releasing the demos this time? Were you sans aggregator because there
is a problem with it? I can go fix it if so. I know I should go try it but I
haven't checked the branch out yet;-)

Simon




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

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

[C++] SDO - preventing SDO from loading schema across the network

[Simon Laws]

Posting to tuscany and php lists

I raised a bug (http://issues.apache.org/jira/browse/TUSCANY-1362) as we
noticed in PHP that C++ SDO was going out across the network to find schema
identified by namespace alone even when the schema had already been read.
The problem is that the list that is used to check whether the schema has
been seen already is based on the location of the schema. So when something
later tries to read the schema based on namespace it can't tell it's seen
it.

I have a fix which involves storing a second list of namespaces seen before
to sit alongside the locations seen before list. This list can then be
checked as well. Now the worry I have in implementing this is that I believe
if we check schema loads against the previous seen namespaces it means that
we can't load types for a namespace from more than one file. Is this a
scenario that is important to support?

Regards

Simon

[jira] Updated: (TUSCANY-1364) sdo-impl should export org.apache.tuscany.sdo.model.internal

[Frank Budinsky (JIRA)]

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

Frank Budinsky updated TUSCANY-1364:


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

> sdo-impl should export org.apache.tuscany.sdo.model.internal
> 
>
> Key: TUSCANY-1364
> URL: https://issues.apache.org/jira/browse/TUSCANY-1364
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
>Reporter: Brian Murray
> Fix For: Java-SDO-1.0
>
> Attachments: 1364.patch
>
>
> The org.apache.tuscany.sdo.model.internal package was introduced somewhat 
> recently, and is visible in a statically generated class.  The problem is 
> that the impl project does not export this package.  
> For example, I ran the XSD2JavaGenerator tool on 
> sdo\impl\src\test\resources\bank.xsd and here are some snippets from the 
> resulting MybankFactory.impl:
> import org.apache.tuscany.sdo.model.internal.InternalFactory;
> ...
>   public static MybankFactoryImpl init()
>   {
> if (isInited) return 
> (MybankFactoryImpl)FactoryBase.getStaticFactory(MybankFactoryImpl.NAMESPACE_URI);
> MybankFactoryImpl theMybankFactoryImpl = new MybankFactoryImpl();
> isInited = true;
> // Initialize dependencies
> SDOUtil.registerStaticTypes(SDOFactory.class);
> SDOUtil.registerStaticTypes(ModelFactory.class);
> SDOUtil.registerStaticTypes(InternalFactory.class);
> I am providing a patch to the sdo/impl/pom.xml which will export this package.

-- 
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: 0.91 release?

[Simon Laws]

I can speak for the following

binding-jms - Works for sychronous, Java object based messages and
implements a part of the spec but not all of it. So it depends on how
comfortable we are with spec incomplete bindings. I would leave it out for
now

binding-sca - part of the distributed runtime. All checked in now with a
working sample but uses binding-jms (as there is a lack of point to point
protocols that I can leverage without change).  Am just writing mail now to
describe what I've been up to and now you've taken the branch I'll put it in
the build.

Are we releasing the demos this time? Were you sans aggregator because there
is a problem with it? I can go fix it if so. I know I should go try it but I
haven't checked the branch out yet;-)

Simon

Re: 0.91 release?

[Venkata Krishnan]

Hi,

I have the branch building modules, itests, samples and demos (sans the
aggregator).  I have rolled back the SDO dependencies to the beta1 release
in the branch.

Now I'd like to figure out the modules that we intend to actually include in
this release.  Here is a list of the modules that were a part of the trunks
build, this morning when I cut the branch and are additions over what we
already had for Rel. 0.90.

- binding-jms
- binding-ajax
- binding-ejb
- binding-feed
- databinding-json
- extension-helper
- implementation-bpel
- implementation-resource
- implementation-spring
- topology
- topology-xml

Out of these I know for sure from the wiki (
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents)
that we are going to include the following.  The extensions that depend on
DAS are not going to be a part of this release and am excluding them though
they have been specifed in the wiki.

- binding-ajax
- extension-helper

What do people think about the others.  IMHO, I guess we could include the
following
- binding-ejb
- binding-feed
- implementation-spring

There are a whole lot of others as well on the trunk which are presently not
a part of the build but interesting though :
- binding-sca
- binding-osgi
- implementation-osgi
- the geronimo integration
- implementation-bpel

I am really not sure where we are with these but just about feel that they
are not ready for the release round the corner as they are not yet a part of
the trunk build as of this morning.  However I'd like to know if there are
other opinions on this.

I hope to finalize on this list today so that I may start working on the
distributions tomorrow.

Also, please feel free to point out anything that I might have missed out on
all of this.

Thanks

- Venkat


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


Hi,

I guess the changes after beta1 are to do with some restructuring of
classes across packages.  Also when I rolled back the SDO DB back to beta1,
it seems to build fine with just changes to the package names it was using.
So seems like beta1 seems ok for SDO Databinding.  Let me do the same for
the others and get back.

- Venkat

On 6/20/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 6/20/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I have cut a branch for the 0.91 release and have changed over the
> > artifact
> > versions to 0.91-incubating-SNAPSHOT.  I am now trying to build it and
> > here
> > are some problems that I have observed.
> >
> > - The SDO dependency seems to be on the current
> > 1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl
> > and sdo-lib that are being used
> > as dependencies in the SDO Databinding.  This does not match with the
> last
> > sdo release of 1.0-incubating-beta1 .  So how are we going to go
> forward
> > with
> > the SDO dependency for this SCA release?  Are we going to roll back
> things
> > to beta1 (which is not something I'd be happy about) or should we
> consider
> > using a snapshot from the trunk (which is also something that we have
> > decided not to do)  or is there another alternative to this?  Could
> people
> > please help in this.
> >
> > Thanks
> >
> > - Venkat
> >
> > On 6/19/07, Simon Nash < [EMAIL PROTECTED] > wrote:
> > >
> > > I would prefer not to delay SCA 0.91 for the DAS support.  Unless we
> > > are confident that the DAS release can be created quickly, I think
> > > it's better to go ahead with SCA 0.91 as planned and defer the DAS
> > > support.
> > >
> > > An alternative packaging approach (which I am starting to think
> would
> > > be even better) is to reverse the dependency and have the DAS
> release
> > > ship the pieces identified by Luciano below.  It should be possible
> > > (even desirable) for Tuscany SCA extensions that support another
> > > technology to ship as part of a release of that technology rather
> than
> > > always making them part of a Tuscany SCA release.
> > >
> > >Simon
> > >
> > > Venkata Krishnan wrote:
> > >
> > > > Hi Luciano,
> > > >
> > > > This is a surprise :)... I was planning on taking the 0.91 brn
> > tomorrow
> > > and
> > > > imediately start getting out RCs to vote on, but I can't do that
> if it
> >
> > > > needs
> > > > to include the DAS beta1 release???.
> > > >
> > > > What do people think?
> > > >
> > > > - Venkat
> > > >
> > > > On 6/18/07, Luciano Resende < [EMAIL PROTECTED] > wrote:
> > > >
> > > >>
> > > >> Sorry, I'm having some restricted internet access as I'm
> traveling
> > > >> since last week... that's probably why we haven't created a DAS
> > > >> release candidate yet... but the community and I think that we
> are
> > > >> ready to have one.
> > > >>
> > > >> Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on
> the
> > > >> following items:
> > > >>- implementation.das
> > > >>- implementation.data
> > > >>- some samples (maybe including the samples we didn't ship in
> 0.9)
> > > >>
> > > >> On 6/1

Re: Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

[Pete Robbins]

Brady,

Welcome aboard! The best way to proceed is to open a Jira (
https://issues.apache.org/jira/browse/TUSCANY) describing what you are
trying to achieve then attach a patch to the Jira. It's usually a good idea
to post on tuscany_dev when you submit a patch as some of us filter off Jira
messages and don't immediately see them. Then... some kindly committer can
apply and test the patch and, if all is well, commit it to subversion.

What you are proposing sounds very reasonable so I will look out for a Jira
and patch.

Cheers,


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


Hello all,

Im investigating using TuscanySCA (C++ version) with a container other
than Axis. To do this, the container needs to be able to obtain the WSDL
operations, etc loaded by Tuscany. I would like to propose extending
some of the Tuscany APIs to allow them to be queried, since currently
you can only do a find with an operation name. These query operations
could be done either by returning an iterator to the internal map, or by
just returning a list of map's value strings. The second option would
probably be safer and more thread-safe. Below are the extensions that I
propose adding:

runtime/core/src/tuscany/sca/model/Composite.h/cpp
   std::list Composite::getNamespaces();

runtime/core/src/tuscany/sca/model/WSDLDefinition.h/cpp
   std::list WSDLDefinition::getPortTypes();
   std::list WSDLDefinition::getOperations( const
std::string &portTypeName );

If its decided to allow the internal map to be iterated over, the
interface would look something like this:
runtime/core/src/tuscany/sca/model/Composite.h/cpp
   std::map::const_iterator
Composite::getNamespacesIteratorBegin();
   std::map::const_iterator
Composite::getNamespacesIteratorEnd();

Once the projects have been loaded by calling:
   tuscany::sca::SCARuntime::initializeSharedRuntime()

The system composite can then be obtained by calling:
   tuscany::sca::model::Composite* SCARuntime::getSystem();

With the system composite, the extension to the Composite class would
allow you to get all of the WSDL namespaces loaded. Then for each
namespace, the WSDLDefinition can be obtained by calling:
   WSDLDefinition* Composite::findWSDLDefinition(const std::string&
wsdlNamespace);

Then, for each WSDLDefinition, all of the WSDL PortTypes can be obtained
by calling the getPortTypes() method above. Then for each PortType, the
actual operations can be retreived by calling the getOperations() method
above.

Im not currently a TuscanySCA contributor, so what would it take to get
these changes in?

Thanks


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





--
Pete

Re: Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

[Andrew Borley]

Hi Brady,

That would need that standard Apache way (tm)!

Raise an issue in our Jira system (under the SCA C++ component), check
out the code head from SVN, make your changes, make sure they compile
and the basic tests run and then create a patch and attach it to the
Jira. Add a note on this thread to explain what you've changed and a
committer should check and apply the patch.

The idea is that you do the above often enough so that the committers
get bored of applying your patches and vote you on as a committer!

Cheers
Andy

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

Hello all,

Im investigating using TuscanySCA (C++ version) with a container other
than Axis. To do this, the container needs to be able to obtain the WSDL
operations, etc loaded by Tuscany. I would like to propose extending
some of the Tuscany APIs to allow them to be queried, since currently
you can only do a find with an operation name. These query operations
could be done either by returning an iterator to the internal map, or by
just returning a list of map's value strings. The second option would
probably be safer and more thread-safe. Below are the extensions that I
propose adding:

runtime/core/src/tuscany/sca/model/Composite.h/cpp
std::list Composite::getNamespaces();

runtime/core/src/tuscany/sca/model/WSDLDefinition.h/cpp
std::list WSDLDefinition::getPortTypes();
std::list WSDLDefinition::getOperations( const
std::string &portTypeName );

If its decided to allow the internal map to be iterated over, the
interface would look something like this:
runtime/core/src/tuscany/sca/model/Composite.h/cpp
std::map::const_iterator
Composite::getNamespacesIteratorBegin();
std::map::const_iterator
Composite::getNamespacesIteratorEnd();

Once the projects have been loaded by calling:
tuscany::sca::SCARuntime::initializeSharedRuntime()

The system composite can then be obtained by calling:
tuscany::sca::model::Composite* SCARuntime::getSystem();

With the system composite, the extension to the Composite class would
allow you to get all of the WSDL namespaces loaded. Then for each
namespace, the WSDLDefinition can be obtained by calling:
WSDLDefinition* Composite::findWSDLDefinition(const std::string&
wsdlNamespace);

Then, for each WSDLDefinition, all of the WSDL PortTypes can be obtained
by calling the getPortTypes() method above. Then for each PortType, the
actual operations can be retreived by calling the getOperations() method
above.

Im not currently a TuscanySCA contributor, so what would it take to get
these changes in?

Thanks


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




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

Re: How to get an instance of the read composite file ?

[ant elder]

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


Hello All,

In the implementation script module, there should be some place where the
[.composite] file information are read .

Can any one mention where this is read ?

Is it in the AbstractSCATestCase ?


Am now trying implementation bpel (ie integrating Apaceh ODE-bpel and
Tuscany-SCA)

I ll giving a few attributes in .composite file for ode runtime to start
and
run, so how to read this attributes from .composite file?
If the ImplementationActivator does the job of reading the composite file
then through which instance i could get these attributes which specify in
the composite file?

In the prev M2 release, we had ImplementationLoader where in we had
XMLStreamReader .
Through which we can access the attricutes we give in the scdl.
Like ( reader.getAttributeValue(..) )

So now how can i do this ?



The script implementation is using the simpler extension spi prototype which
is a bit different from the other spi. It uses a simple pojo class for the
implementation and the getters/setters define which attributes are expected
in the scdl, the runtime automatically calls the setters with the values of
the scdl attribudes. You may be able to do what you need with the Ode
extension with this simple spi but it is still being developed and not
stable so you could also just use the other SPI as shown in the CRUD sample.

  ...ant

[jira] Commented: (TUSCANY-1364) sdo-impl should export org.apache.tuscany.sdo.model.internal

[Brian Murray (JIRA)]

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

Brian Murray commented on TUSCANY-1364:
---

Symptom:  Prior to this patch I was seeing a java.lang.NoClassDefFoundError: 
org.apache.tuscany.sdo.model.internal.InternalFactory

> sdo-impl should export org.apache.tuscany.sdo.model.internal
> 
>
> Key: TUSCANY-1364
> URL: https://issues.apache.org/jira/browse/TUSCANY-1364
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Brian Murray
> Attachments: 1364.patch
>
>
> The org.apache.tuscany.sdo.model.internal package was introduced somewhat 
> recently, and is visible in a statically generated class.  The problem is 
> that the impl project does not export this package.  
> For example, I ran the XSD2JavaGenerator tool on 
> sdo\impl\src\test\resources\bank.xsd and here are some snippets from the 
> resulting MybankFactory.impl:
> import org.apache.tuscany.sdo.model.internal.InternalFactory;
> ...
>   public static MybankFactoryImpl init()
>   {
> if (isInited) return 
> (MybankFactoryImpl)FactoryBase.getStaticFactory(MybankFactoryImpl.NAMESPACE_URI);
> MybankFactoryImpl theMybankFactoryImpl = new MybankFactoryImpl();
> isInited = true;
> // Initialize dependencies
> SDOUtil.registerStaticTypes(SDOFactory.class);
> SDOUtil.registerStaticTypes(ModelFactory.class);
> SDOUtil.registerStaticTypes(InternalFactory.class);
> I am providing a patch to the sdo/impl/pom.xml which will export this package.

-- 
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-1364) sdo-impl should export org.apache.tuscany.sdo.model.internal

[Brian Murray (JIRA)]

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

Brian Murray updated TUSCANY-1364:
--

Attachment: 1364.patch

> sdo-impl should export org.apache.tuscany.sdo.model.internal
> 
>
> Key: TUSCANY-1364
> URL: https://issues.apache.org/jira/browse/TUSCANY-1364
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Brian Murray
> Attachments: 1364.patch
>
>
> The org.apache.tuscany.sdo.model.internal package was introduced somewhat 
> recently, and is visible in a statically generated class.  The problem is 
> that the impl project does not export this package.  
> For example, I ran the XSD2JavaGenerator tool on 
> sdo\impl\src\test\resources\bank.xsd and here are some snippets from the 
> resulting MybankFactory.impl:
> import org.apache.tuscany.sdo.model.internal.InternalFactory;
> ...
>   public static MybankFactoryImpl init()
>   {
> if (isInited) return 
> (MybankFactoryImpl)FactoryBase.getStaticFactory(MybankFactoryImpl.NAMESPACE_URI);
> MybankFactoryImpl theMybankFactoryImpl = new MybankFactoryImpl();
> isInited = true;
> // Initialize dependencies
> SDOUtil.registerStaticTypes(SDOFactory.class);
> SDOUtil.registerStaticTypes(ModelFactory.class);
> SDOUtil.registerStaticTypes(InternalFactory.class);
> I am providing a patch to the sdo/impl/pom.xml which will export this package.

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


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

[jira] Created: (TUSCANY-1364) sdo-impl should export org.apache.tuscany.sdo.model.internal

[Brian Murray (JIRA)]

sdo-impl should export org.apache.tuscany.sdo.model.internal


 Key: TUSCANY-1364
 URL: https://issues.apache.org/jira/browse/TUSCANY-1364
 Project: Tuscany
  Issue Type: Bug
Reporter: Brian Murray


The org.apache.tuscany.sdo.model.internal package was introduced somewhat 
recently, and is visible in a statically generated class.  The problem is that 
the impl project does not export this package.  

For example, I ran the XSD2JavaGenerator tool on 
sdo\impl\src\test\resources\bank.xsd and here are some snippets from the 
resulting MybankFactory.impl:

import org.apache.tuscany.sdo.model.internal.InternalFactory;
...
  public static MybankFactoryImpl init()
  {
if (isInited) return 
(MybankFactoryImpl)FactoryBase.getStaticFactory(MybankFactoryImpl.NAMESPACE_URI);
MybankFactoryImpl theMybankFactoryImpl = new MybankFactoryImpl();
isInited = true;

// Initialize dependencies
SDOUtil.registerStaticTypes(SDOFactory.class);
SDOUtil.registerStaticTypes(ModelFactory.class);
SDOUtil.registerStaticTypes(InternalFactory.class);

I am providing a patch to the sdo/impl/pom.xml which will export this package.

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

Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

[Brady Johnson]

Hello all,
 
Im investigating using TuscanySCA (C++ version) with a container other
than Axis. To do this, the container needs to be able to obtain the WSDL
operations, etc loaded by Tuscany. I would like to propose extending
some of the Tuscany APIs to allow them to be queried, since currently
you can only do a find with an operation name. These query operations
could be done either by returning an iterator to the internal map, or by
just returning a list of map's value strings. The second option would
probably be safer and more thread-safe. Below are the extensions that I
propose adding:
 
runtime/core/src/tuscany/sca/model/Composite.h/cpp
std::list Composite::getNamespaces();

runtime/core/src/tuscany/sca/model/WSDLDefinition.h/cpp
std::list WSDLDefinition::getPortTypes();
std::list WSDLDefinition::getOperations( const
std::string &portTypeName );
 
If its decided to allow the internal map to be iterated over, the
interface would look something like this:
runtime/core/src/tuscany/sca/model/Composite.h/cpp
std::map::const_iterator
Composite::getNamespacesIteratorBegin();
std::map::const_iterator
Composite::getNamespacesIteratorEnd();
 
Once the projects have been loaded by calling:
tuscany::sca::SCARuntime::initializeSharedRuntime()
 
The system composite can then be obtained by calling:
tuscany::sca::model::Composite* SCARuntime::getSystem();
 
With the system composite, the extension to the Composite class would
allow you to get all of the WSDL namespaces loaded. Then for each
namespace, the WSDLDefinition can be obtained by calling:
WSDLDefinition* Composite::findWSDLDefinition(const std::string&
wsdlNamespace);
 
Then, for each WSDLDefinition, all of the WSDL PortTypes can be obtained
by calling the getPortTypes() method above. Then for each PortType, the
actual operations can be retreived by calling the getOperations() method
above.
 
Im not currently a TuscanySCA contributor, so what would it take to get
these changes in?
 
Thanks
 

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

Re: 0.91 release?

[Venkata Krishnan]

Hi,

I guess the changes after beta1 are to do with some restructuring of classes
across packages.  Also when I rolled back the SDO DB back to beta1, it seems
to build fine with just changes to the package names it was using.  So seems
like beta1 seems ok for SDO Databinding.  Let me do the same for the others
and get back.

- Venkat

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


On 6/20/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have cut a branch for the 0.91 release and have changed over the
> artifact
> versions to 0.91-incubating-SNAPSHOT.  I am now trying to build it and
> here
> are some problems that I have observed.
>
> - The SDO dependency seems to be on the current
> 1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl
> and sdo-lib that are being used
> as dependencies in the SDO Databinding.  This does not match with the
last
> sdo release of 1.0-incubating-beta1 .  So how are we going to go forward
> with
> the SDO dependency for this SCA release?  Are we going to roll back
things
> to beta1 (which is not something I'd be happy about) or should we
consider
> using a snapshot from the trunk (which is also something that we have
> decided not to do)  or is there another alternative to this?  Could
people
> please help in this.
>
> Thanks
>
> - Venkat
>
> On 6/19/07, Simon Nash <[EMAIL PROTECTED] > wrote:
> >
> > I would prefer not to delay SCA 0.91 for the DAS support.  Unless we
> > are confident that the DAS release can be created quickly, I think
> > it's better to go ahead with SCA 0.91 as planned and defer the DAS
> > support.
> >
> > An alternative packaging approach (which I am starting to think would
> > be even better) is to reverse the dependency and have the DAS release
> > ship the pieces identified by Luciano below.  It should be possible
> > (even desirable) for Tuscany SCA extensions that support another
> > technology to ship as part of a release of that technology rather than
> > always making them part of a Tuscany SCA release.
> >
> >Simon
> >
> > Venkata Krishnan wrote:
> >
> > > Hi Luciano,
> > >
> > > This is a surprise :)... I was planning on taking the 0.91 brn
> tomorrow
> > and
> > > imediately start getting out RCs to vote on, but I can't do that if
it
>
> > > needs
> > > to include the DAS beta1 release???.
> > >
> > > What do people think?
> > >
> > > - Venkat
> > >
> > > On 6/18/07, Luciano Resende < [EMAIL PROTECTED]> wrote:
> > >
> > >>
> > >> Sorry, I'm having some restricted internet access as I'm traveling
> > >> since last week... that's probably why we haven't created a DAS
> > >> release candidate yet... but the community and I think that we are
> > >> ready to have one.
> > >>
> > >> Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the
> > >> following items:
> > >>- implementation.das
> > >>- implementation.data
> > >>- some samples (maybe including the samples we didn't ship in
0.9)
> > >>
> > >> On 6/18/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > >> > What will be the relationship between SCA 0.91 and DAS?  I have
> seen
> > >> > some discussions on the list about a DAS release.  Will SCA
0.91have
> > >> > this DAS release as a dependency?
> > >> >
> > >> >Simon
> > >> >
> > >> > Luciano Resende wrote:
> > >> >
> > >> > > I have updated the wiki [1] page with things that I'm working
on,
>
> > and
> > >> > > would like to have in 0.91 .
> > >> > >
> > >> > > As for the implementation.das question regarding it's canned
> derby
> > >> db,
> > >> > > we recently created a db utility to create and populate the
> > database,
> > >> > > and I have plans to integrate with it.
> > >> > >
> > >> > > [1]
> > >> > >
> > >>
> >
>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
> > >>
> > >> > >
> > >> > >
> > >> > > On 6/16/07, ant elder < [EMAIL PROTECTED]> wrote:
> > >> > >
> > >> > >> Wow 571 license problems! after being clean for 0.90 just a
> month
> > >> ago.
> > >> > >>
> > >> > >> One question this brings up is what is actually intended to be
> > >> > >> included in
> > >> > >> 0.91? There's been quite a few new extensions and demo's etc
> added
> > >> > >> recently
> > >> > >> but no one has said they want those included in 0.91. Should
> they
> > be
> > >> by
> > >> > >> default or should we just include things that are mentioned on
> the
> > >> > >> release
> > >> > >> wiki page? If so anyone else care to help clean things up, add
> > >> missing
> > >> > >> license headers, check the distribution works and includes
> > >> > >> dependencies etc?
> > >> > >> The implementation.das is including an entire database in the
> > >> src, is
> > >> > >> there
> > >> > >> any way that could be generated by the tests?
> > >> > >>
> > >> > >>...ant
> > >> > >>
> > >> > >> On 6/16/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > >> > >> >
> > >> > >> > Thanks Ant.  So could we all please use this wiki page to
put
> > down
> > >> > >> things
> > >> > >> 

Re: 0.91 release?

[Simon Laws]

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


Hi,

I have cut a branch for the 0.91 release and have changed over the
artifact
versions to 0.91-incubating-SNAPSHOT.  I am now trying to build it and
here
are some problems that I have observed.

- The SDO dependency seems to be on the current
1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl
and sdo-lib that are being used
as dependencies in the SDO Databinding.  This does not match with the last
sdo release of 1.0-incubating-beta1 .  So how are we going to go forward
with
the SDO dependency for this SCA release?  Are we going to roll back things
to beta1 (which is not something I'd be happy about) or should we consider
using a snapshot from the trunk (which is also something that we have
decided not to do)  or is there another alternative to this?  Could people
please help in this.

Thanks

- Venkat

On 6/19/07, Simon Nash <[EMAIL PROTECTED] > wrote:
>
> I would prefer not to delay SCA 0.91 for the DAS support.  Unless we
> are confident that the DAS release can be created quickly, I think
> it's better to go ahead with SCA 0.91 as planned and defer the DAS
> support.
>
> An alternative packaging approach (which I am starting to think would
> be even better) is to reverse the dependency and have the DAS release
> ship the pieces identified by Luciano below.  It should be possible
> (even desirable) for Tuscany SCA extensions that support another
> technology to ship as part of a release of that technology rather than
> always making them part of a Tuscany SCA release.
>
>Simon
>
> Venkata Krishnan wrote:
>
> > Hi Luciano,
> >
> > This is a surprise :)... I was planning on taking the 0.91 brn
tomorrow
> and
> > imediately start getting out RCs to vote on, but I can't do that if it

> > needs
> > to include the DAS beta1 release???.
> >
> > What do people think?
> >
> > - Venkat
> >
> > On 6/18/07, Luciano Resende < [EMAIL PROTECTED]> wrote:
> >
> >>
> >> Sorry, I'm having some restricted internet access as I'm traveling
> >> since last week... that's probably why we haven't created a DAS
> >> release candidate yet... but the community and I think that we are
> >> ready to have one.
> >>
> >> Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the
> >> following items:
> >>- implementation.das
> >>- implementation.data
> >>- some samples (maybe including the samples we didn't ship in 0.9)
> >>
> >> On 6/18/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> >> > What will be the relationship between SCA 0.91 and DAS?  I have
seen
> >> > some discussions on the list about a DAS release.  Will SCA 0.91have
> >> > this DAS release as a dependency?
> >> >
> >> >Simon
> >> >
> >> > Luciano Resende wrote:
> >> >
> >> > > I have updated the wiki [1] page with things that I'm working on,

> and
> >> > > would like to have in 0.91 .
> >> > >
> >> > > As for the implementation.das question regarding it's canned
derby
> >> db,
> >> > > we recently created a db utility to create and populate the
> database,
> >> > > and I have plans to integrate with it.
> >> > >
> >> > > [1]
> >> > >
> >>
>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
> >>
> >> > >
> >> > >
> >> > > On 6/16/07, ant elder < [EMAIL PROTECTED]> wrote:
> >> > >
> >> > >> Wow 571 license problems! after being clean for 0.90 just a
month
> >> ago.
> >> > >>
> >> > >> One question this brings up is what is actually intended to be
> >> > >> included in
> >> > >> 0.91? There's been quite a few new extensions and demo's etc
added
> >> > >> recently
> >> > >> but no one has said they want those included in 0.91. Should
they
> be
> >> by
> >> > >> default or should we just include things that are mentioned on
the
> >> > >> release
> >> > >> wiki page? If so anyone else care to help clean things up, add
> >> missing
> >> > >> license headers, check the distribution works and includes
> >> > >> dependencies etc?
> >> > >> The implementation.das is including an entire database in the
> >> src, is
> >> > >> there
> >> > >> any way that could be generated by the tests?
> >> > >>
> >> > >>...ant
> >> > >>
> >> > >> On 6/16/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >> > >> >
> >> > >> > Thanks Ant.  So could we all please use this wiki page to put
> down
> >> > >> things
> >> > >> > that are going to be increments over 0.90.
> >> > >> >
> >> > >> > Also I run the RAT on the trunk - just java/sca and here is
the
> >> > >> report.  I
> >> > >> > intend to go and fix the missing headers just ahead of cutting
> the
> >> > >> branch.
> >> > >> > Before that if anybody would like to jump in and help with
this,
> >> > >> please feel
> >> > >> > free do so.
> >> > >> >
> >> > >> >
> >> > >> 
http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt
<
> >> http://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt>
> >> > >>
> >> > >> >
> >> > >> > Thanks
> >> > >> >
> >> > 

[jira] Resolved: (TUSCANY-1311) Bring JMS extension into line with the 0.90 SPIs

[Simon Laws (JIRA)]

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

Simon Laws resolved TUSCANY-1311.
-

Resolution: Fixed

As per previous comment the JMS binding runs on the 0.90 SPI but with limited 
features compared to what is called for in the spec.Adding more features though 
should be another JIRA

> Bring JMS extension into line with the 0.90 SPIs
> 
>
> Key: TUSCANY-1311
> URL: https://issues.apache.org/jira/browse/TUSCANY-1311
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA JMS Binding Extension
>Affects Versions: Java-SCA-Next
>Reporter: Simon Laws
>Assignee: Simon Laws
> Fix For: Java-SCA-0.90
>
>
> Port JMS binding from M2 code based to 0.90 code base

-- 
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-1311) Bring JMS extension into line with the 0.90 SPIs

[Simon Laws (JIRA)]

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

Simon Laws updated TUSCANY-1311:


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

> Bring JMS extension into line with the 0.90 SPIs
> 
>
> Key: TUSCANY-1311
> URL: https://issues.apache.org/jira/browse/TUSCANY-1311
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA JMS Binding Extension
>Affects Versions: Java-SCA-Next
>Reporter: Simon Laws
>Assignee: Simon Laws
> Fix For: Java-SCA-0.90
>
>
> Port JMS binding from M2 code based to 0.90 code base

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

AW: Contribute to SCA-OSGi integration

[Wengatz, Nicole]

Hi Graham,

I'm still not sure if the proposal is consistent.

Let my explain my concerns:
Every OSGi container provides an OSGi registry. In the OSGi
enterprise expert group we are currently discussing that proxies
for other services (e.g. EJB stateless Bean which is accessible via 
IIOP) will be created and registered in the OSGi registry.
>From this point of view, your proposal for the implementation.osgi
is consistent.
But do we want to have different behaviour for different SCA implementations
types? Do you expect for example that an implementation.ejb adds remote
proxies to the JNDI service? Or what about implementation.net or 
implementation.c,
do we need now a registry for all implementation types?

I still think that explicit bindings are better.

What do the others on the list think?

Thanks
Nicole

P.S.: Graham, Tim told me today that you are going to be at the F2F in Munich 
next week.
Looking forward to meeting you there :-)

-Ursprüngliche Nachricht-
Von: Graham Charters [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 19. Juni 2007 17:10
An: tuscany-dev@ws.apache.org
Betreff: Re: Contribute to SCA-OSGi integration

Hi Nicole,

My turn to chip in :-)

I think both approaches are valid and tackle two different goals.  If
I understand correctly, then the binding approach does not hand the
responsibility for the OSGi bundles and services to SCA.  So this is
more of a peer-to-peer runtime view.  I think this approach is
appealing if you want to keep OSGi outside the SCA domain for either
organizational reasons, or because you don't want to model some
existing OSGi application in SCA.

The implementation.osgi approach is trying to take an SCA assembly
view of the problem where you want to describe and manage the assembly
of the OSGi assets with other implementation technologies.  Here SCA
is responsible for managing the OSGi bundles (installation,
activation), and ensuring their external dependencies are resolved.

I've inlined some additional comments below.

On 19/06/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote:
> Hi Rajini,
>
> I would prefer a solution where you declare explicitly the bindings, not an 
> implicit registration
> of services.
>
> Please find below a snippet of the OSGi prototype provided by Joel some time 
> ago:
>
> 
>  interface="test.sca.osgi.binding.supplychain.Retailer"/>
>  service="test.sca.osgi.binding.supplychain.Retailer"/>
> RetailerComponent
> 
>
> 
>  class="test.sca.osgi.binding.retailer_warehouse.impl.RetailerComponentImpl"/>
>  target="WarehouseComponent">WarehouseComponent
> 
>
> RetailerComponent will not be registered automatically (without a service). 
> The Service tag provides the
> information via which binding the RetailerComponent will be accessible, in 
> this case via an OSGi Binding.
> The SCA runtime detects the OSGi binding and registers the RetailerComponent 
> as OSGi service in the
> OSGi registry.
>
> The Client uses a reference with OSGi binding to access the RetailerService:
>  
>  class="test.sca.osgi.binding.client.impl.CustomerComponentImpl"/>
>  target="RetailerService">RetailerService
> 
>
>  target="Nothing">
>  interface="test.sca.osgi.binding.supplychain.Retailer"/>
>  service="test.sca.osgi.binding.supplychain.Retailer" 
> filter="(objectclass=test.sca.osgi.binding.supplychain.Retailer)" 
> immediate="false"/>
> 
>
> In this case the SCA runtime looks up the Retailer OSGi service in the 
> registry and injects it into
> the CustomerComponent which is the client.
>
> From my point of view we need such an OSGi Binding for the communication of 
> SCA components running in
> different implementation types. If we have only an OSGi implementation type I 
> would use instead of an OSGi
> binding the OSGI R4 DS (Declarative Services) or Spring OSGi.
>

Both approaches allow OSGi bundles to talk to SCA components built
using different implementation types.  For the binding approach it's
whatever the service with the OSGi binding is wired to in SCA.  For
the implementation.osgi approach, it's whatever the component
reference is wired to.  The runtime needs to make good on this
relationship.  So, an SCA component with an implementation type of
OSGi can be directly wired to an SCA component with an implementation
of Java, or BPEL, etc...

> Questions/Remarks to you proposal:
> >A proxy service is registered in the OSGi registry for the Retailer by the
> >Tuscany OSGi implementation provider when CustomerComponent is processed.
> From my point of view the provider (in this case Retailer) should decide how 
> it is
> accessible, not the client. What happens if Retailer is not declared in the 
> same composite?
> Are you going to search for matching components in the complete SCA domain?
>

I think this is another example of the two different scenarios.  If
you're an assembler who is assembling components which happen to be
implemented 

Re: Finding the .componentType file

[Pete Robbins]

In Tuscany C++ the language implementation (C++, Python, etc) defines the
location of the .componentType file. For C++ we use the header=".." and
path=" .." attributes of implementation.cpp:

in fred.composite:



The implementation library is abc/xyz/Calcualtor.dll (or
abc/xyz/libCalculator.so for linux). The compnentType file is named from the
implentation interface (header) so in the above will be located at
abc/xyz/CalculatorImpl.componentType.

The paths are relative to the composite root (location of the .composite
file).

Cheers,


On 20/06/07, Mike Edwards <[EMAIL PROTECTED]> wrote:


Ant,

In general, I would agree that there should be a simple and obvious
relationship between implementation artifact and componentType file.

However, consider the case of languages like C or C++ where multiple
implementations are bundled into a DLL.  The runtime file is the DLL,
but there must be multiple componentType files.  So now, what is the
relationship between them

In these more complex cases, the implementation type defines the
relationship.

Yours,  Mike.

ant elder wrote:
> On 6/18/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
>
> 
>
>> How does that fit with the spec saying - ""A component type file has
the
>> > same name as the implementation file but has the extension
>> > ".componentType""
>> > ? I'm looking for a way to make the default case easy, it doesn't
have
>> to
>> > deal with every edge case.
>> 
>>
>> Unfortunately, this is no edge case.  There is no reason to expect the
>> component name to be even close to the implementation name.
>
>
>
> AFAICT, unless there's an attribute in the SCDL to explicitly point to
it
> there has to be a way to find these things programatically, and for
humans
> to understand whats going on in a contribution it must be reasonably
> obvious
> which .componentType side file is associated with which implementation
just
> by eyeballing the files. Otherwise, what does this line in the spec
mean:
>
> 'A component type file has the same name as the implementation file but
has
> the extension ".componentType"'
>
>   ...ant
>

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





--
Pete

How to get an instance of the read composite file ?

[sam tam]

Hello All,

In the implementation script module, there should be some place where the
[.composite] file information are read .

Can any one mention where this is read ?

Is it in the AbstractSCATestCase ?


Am now trying implementation bpel (ie integrating Apaceh ODE-bpel and
Tuscany-SCA)

I ll giving a few attributes in .composite file for ode runtime to start and
run, so how to read this attributes from .composite file?
If the ImplementationActivator does the job of reading the composite file
then through which instance i could get these attributes which specify in
the composite file?

In the prev M2 release, we had ImplementationLoader where in we had
XMLStreamReader .
Through which we can access the attricutes we give in the scdl.
Like ( reader.getAttributeValue(..) )

So now how can i do this ?


Thanks in advance ,

Sam..

Re: 0.91 release?

[Venkata Krishnan]

Hi,

I have cut a branch for the 0.91 release and have changed over the artifact
versions to 0.91-incubating-SNAPSHOT.  I am now trying to build it and here
are some problems that I have observed.

- The SDO dependency seems to be on the current
1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl
and sdo-lib that are being used
as dependencies in the SDO Databinding.  This does not match with the last
sdo release of 1.0-incubating-beta1.  So how are we going to go forward with
the SDO dependency for this SCA release?  Are we going to roll back things
to beta1 (which is not something I'd be happy about) or should we consider
using a snapshot from the trunk (which is also something that we have
decided not to do)  or is there another alternative to this?  Could people
please help in this.

Thanks

- Venkat

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


I would prefer not to delay SCA 0.91 for the DAS support.  Unless we
are confident that the DAS release can be created quickly, I think
it's better to go ahead with SCA 0.91 as planned and defer the DAS
support.

An alternative packaging approach (which I am starting to think would
be even better) is to reverse the dependency and have the DAS release
ship the pieces identified by Luciano below.  It should be possible
(even desirable) for Tuscany SCA extensions that support another
technology to ship as part of a release of that technology rather than
always making them part of a Tuscany SCA release.

   Simon

Venkata Krishnan wrote:

> Hi Luciano,
>
> This is a surprise :)... I was planning on taking the 0.91 brn tomorrow
and
> imediately start getting out RCs to vote on, but I can't do that if it
> needs
> to include the DAS beta1 release???.
>
> What do people think?
>
> - Venkat
>
> On 6/18/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
>>
>> Sorry, I'm having some restricted internet access as I'm traveling
>> since last week... that's probably why we haven't created a DAS
>> release candidate yet... but the community and I think that we are
>> ready to have one.
>>
>> Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the
>> following items:
>>- implementation.das
>>- implementation.data
>>- some samples (maybe including the samples we didn't ship in 0.9)
>>
>> On 6/18/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>> > What will be the relationship between SCA 0.91 and DAS?  I have seen
>> > some discussions on the list about a DAS release.  Will SCA 0.91 have
>> > this DAS release as a dependency?
>> >
>> >Simon
>> >
>> > Luciano Resende wrote:
>> >
>> > > I have updated the wiki [1] page with things that I'm working on,
and
>> > > would like to have in 0.91 .
>> > >
>> > > As for the implementation.das question regarding it's canned derby
>> db,
>> > > we recently created a db utility to create and populate the
database,
>> > > and I have plans to integrate with it.
>> > >
>> > > [1]
>> > >
>>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
>>
>> > >
>> > >
>> > > On 6/16/07, ant elder <[EMAIL PROTECTED]> wrote:
>> > >
>> > >> Wow 571 license problems! after being clean for 0.90 just a month
>> ago.
>> > >>
>> > >> One question this brings up is what is actually intended to be
>> > >> included in
>> > >> 0.91? There's been quite a few new extensions and demo's etc added
>> > >> recently
>> > >> but no one has said they want those included in 0.91. Should they
be
>> by
>> > >> default or should we just include things that are mentioned on the
>> > >> release
>> > >> wiki page? If so anyone else care to help clean things up, add
>> missing
>> > >> license headers, check the distribution works and includes
>> > >> dependencies etc?
>> > >> The implementation.das is including an entire database in the
>> src, is
>> > >> there
>> > >> any way that could be generated by the tests?
>> > >>
>> > >>...ant
>> > >>
>> > >> On 6/16/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>> > >> >
>> > >> > Thanks Ant.  So could we all please use this wiki page to put
down
>> > >> things
>> > >> > that are going to be increments over 0.90.
>> > >> >
>> > >> > Also I run the RAT on the trunk - just java/sca and here is the
>> > >> report.  I
>> > >> > intend to go and fix the missing headers just ahead of cutting
the
>> > >> branch.
>> > >> > Before that if anybody would like to jump in and help with this,
>> > >> please feel
>> > >> > free do so.
>> > >> >
>> > >> >
>> > >> http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt<
>> http://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt>
>> > >>
>> > >> >
>> > >> > Thanks
>> > >> >
>> > >> > - Venkat
>> > >> >
>> > >> > On 6/14/07, ant elder <[EMAIL PROTECTED]> wrote:
>> > >> > >
>> > >> > > Taking a branch around the 20th sounds ok to me.
>> > >> > >
>> > >> > > The high level things I'm focusing on for the 0.91 release
are:
>> > >> > >
>> > >> > > - Simplification of using script components (working without
>> > >> > > .componentTyp

Re: Finding the .componentType file

[Mike Edwards]

Ant,

In general, I would agree that there should be a simple and obvious 
relationship between implementation artifact and componentType file.


However, consider the case of languages like C or C++ where multiple 
implementations are bundled into a DLL.  The runtime file is the DLL, 
but there must be multiple componentType files.  So now, what is the 
relationship between them


In these more complex cases, the implementation type defines the 
relationship.


Yours,  Mike.

ant elder wrote:

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




How does that fit with the spec saying - ""A component type file has the
> same name as the implementation file but has the extension
> ".componentType""
> ? I'm looking for a way to make the default case easy, it doesn't have
to
> deal with every edge case.


Unfortunately, this is no edge case.  There is no reason to expect the
component name to be even close to the implementation name.




AFAICT, unless there's an attribute in the SCDL to explicitly point to it
there has to be a way to find these things programatically, and for humans
to understand whats going on in a contribution it must be reasonably 
obvious

which .componentType side file is associated with which implementation just
by eyeballing the files. Otherwise, what does this line in the spec mean:

'A component type file has the same name as the implementation file but has
the extension ".componentType"'

  ...ant



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

[jira] Commented: (TUSCANY-1363) Initial implementation of OSGi Implementation type for Tuscany

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-1363:


Applied. Thanks for the code!

> Initial implementation of OSGi Implementation type for Tuscany
> --
>
> Key: TUSCANY-1363
> URL: https://issues.apache.org/jira/browse/TUSCANY-1363
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA OSGi Integration
>Reporter: Rajini Sivaram
>Assignee: ant elder
> Attachments: implementation-osgi-patch.txt, osgi-supplychain.zip
>
>
> This is the initial code drop for an OSGi implementation type for Tuscany.
> The attachments include a patch for modules/implementation-osgi and a 
> supplychain sample which uses a combination of Java and OSGi components. 
> The code has been tested against Apache Felix, Equinox and Knopflerfish OSGi 
> runtimes. The maven files for building and testing use Apache Felix snapshots 
> since the Equinox runtime available in a maven repository used by Tuscany is 
> very old.
> Since there was an OSGi binding implementation under Tuscany earlier, I am 
> assuming that there are no issues with licenses, but for reference, OSGi 
> specification is available at 
> http://www2.osgi.org/Main/OSGiSpecificationLicense, Apache Felix OSGI runtime 
> uses Apache License, Equinox OSGi runtime is available under Eclipse EPL 
> http://www.eclipse.org/legal/epl/notice.html and Knopflerfish OSGi runtime is 
> available under a BSD style license http://www.knopflerfish.org/license.html.

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


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

[jira] Assigned: (TUSCANY-1363) Initial implementation of OSGi Implementation type for Tuscany

[ant elder (JIRA)]

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

ant elder reassigned TUSCANY-1363:
--

Assignee: ant elder

> Initial implementation of OSGi Implementation type for Tuscany
> --
>
> Key: TUSCANY-1363
> URL: https://issues.apache.org/jira/browse/TUSCANY-1363
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA OSGi Integration
>Reporter: Rajini Sivaram
>Assignee: ant elder
> Attachments: implementation-osgi-patch.txt, osgi-supplychain.zip
>
>
> This is the initial code drop for an OSGi implementation type for Tuscany.
> The attachments include a patch for modules/implementation-osgi and a 
> supplychain sample which uses a combination of Java and OSGi components. 
> The code has been tested against Apache Felix, Equinox and Knopflerfish OSGi 
> runtimes. The maven files for building and testing use Apache Felix snapshots 
> since the Equinox runtime available in a maven repository used by Tuscany is 
> very old.
> Since there was an OSGi binding implementation under Tuscany earlier, I am 
> assuming that there are no issues with licenses, but for reference, OSGi 
> specification is available at 
> http://www2.osgi.org/Main/OSGiSpecificationLicense, Apache Felix OSGI runtime 
> uses Apache License, Equinox OSGi runtime is available under Eclipse EPL 
> http://www.eclipse.org/legal/epl/notice.html and Knopflerfish OSGi runtime is 
> available under a BSD style license http://www.knopflerfish.org/license.html.

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


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

[jira] Updated: (TUSCANY-1363) Initial implementation of OSGi Implementation type for Tuscany

[Rajini Sivaram (JIRA)]

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

Rajini Sivaram updated TUSCANY-1363:


Attachment: osgi-supplychain.zip
implementation-osgi-patch.txt


implementation-osgi-patch.txt contains a patch for modules/implementation-osgi.

osgi-supplychain.zip contains a version of the supplychain sample which uses a 
combination of OSGi and POJO implementation types for the components.

> Initial implementation of OSGi Implementation type for Tuscany
> --
>
> Key: TUSCANY-1363
> URL: https://issues.apache.org/jira/browse/TUSCANY-1363
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA OSGi Integration
>Reporter: Rajini Sivaram
> Attachments: implementation-osgi-patch.txt, osgi-supplychain.zip
>
>
> This is the initial code drop for an OSGi implementation type for Tuscany.
> The attachments include a patch for modules/implementation-osgi and a 
> supplychain sample which uses a combination of Java and OSGi components. 
> The code has been tested against Apache Felix, Equinox and Knopflerfish OSGi 
> runtimes. The maven files for building and testing use Apache Felix snapshots 
> since the Equinox runtime available in a maven repository used by Tuscany is 
> very old.
> Since there was an OSGi binding implementation under Tuscany earlier, I am 
> assuming that there are no issues with licenses, but for reference, OSGi 
> specification is available at 
> http://www2.osgi.org/Main/OSGiSpecificationLicense, Apache Felix OSGI runtime 
> uses Apache License, Equinox OSGi runtime is available under Eclipse EPL 
> http://www.eclipse.org/legal/epl/notice.html and Knopflerfish OSGi runtime is 
> available under a BSD style license http://www.knopflerfish.org/license.html.

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


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

[jira] Created: (TUSCANY-1363) Initial implementation of OSGi Implementation type for Tuscany

[Rajini Sivaram (JIRA)]

Initial implementation of OSGi Implementation type for Tuscany
--

 Key: TUSCANY-1363
 URL: https://issues.apache.org/jira/browse/TUSCANY-1363
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA OSGi Integration
Reporter: Rajini Sivaram


This is the initial code drop for an OSGi implementation type for Tuscany.

The attachments include a patch for modules/implementation-osgi and a 
supplychain sample which uses a combination of Java and OSGi components. 

The code has been tested against Apache Felix, Equinox and Knopflerfish OSGi 
runtimes. The maven files for building and testing use Apache Felix snapshots 
since the Equinox runtime available in a maven repository used by Tuscany is 
very old.

Since there was an OSGi binding implementation under Tuscany earlier, I am 
assuming that there are no issues with licenses, but for reference, OSGi 
specification is available at 
http://www2.osgi.org/Main/OSGiSpecificationLicense, Apache Felix OSGI runtime 
uses Apache License, Equinox OSGi runtime is available under Eclipse EPL 
http://www.eclipse.org/legal/epl/notice.html and Knopflerfish OSGi runtime is 
available under a BSD style license http://www.knopflerfish.org/license.html.




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


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

[jira] Created: (TUSCANY-1362) Incorrect operation of code that checks whether schema is loaded before going out on the net to retrieve it.

[Simon Laws (JIRA)]

Incorrect operation of code that checks whether schema is loaded before going 
out on the net to retrieve it. 
-

 Key: TUSCANY-1362
 URL: https://issues.apache.org/jira/browse/TUSCANY-1362
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Java-SDO-M2
 Environment: All
Reporter: Simon Laws
Priority: Minor


There is code in SDOSchemeSAX2Parse.cpp that decideds whether to go ahead and 
parse the referenced file

SDOSchemaSAX2Parser* ParserErrorSetter::parseIfNot(const void* 
location, bool loadImportNamespace, const void* base)
{
xmlChar*const absoluteUri = xmlBuildURI((xmlChar*)location, 
(xmlChar*)base);
if (! absoluteUri)
SDO_THROW_EXCEPTION("parseIfNot", SDOFileNotFoundException, 
(char*)location);
LocationParserMap::iterator iter = 
parsedLocations.find(absoluteUri);
if (parsedLocations.end() == iter)
{
SDOSchemaSAX2Parser*const schemaParser = new 
SDOSchemaSAX2Parser(*new SchemaInfo(), this, loadImportNamespace);
try {
if (0 == 
schemaParser->parse((char*)absoluteUri))
 ***   return parsedLocations[ absoluteUri ] = schemaParser;
}
catch (SDORuntimeException e)
{}
schemaParser->free(absoluteUri);
return 0;
}
xmlFree(absoluteUri);
return iter->second;
}

Note the line marked ***. This adds the current URL being parse to the 
parsedLocations list for future reference. The issue is that, in the case where 
no schemaLocation is provided and loadImportNamespace is true, this will not 
work if the schema was orginally loaded from the file system, for example

/mydir/schema1.xsd  - parsedLocation = "file:///mydir/schema1.xsd
targetNamespace="http://schemas.xmlsoap.org/wsdl/";
/mydir/schema2.xsd 
  http://schemas.xmlsoap.org/wsdl/"; /> - doesn't hit 
parsedLocation as it not the same URL as was originally used to load schema1

A solution is to store both the provided location and the target namsepace in 
parsedLocation

-- 
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: Which jar files are really needed for the Calculator Sample?

[Simon Nash]

I agree that we need something better for 1.0.  Hard-wiring a
hand-built list of files into a build script won't be good
enough to support a variety of user applications that all need
slightly different combinations.

  Simon

ant elder wrote:


On 6/20/07, Matthew Peters <[EMAIL PROTECTED]> wrote:



Newbie question and first posting - I hope this gets formatted OK, right
name put on etc.. Also, I have searched the mail archive but cannot find
the answer - please excuse me if this has been asked before..

The calculator sample includes a tuscany-sca-manifest.jar that pulls in
literally dozens of other jars. I want to make a war file that contains
the sample and really only want to include the minimal set of jar files.
So, are they really all needed, and if not, how can I work out exactly
which ones are?




The current distribution and the tuscany-sca-manifest.jar is a point in 
time

thing to make things easy to use for now, there's probably better ways for
1.0. You can do what you want now though, in fact, take a look at the
calculator-webapp sample:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp/ 



  ...ant





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

Re: [jira] Updated: (TUSCANY-1356) Clean up binding-echo and implementation-crud samples

[Simon Nash]

Ant,
Thee is no plan to move any code from the other samples to itests.
However, I would like to add an itest for each of the other samples
that calls the sample client code used by "ant run", to ensure that
this client code runs correctly without exceptions.

I decided not to delay my patch for TUSCANY-1356 by adding this code
to it, since the main point was to clean up the sample code for these
two samples.  I'm happy to create a separate JIRA and attach a patch
there to create itests for the other sample clients.

  Simon

ant elder wrote:


You know, now that we get to see this I'm not sure if this isn't making
things even more confusing than before, what do others think? Is the plan
now to move all the sample testcases from the samples to itests, or
otherwise why are these two samples special?

  ...ant


On 6/20/07, Simon Nash (JIRA)  wrote:




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



Simon Nash updated TUSCANY-1356:


Attachment: jira1356.zip

zip file containing the added files

> Clean up binding-echo and implementation-crud samples
> -
>
> Key: TUSCANY-1356
> URL: https://issues.apache.org/jira/browse/TUSCANY-1356
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-0.91
> Environment: Windows XP
>Reporter: Simon Nash
>Assignee: Simon Nash
> Fix For: Java-SCA-0.91
>
> Attachments: jira1356.diff, jira1356.svnst, jira1356.zip
>
>
> There is duplicate and confusing code in binding-echo and
binding-echo-extension, and also in implementation-crud and
implementation-crud-extension.
> See 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18926.htmlfor 
more details of the problem.


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








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

Re: Which jar files are really needed for the Calculator Sample?

[ant elder]

On 6/20/07, Matthew Peters <[EMAIL PROTECTED]> wrote:


Newbie question and first posting - I hope this gets formatted OK, right
name put on etc.. Also, I have searched the mail archive but cannot find
the answer - please excuse me if this has been asked before..

The calculator sample includes a tuscany-sca-manifest.jar that pulls in
literally dozens of other jars. I want to make a war file that contains
the sample and really only want to include the minimal set of jar files.
So, are they really all needed, and if not, how can I work out exactly
which ones are?



The current distribution and the tuscany-sca-manifest.jar is a point in time
thing to make things easy to use for now, there's probably better ways for
1.0. You can do what you want now though, in fact, take a look at the
calculator-webapp sample:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp/

  ...ant

Which jar files are really needed for the Calculator Sample?

[Matthew Peters]

Newbie question and first posting - I hope this gets formatted OK, right 
name put on etc.. Also, I have searched the mail archive but cannot find 
the answer - please excuse me if this has been asked before..

The calculator sample includes a tuscany-sca-manifest.jar that pulls in 
literally dozens of other jars. I want to make a war file that contains 
the sample and really only want to include the minimal set of jar files. 
So, are they really all needed, and if not, how can I work out exactly 
which ones are?

Matthew Peters






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [jira] Updated: (TUSCANY-1356) Clean up binding-echo and implementation-crud samples

[ant elder]

You know, now that we get to see this I'm not sure if this isn't making
things even more confusing than before, what do others think? Is the plan
now to move all the sample testcases from the samples to itests, or
otherwise why are these two samples special?

  ...ant


On 6/20/07, Simon Nash (JIRA)  wrote:



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

Simon Nash updated TUSCANY-1356:


Attachment: jira1356.zip

zip file containing the added files

> Clean up binding-echo and implementation-crud samples
> -
>
> Key: TUSCANY-1356
> URL: https://issues.apache.org/jira/browse/TUSCANY-1356
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-0.91
> Environment: Windows XP
>Reporter: Simon Nash
>Assignee: Simon Nash
> Fix For: Java-SCA-0.91
>
> Attachments: jira1356.diff, jira1356.svnst, jira1356.zip
>
>
> There is duplicate and confusing code in binding-echo and
binding-echo-extension, and also in implementation-crud and
implementation-crud-extension.
> See http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18926.htmlfor 
more details of the problem.

--
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] Closed: (TUSCANY-1357) The Result returned by SDOUtil.getTypes includes DocumentRoot Type

[lizhantao (JIRA)]

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

lizhantao closed TUSCANY-1357.
--


> The Result returned by SDOUtil.getTypes includes DocumentRoot Type
> --
>
> Key: TUSCANY-1357
> URL: https://issues.apache.org/jira/browse/TUSCANY-1357
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: tuscany-sdo-impl-1.0-incubating-beta1.jar
>Reporter: lizhantao
> Fix For: Java-SDO-1.0
>
>
> It's ugly

-- 
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: Supporting callbacks across Web Services

[scabooz]

Simon,

I think it great that you're trying to tackle this problem and it seems like
You're on the right track.  My only suggestion (at this point) is to first
get the runtime back to where it was before .90 from the perspective
of the SCA app, if that's possible.

Only one comment embedded below.

Dave


- Original Message - 
From: "Matthew Sykes" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, June 19, 2007 8:44 AM
Subject: Re: Supporting callbacks across Web Services


I did notice that the code that is responsible for creating the callback 
wires / invocation chains out of createWires on the service side is 
currently commented out in the CompositeActivatorImpl.  When that code is 
uncommented I found that the callback proxy was injected as there were 
callback wires associated with the service.  Even when the proxy is 
injected, the rest of the issues you've raised still come into play.


I'm interested in the progress you make here as I'm also trying to figure 
out how to make callbacks work when the callback target is not local to 
the composite containing the service.  Right now it seems that callbacks 
only work when the reference and service are associated with components in 
the same composite as the callback target.  I think some of this is due to 
how Tuscany treats the concept of the default binding and extends it to 
hold a direct reference to the target component associated with the 
binding.


In particular, within the CompositeActivatorImpl, the createWires method 
that deals with the reference side will create the callback wires with 
endpoint references that hold pointers to the runtime components on both 
sides of the wire.  With the target service in hand, you can add the 
callback wire to the service side as is done at the end of createWires. 
Since the wire deals with RuntimeComonent instances on the source and 
target, everything works fine with an implementation interceptor.


When the implementation interceptors are not added and only the binding 
interceptors exist on the wire, I'm not sure how to connect up the two.



Simon Nash wrote:

In my investigations into TUSCANY-1341, I'have fixed a few minor
blocking defects (see my updates to the JIRA) and I'm now getting
to the heart of the problem.  I think the right approach is to do
this in a similar way to callbacks over direct local wires, with
the forward call proceeding as normal and a callback proxy being
injected on the service side to make a reverse call back to the
client instance using the same Web services connection thar was
used for the forward call from client to server.  This isn't the
approach used by the current code.

So far I have got this path working as far as the attempt to call
back using the service's proxy.  The code to inject this proxy
isn't working properly yet.

I'm not yet sure how callbacks should be mapped to the protocol
used by the Web services connection.  There need to be standard
mappings for this, or SCA callbacks won't interoperate with
non-SCA Web service endpoints.


The SCA specs intentionally avoided starying into WS-* spec space.
In order to get to interoperability, the industry would need a
WS-Callback spec.  You'll find the same thing to be true of
conversations (when you get there in the scope of callbacks).  I know
this doesn't help you implement it, but I thought the background
would be helpful.


 I'm hoping Axis2 provides a way
to call back from a server to a client over an already established
connection, but I haven't looked into this in detail yet.

I'm hoping my fix will support callback from both two-way methods
and one-way methods.  (The spec seems to imply that both of these
are valid.)  The two-way case seems harder because the callback
invocation will be sent back on the wire before the forward
invocation has returned its response message.


This will be hard when using an HTTP transport.  Getting back
to simply supporting oneways will be a challenge.


 If it's too hard
to do this, I may back off and only support callbacks from
one-way methods for now.  This seems to present challenges as well,
because I'm not sure whether the connection is guaranteed to
remain active after the one-way call has been made and the server
method is running.

Before I go further down this path, I would welcome any comments
on the above issues and whether my basic approach is sound.

  Simon


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




--
Matthew Sykes

-
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: Policy Framework Impl. in Tuscany

[scabooz]

Venkat,
comments embedded...

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

To: 
Sent: Monday, June 18, 2007 10:33 AM
Subject: Re: Policy Framework Impl. in Tuscany



Venkata Krishnan wrote:

Hi,

I am keen on adding further to the Policy support thats in Tuscany today. 
I
recently run thro the Policy Framework specs and was looking into Tuscany 
on

how far we had gone on this.  Here's my understanding of all that.  I
request people's perspective on my understanding before I go ahead and
implement things.

1.  Policy intents and PolicySets are things that can be defined at the
domain level.  I propose we have Policy Registry or Repository that hosts
the set of all intents and policy sets that pertain to a domain.


+1 but I think we could start with something simpler than a repository, 
simply a model for definitions.xml, and a reader for this file.




In addition, you could consider PolicySets packaged with a contribution,
such that it's not possible (a temporary restriction) to reference a
policySet from another contribution.  Start simple.



2. There can be a PolicyRegistryService that can provide interfaces to 
add,

retrieve and remove intents and policies to the Policy Registry /
Repository.


+1



3. The set of intents and policy sets for a domain could be defined in 
the
definitions.xml file which could be picked up by the 
ContributionsProcessor
(see line 2490 of Assembly Model Spec).  Infact there is more - such as 
the
intents that are supported by binding and implementation types in the 
domain
and so on.  We could have a processor for the sca definitions that will 
read
among other artifacts the policy intents and policy sets and add them to 
the
registry.  The model objects to represent policy intents and policy sets 
and

the factory to create them are already in place under the policy module.



Policy administration is independent of SCA contributions. How about a new 
policy-xml module for the code that will read definitions.xml, independent 
of the ContributionProcessor?




Right. A long term solution would include a seperation of policy from
contributions.  The "policy registry" could even be separate from
the Domain as an entity, but a Domain will have a reference to a
policy registry.


4. SCA artifacts will have intents and policy sets attached to them.
Presently the artifact processors create the Intents and PolicySet 
objects.

I propose that the artifact processor that read these SCA Artifacts will
just about read the QNames and resolve them in the resolution phase with 
the
help of the PolicyRegistryService.  This way we can also check if the 
intent
or policy set specified for an artifact is really applicable to the 
artifact

or not.



Intents need to be resolved to point to the intents defined in 
definitions.xml in ArtifactProcessor.resolve(). I'd suggest to adopt to 
the same approach as for all other objects that need to be resolved:

1. read creates an Intent / PolicySet with unresolved = true
2. resolve replaces it with the resolved Intent / PolicySet



I didn't quite follow this.  Is this different from canonicalizing
intent and policySet attachments as described in the lengthy algorithm in
section 1.4.10 of the spec?

5. Loading of PolicySet could get a bit deeper since there is 
extensibility

that is allowed on the policy language that could be used.  But I guess
WS-Policy will need to be supported for by Tuscany as that is view to be 
a

common thing that could be used

So thats a summary the loading part.

In the building phase there are algorithms that the Policy Framework 
Specs

has specified to validate the wiring between components in the context of
policies (including each end of the wire could inherit from ancestor
artifacts and what is the binding or implementation type being used and 
what

that supports inherently).

Finally during runtime we have to make sure that the policy statements 
are

handed out to the appropriate QoS infrastructures i.e Security or
Transaction support modules so that they may be enforced.  I am a bit
unclear on the options related to this at the present moment.

Before I get to a discussion on the wiring and runtime aspects related to
policy I wish to know if my thoughts are in the right direction this far.


Yes, this sounds good to me. I'd suggest to start small with:
- reading of definitions.xml
- completing the Policy Intent and PolicySet models
- starting with a a real Policy implementation, like Security, to help 
drive the design and implementation with a concrete use case.



+1



Thanks

- Venkat


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

[jira] Resolved: (TUSCANY-1338) Add support for simple distributed runtimes to trunk

[Simon Laws (JIRA)]

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

Simon Laws resolved TUSCANY-1338.
-

Resolution: Fixed

Basic support is implemented but 

1/ modules/distributed needs further integration with the other SCA modules
2/ the topology modules are not used yet. The topology is hard coded in the 
sample

> Add support for simple distributed runtimes to trunk
> 
>
> Key: TUSCANY-1338
> URL: https://issues.apache.org/jira/browse/TUSCANY-1338
> Project: Tuscany
>  Issue Type: New Feature
>Affects Versions: Java-SCA-Next
>Reporter: Simon Laws
>
> Move the sample distributed runtime support from my sandbox into truck and 
> reorganize

-- 
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-1338) Add support for simple distributed runtimes to trunk

[Simon Laws (JIRA)]

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

Simon Laws commented on TUSCANY-1338:
-

Basci changes integrated as of 20/06/07 included in the modules

modules/topology
modules/topology-xml
modules/binding-sca
modules/distributed
samples/calculator-distributed

The topology model is not used by the distributed calculator sample yet. Here 
the topology is hard coded. 


> Add support for simple distributed runtimes to trunk
> 
>
> Key: TUSCANY-1338
> URL: https://issues.apache.org/jira/browse/TUSCANY-1338
> Project: Tuscany
>  Issue Type: New Feature
>Affects Versions: Java-SCA-Next
>Reporter: Simon Laws
>
> Move the sample distributed runtime support from my sandbox into truck and 
> reorganize

-- 
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-1358) Exception in thread "main" java.lang.IllegalArgumentException: Cannot generate XSD since SDO Type 'item' was orginally generated from XSD. Use original XSD

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson commented on TUSCANY-1358:
-

I'm in the middle of composing my response to this,  but I should have added to 
the above comment to say that you can join the mailing lists by looking at 
http://incubator.apache.org/tuscany/mailing-lists.html

> Exception in thread "main" java.lang.IllegalArgumentException: Cannot 
> generate XSD since SDO Type 'item' was orginally generated from XSD.  Use 
> original XSD
> 
>
> Key: TUSCANY-1358
> URL: https://issues.apache.org/jira/browse/TUSCANY-1358
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
>Reporter: lizhantao
>Priority: Blocker
> Fix For: Java-SDO-1.0
>
>
> package com.hollycrm.sdo;
> import java.io.FileWriter;
> import java.io.Writer;
> import java.util.Iterator;
> import java.util.List;
> import org.apache.tuscany.samples.sdo.SdoSampleConstants;
> import org.apache.tuscany.sdo.util.SDOUtil;
> import commonj.sdo.Type;
> import commonj.sdo.helper.HelperContext;
> import commonj.sdo.helper.TypeHelper;
> import commonj.sdo.helper.XMLHelper;
> import commonj.sdo.helper.XSDHelper;
> public class POXSDTest {
>   public static void main(String[]argv)throws Exception{
>   HelperContext hc = SDOUtil.createHelperContext(true);
>   
>   
> hc.getXSDHelper().define(ClassLoader.getSystemResourceAsStream("po.xsd"), 
> null);   
>   List allTypes = SDOUtil.getTypes(hc.getTypeHelper(), 
> "http://www.example.com/PO";);
>   removeDocumentRootType(allTypes);
>   String xsd = hc.getXSDHelper().generate(allTypes);
>   Writer w = new FileWriter("po2.xsd");
>   w.write(xsd);
>   }
>   /**
>* eliminate a bug
>* @param allTypes
>*/
>   private static void removeDocumentRootType(List allTypes) {
>   for (Iterator iter = allTypes.iterator(); iter.hasNext();) {
>   Type t = (Type) iter.next();
>   if ("DocumentRoot".equals(t.getName())) {
>   iter.remove();
>   continue;
>   }
>   
>   }
>   }
> }
> console out---
> Exception in thread "main" java.lang.IllegalArgumentException: Cannot 
> generate XSD since SDO Type 'item' was orginally generated from XSD.  Use 
> original XSD
>   at 
> org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:291)
>   at 
> org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:235)
>   at com.hollycrm.sdo.POXSDTest.main(POXSDTest.java:24)

-- 
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: Finding the .componentType file

[ant elder]

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




How does that fit with the spec saying - ""A component type file has the
> same name as the implementation file but has the extension
> ".componentType""
> ? I'm looking for a way to make the default case easy, it doesn't have
to
> deal with every edge case.


Unfortunately, this is no edge case.  There is no reason to expect the
component name to be even close to the implementation name.



AFAICT, unless there's an attribute in the SCDL to explicitly point to it
there has to be a way to find these things programatically, and for humans
to understand whats going on in a contribution it must be reasonably obvious
which .componentType side file is associated with which implementation just
by eyeballing the files. Otherwise, what does this line in the spec mean:

'A component type file has the same name as the implementation file but has
the extension ".componentType"'

  ...ant

[jira] Commented: (TUSCANY-1358) Exception in thread "main" java.lang.IllegalArgumentException: Cannot generate XSD since SDO Type 'item' was orginally generated from XSD. Use original XSD

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson commented on TUSCANY-1358:
-

Hi,  I'm going to copy this issue to the tusany-user mailing list and respond 
with a suggestion there.  I don't believe there is a bug here. but I'll leave 
this it open for a little while until the discussion has panned out a bit more. 
 I will cc you directly with my response,  but please could you subscribe to 
the tuscany user mailing list (and tuscany-dev if you wish) in order to raise 
these sorts of issues until such time that it is clear that there is an issue 
for Tuscany to address. 

> Exception in thread "main" java.lang.IllegalArgumentException: Cannot 
> generate XSD since SDO Type 'item' was orginally generated from XSD.  Use 
> original XSD
> 
>
> Key: TUSCANY-1358
> URL: https://issues.apache.org/jira/browse/TUSCANY-1358
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
>Reporter: lizhantao
>Priority: Blocker
> Fix For: Java-SDO-1.0
>
>
> package com.hollycrm.sdo;
> import java.io.FileWriter;
> import java.io.Writer;
> import java.util.Iterator;
> import java.util.List;
> import org.apache.tuscany.samples.sdo.SdoSampleConstants;
> import org.apache.tuscany.sdo.util.SDOUtil;
> import commonj.sdo.Type;
> import commonj.sdo.helper.HelperContext;
> import commonj.sdo.helper.TypeHelper;
> import commonj.sdo.helper.XMLHelper;
> import commonj.sdo.helper.XSDHelper;
> public class POXSDTest {
>   public static void main(String[]argv)throws Exception{
>   HelperContext hc = SDOUtil.createHelperContext(true);
>   
>   
> hc.getXSDHelper().define(ClassLoader.getSystemResourceAsStream("po.xsd"), 
> null);   
>   List allTypes = SDOUtil.getTypes(hc.getTypeHelper(), 
> "http://www.example.com/PO";);
>   removeDocumentRootType(allTypes);
>   String xsd = hc.getXSDHelper().generate(allTypes);
>   Writer w = new FileWriter("po2.xsd");
>   w.write(xsd);
>   }
>   /**
>* eliminate a bug
>* @param allTypes
>*/
>   private static void removeDocumentRootType(List allTypes) {
>   for (Iterator iter = allTypes.iterator(); iter.hasNext();) {
>   Type t = (Type) iter.next();
>   if ("DocumentRoot".equals(t.getName())) {
>   iter.remove();
>   continue;
>   }
>   
>   }
>   }
> }
> console out---
> Exception in thread "main" java.lang.IllegalArgumentException: Cannot 
> generate XSD since SDO Type 'item' was orginally generated from XSD.  Use 
> original XSD
>   at 
> org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:291)
>   at 
> org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:235)
>   at com.hollycrm.sdo.POXSDTest.main(POXSDTest.java:24)

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


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

[jira] Created: (TUSCANY-1361) New Util: Validation

[Christian Landbo Frederiksen (JIRA)]

New Util: Validation


 Key: TUSCANY-1361
 URL: https://issues.apache.org/jira/browse/TUSCANY-1361
 Project: Tuscany
  Issue Type: Wish
  Components: Java SDO Tools
Reporter: Christian Landbo Frederiksen
Priority: Minor


Has been discussed here: http://www.mail-archive.com/[EMAIL 
PROTECTED]/msg01095.html

I do validation using EMF:

Diagnostic diagnostic = Diagnostician.INSTANCE.validate((EObject)dataObject);
  if (diagnostic.getSeverity() == Diagnostic.ERROR) { 

Kelvin points out that this is not a full schema validator but that it might be 
added as a utility with some comments on the restrictions.

I'll look into making my code more general in terms of using this as a utility, 
and I'll put something here.

Any ideas as to how this could be implemented best as a simple utitlity are 
velcome. More specifically - how do we report the validation errors. I use a 
custom ValidationError class.

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


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

[jira] Created: (TUSCANY-1360) New SDOUtil: Getting the enumeration facet

[Christian Landbo Frederiksen (JIRA)]

New SDOUtil: Getting the enumeration facet
--

 Key: TUSCANY-1360
 URL: https://issues.apache.org/jira/browse/TUSCANY-1360
 Project: Tuscany
  Issue Type: Wish
  Components: Java SDO Tools
Reporter: Christian Landbo Frederiksen
Priority: Minor


This has been discussed in the lists: 

http://www.mail-archive.com/[EMAIL PROTECTED]/msg01095.html

I do this:

  public static List getEnumerationFacet(Type type) {

   return
 ExtendedMetaData.INSTANCE.getEnumerationFacet((EDataType)type);
   }

Kelvin suggested another way

I think you should be able to do

type.getInstanceProperties() and find the Property called "enumeration".
Then you can get the enumerations using that Property.
(see MetaDataInstancePropertiesTestCase [2])

Having this encapsuled by the SDOUtil would be cool (but maybe overkill - you 
decide)


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


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

[jira] Created: (TUSCANY-1359) New SDOUtil: Upper and lower bound on properties where 'isMany' is true

[Christian Landbo Frederiksen (JIRA)]

New SDOUtil: Upper and lower bound on properties where 'isMany' is true
---

 Key: TUSCANY-1359
 URL: https://issues.apache.org/jira/browse/TUSCANY-1359
 Project: Tuscany
  Issue Type: Wish
  Components: Java SDO Tools
Reporter: Christian Landbo Frederiksen
Priority: Minor


Can be implemented like this:

 public static int getUpperBound(Property property) {

return ((EStructuralFeature) property).getUpperBound();
 }

   public static int getLowerBound(Property property) {

   return ((EStructuralFeature) property).getLowerBound();
   }



-- 
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-1358) Exception in thread "main" java.lang.IllegalArgumentException: Cannot generate XSD since SDO Type 'item' was orginally generated from XSD. Use original XSD

[lizhantao (JIRA)]

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

lizhantao commented on TUSCANY-1358:


If I'm wrong,How should I do?

> Exception in thread "main" java.lang.IllegalArgumentException: Cannot 
> generate XSD since SDO Type 'item' was orginally generated from XSD.  Use 
> original XSD
> 
>
> Key: TUSCANY-1358
> URL: https://issues.apache.org/jira/browse/TUSCANY-1358
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
>Reporter: lizhantao
>Priority: Blocker
> Fix For: Java-SDO-1.0
>
>
> package com.hollycrm.sdo;
> import java.io.FileWriter;
> import java.io.Writer;
> import java.util.Iterator;
> import java.util.List;
> import org.apache.tuscany.samples.sdo.SdoSampleConstants;
> import org.apache.tuscany.sdo.util.SDOUtil;
> import commonj.sdo.Type;
> import commonj.sdo.helper.HelperContext;
> import commonj.sdo.helper.TypeHelper;
> import commonj.sdo.helper.XMLHelper;
> import commonj.sdo.helper.XSDHelper;
> public class POXSDTest {
>   public static void main(String[]argv)throws Exception{
>   HelperContext hc = SDOUtil.createHelperContext(true);
>   
>   
> hc.getXSDHelper().define(ClassLoader.getSystemResourceAsStream("po.xsd"), 
> null);   
>   List allTypes = SDOUtil.getTypes(hc.getTypeHelper(), 
> "http://www.example.com/PO";);
>   removeDocumentRootType(allTypes);
>   String xsd = hc.getXSDHelper().generate(allTypes);
>   Writer w = new FileWriter("po2.xsd");
>   w.write(xsd);
>   }
>   /**
>* eliminate a bug
>* @param allTypes
>*/
>   private static void removeDocumentRootType(List allTypes) {
>   for (Iterator iter = allTypes.iterator(); iter.hasNext();) {
>   Type t = (Type) iter.next();
>   if ("DocumentRoot".equals(t.getName())) {
>   iter.remove();
>   continue;
>   }
>   
>   }
>   }
> }
> console out---
> Exception in thread "main" java.lang.IllegalArgumentException: Cannot 
> generate XSD since SDO Type 'item' was orginally generated from XSD.  Use 
> original XSD
>   at 
> org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:291)
>   at 
> org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:235)
>   at com.hollycrm.sdo.POXSDTest.main(POXSDTest.java:24)

-- 
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-1358) Exception in thread "main" java.lang.IllegalArgumentException: Cannot generate XSD since SDO Type 'item' was orginally generated from XSD. Use original XSD

[lizhantao (JIRA)]

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

lizhantao commented on TUSCANY-1358:


related source:
if ( !xsdHelper.isXSD( dataType ) )
{
if ( dataType.isDataType() )
{
schemaTypeName =  buildSimpleSchemaType(dataType);
}
else
{
schemaTypeName =  buildComplexSchemaType(dataType);
}
}
else
{
throw new IllegalArgumentException("Cannot generate XSD since 
SDO Type '" + 
dataType.getName() + "' was orginally generated from 
XSD.  Use original XSD");
}

> Exception in thread "main" java.lang.IllegalArgumentException: Cannot 
> generate XSD since SDO Type 'item' was orginally generated from XSD.  Use 
> original XSD
> 
>
> Key: TUSCANY-1358
> URL: https://issues.apache.org/jira/browse/TUSCANY-1358
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
>Reporter: lizhantao
>Priority: Blocker
> Fix For: Java-SDO-1.0
>
>
> package com.hollycrm.sdo;
> import java.io.FileWriter;
> import java.io.Writer;
> import java.util.Iterator;
> import java.util.List;
> import org.apache.tuscany.samples.sdo.SdoSampleConstants;
> import org.apache.tuscany.sdo.util.SDOUtil;
> import commonj.sdo.Type;
> import commonj.sdo.helper.HelperContext;
> import commonj.sdo.helper.TypeHelper;
> import commonj.sdo.helper.XMLHelper;
> import commonj.sdo.helper.XSDHelper;
> public class POXSDTest {
>   public static void main(String[]argv)throws Exception{
>   HelperContext hc = SDOUtil.createHelperContext(true);
>   
>   
> hc.getXSDHelper().define(ClassLoader.getSystemResourceAsStream("po.xsd"), 
> null);   
>   List allTypes = SDOUtil.getTypes(hc.getTypeHelper(), 
> "http://www.example.com/PO";);
>   removeDocumentRootType(allTypes);
>   String xsd = hc.getXSDHelper().generate(allTypes);
>   Writer w = new FileWriter("po2.xsd");
>   w.write(xsd);
>   }
>   /**
>* eliminate a bug
>* @param allTypes
>*/
>   private static void removeDocumentRootType(List allTypes) {
>   for (Iterator iter = allTypes.iterator(); iter.hasNext();) {
>   Type t = (Type) iter.next();
>   if ("DocumentRoot".equals(t.getName())) {
>   iter.remove();
>   continue;
>   }
>   
>   }
>   }
> }
> console out---
> Exception in thread "main" java.lang.IllegalArgumentException: Cannot 
> generate XSD since SDO Type 'item' was orginally generated from XSD.  Use 
> original XSD
>   at 
> org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:291)
>   at 
> org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:235)
>   at com.hollycrm.sdo.POXSDTest.main(POXSDTest.java:24)

-- 
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-1358) Exception in thread "main" java.lang.IllegalArgumentException: Cannot generate XSD since SDO Type 'item' was orginally generated from XSD. Use original XSD

[lizhantao (JIRA)]

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

lizhantao commented on TUSCANY-1358:


I need deserialize DataObject Type from xsd file and then modify DataObject 
Type, serialize modified DataObject Type to xsd file.

> Exception in thread "main" java.lang.IllegalArgumentException: Cannot 
> generate XSD since SDO Type 'item' was orginally generated from XSD.  Use 
> original XSD
> 
>
> Key: TUSCANY-1358
> URL: https://issues.apache.org/jira/browse/TUSCANY-1358
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
>Reporter: lizhantao
>Priority: Blocker
> Fix For: Java-SDO-1.0
>
>
> package com.hollycrm.sdo;
> import java.io.FileWriter;
> import java.io.Writer;
> import java.util.Iterator;
> import java.util.List;
> import org.apache.tuscany.samples.sdo.SdoSampleConstants;
> import org.apache.tuscany.sdo.util.SDOUtil;
> import commonj.sdo.Type;
> import commonj.sdo.helper.HelperContext;
> import commonj.sdo.helper.TypeHelper;
> import commonj.sdo.helper.XMLHelper;
> import commonj.sdo.helper.XSDHelper;
> public class POXSDTest {
>   public static void main(String[]argv)throws Exception{
>   HelperContext hc = SDOUtil.createHelperContext(true);
>   
>   
> hc.getXSDHelper().define(ClassLoader.getSystemResourceAsStream("po.xsd"), 
> null);   
>   List allTypes = SDOUtil.getTypes(hc.getTypeHelper(), 
> "http://www.example.com/PO";);
>   removeDocumentRootType(allTypes);
>   String xsd = hc.getXSDHelper().generate(allTypes);
>   Writer w = new FileWriter("po2.xsd");
>   w.write(xsd);
>   }
>   /**
>* eliminate a bug
>* @param allTypes
>*/
>   private static void removeDocumentRootType(List allTypes) {
>   for (Iterator iter = allTypes.iterator(); iter.hasNext();) {
>   Type t = (Type) iter.next();
>   if ("DocumentRoot".equals(t.getName())) {
>   iter.remove();
>   continue;
>   }
>   
>   }
>   }
> }
> console out---
> Exception in thread "main" java.lang.IllegalArgumentException: Cannot 
> generate XSD since SDO Type 'item' was orginally generated from XSD.  Use 
> original XSD
>   at 
> org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:291)
>   at 
> org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:235)
>   at com.hollycrm.sdo.POXSDTest.main(POXSDTest.java:24)

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


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

[jira] Created: (TUSCANY-1358) Exception in thread "main" java.lang.IllegalArgumentException: Cannot generate XSD since SDO Type 'item' was orginally generated from XSD. Use original XSD

[lizhantao (JIRA)]

Exception in thread "main" java.lang.IllegalArgumentException: Cannot generate 
XSD since SDO Type 'item' was orginally generated from XSD.  Use original XSD


 Key: TUSCANY-1358
 URL: https://issues.apache.org/jira/browse/TUSCANY-1358
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
Reporter: lizhantao
Priority: Blocker
 Fix For: Java-SDO-1.0


package com.hollycrm.sdo;

import java.io.FileWriter;
import java.io.Writer;
import java.util.Iterator;
import java.util.List;

import org.apache.tuscany.samples.sdo.SdoSampleConstants;
import org.apache.tuscany.sdo.util.SDOUtil;

import commonj.sdo.Type;
import commonj.sdo.helper.HelperContext;
import commonj.sdo.helper.TypeHelper;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.helper.XSDHelper;

public class POXSDTest {
public static void main(String[]argv)throws Exception{
HelperContext hc = SDOUtil.createHelperContext(true);


hc.getXSDHelper().define(ClassLoader.getSystemResourceAsStream("po.xsd"), 
null);   
List allTypes = SDOUtil.getTypes(hc.getTypeHelper(), 
"http://www.example.com/PO";);
removeDocumentRootType(allTypes);
String xsd = hc.getXSDHelper().generate(allTypes);
Writer w = new FileWriter("po2.xsd");
w.write(xsd);
}
/**
 * eliminate a bug
 * @param allTypes
 */
private static void removeDocumentRootType(List allTypes) {
for (Iterator iter = allTypes.iterator(); iter.hasNext();) {
Type t = (Type) iter.next();
if ("DocumentRoot".equals(t.getName())) {
iter.remove();
continue;
}

}
}
}
console out---
Exception in thread "main" java.lang.IllegalArgumentException: Cannot generate 
XSD since SDO Type 'item' was orginally generated from XSD.  Use original XSD
at 
org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:291)
at 
org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(XSDHelperImpl.java:235)
at com.hollycrm.sdo.POXSDTest.main(POXSDTest.java:24)

-- 
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-1357) The Result returned by SDOUtil.getTypes includes DocumentRoot Type

[Kelvin Goodson (JIRA)]

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

Kelvin Goodson resolved TUSCANY-1357.
-

Resolution: Invalid

Hello,
This issue has been addressed before in TUSCANY-708 and TUSCANY-1117.  Please 
see the comments in those JIRAs.   Reasoned discussion about design issues and 
implementation deficiencies is welcomed on the mailing lists.
Thanks.

> The Result returned by SDOUtil.getTypes includes DocumentRoot Type
> --
>
> Key: TUSCANY-1357
> URL: https://issues.apache.org/jira/browse/TUSCANY-1357
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: tuscany-sdo-impl-1.0-incubating-beta1.jar
>Reporter: lizhantao
> Fix For: Java-SDO-1.0
>
>
> It's ugly

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