Re: Not being able to edit wiki
Thanks ; ) Adriano Crestani On 6/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote: You should be all set for the wiki used as our website. I have added you to the proper groups. On 6/21/07, Simon Laws <[EMAIL PROTECTED]> wrote: > On 6/22/07, Adriano Crestani <[EMAIL PROTECTED]> wrote: > > > > Hi, can anyone tell me why I'm not being able to edit the wiki? I get this > > message: > > > > You do not have permission to view this page. > > > > You have to be a member of *all* the following groups to access this page. > > If this is incorrect please contact your administrator. > > Groups/User Set by On > > > > > > But no group/user is shown. > > > > Adriano Crestani > > > > Hi Adriano > > By wiki do you mean > > http://cwiki.apache.org/confluence/display/TUSCANY - the confluence space > that drives the Tuscany web site. > http://cwiki.apache.org/confluence/display/TUSCANYWIKI - the general wiki > space > > Regards > > 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]
Re: Not being able to edit wiki
You should be all set for the wiki used as our website. I have added you to the proper groups. On 6/21/07, Simon Laws <[EMAIL PROTECTED]> wrote: On 6/22/07, Adriano Crestani <[EMAIL PROTECTED]> wrote: > > Hi, can anyone tell me why I'm not being able to edit the wiki? I get this > message: > > You do not have permission to view this page. > > You have to be a member of *all* the following groups to access this page. > If this is incorrect please contact your administrator. > Groups/User Set by On > > > But no group/user is shown. > > Adriano Crestani Hi Adriano By wiki do you mean http://cwiki.apache.org/confluence/display/TUSCANY - the confluence space that drives the Tuscany web site. http://cwiki.apache.org/confluence/display/TUSCANYWIKI - the general wiki space Regards 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]
Re: Not being able to edit wiki
On 6/22/07, Adriano Crestani <[EMAIL PROTECTED]> wrote: Hi, can anyone tell me why I'm not being able to edit the wiki? I get this message: You do not have permission to view this page. You have to be a member of *all* the following groups to access this page. If this is incorrect please contact your administrator. Groups/User Set by On But no group/user is shown. Adriano Crestani Hi Adriano By wiki do you mean http://cwiki.apache.org/confluence/display/TUSCANY - the confluence space that drives the Tuscany web site. http://cwiki.apache.org/confluence/display/TUSCANYWIKI - the general wiki space Regards Simon
Not being able to edit wiki
Hi, can anyone tell me why I'm not being able to edit the wiki? I get this message: You do not have permission to view this page. You have to be a member of *all* the following groups to access this page. If this is incorrect please contact your administrator. Groups/User Set by On But no group/user is shown. Adriano Crestani
C++ SDO spec portability: RefCountingPointer
Hi,
In looking at C++ SDO portabilty, we found the the Tuscany C++ SDO class
RefCountingPointer has functions used externally by SCA:
operator T*() {return pointee;}
friend std::ostream& operator<< (std::ostream &os, const
RefCountingPointer& ptr)
It looks like the conversion to T* function may have been put in
originally as a porting alternative to a member function template, but
may not be needed any more since the member template is now included
outside the #ifdef.
Exposing the dumb pointer is undesirable since it raises object lifetime
issues and allows other unwanted operations. Having a conversion to bool
is convenient however, and can be implemented safely using a member
function pointer trick (see:
http://www.artima.com/cppsource/safebool.html).
The shift operator also seems undesireable since it places a burden on
all classes which use smart pointers to implement toString
functionality.
How does it sound to raise a Jira to have these member functions
removed?
Thanks,
Michael Yoder
Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
C++ SDO spec portability: C++ type definition API
Hi, C++ Tuscany SDO extends type definition API with the off-spec classes PropertyDefinition and TypeDefinition, which are used externally by SCA. We also have found the C++ SDO specification type definition API lacking, and have added the Impl member function DataFactoryImpl::define(DataObjectPtr) to parallel the Java type definition API using DataObject's of Types commonj.sdo#Type and commonj.sdo#Property. Should a Jira be raised for these classes to be removed or kept internal to Tuscany C++ SDO? Is there API here that it would be good to present to the comittee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Amita,
This part of your mapping is wrong:
XML_SAVE_LINE_BREAK OPTION_FORMATTED
XML_SAVE_INDENT OPTION_FORMATTED
XML_SAVE_MARGIN OPTION_FORMATTED
These options don't map to anything in EMF. They are Tuscany defined
options which are processed in SDOXMLResourceImpl.
Frank.
Fuhwei Lwo <[EMAIL PROTECTED]> wrote on 06/21/2007 02:44:55 PM:
> Hi Amita,
>
> Currently Tuscany SDO is not exposing all the EMF options for load
> and save. Also it's not 1:1 mapping from SDO to EMF options. That's
> why all the supported SDO options are described in the org.apache.
> tuscany.sdo.api.SDOHelper$XMLOptions. In order to add more options
> to SDO, you need to modify SDOHelper$XMLOptions then implement the
> new SDO option by either mapping to EMF's option or implementing
> your own. Also, I believe load and save options are mutually
> exclusive which means passing save options to load method will be a
no-op.
>
> In your test case for JIRA 1317, you cannot do something like this:
>
> options.put(XMLResource.OPTION_SAVE_DOCTYPE, Boolean.FALSE);
>
> because it's using EMF API not SDO's. From a SDO user point
> of view
>
> because it's using EMF API not SDO's. From a SDO user point of view,
> he/she should not need to import any EMF packages in his/her SDO
program.
>
> Fuhwei
>
> Amita Vadhavkar <[EMAIL PROTECTED]> wrote: Hi,
> I got the below mapping between Tuscany's XMLOptions and emf XMLResource
> Options
> Is this what is intended to be passed to in load method, i.e. is it
expected
> to
> have this mapping and pass appropriate options set to the doLoad()?
Also, we
> have
> multiple options for line formatting whereas there is only
OPTION_FORMATTED
> in emf XMLResource, so what needs to be done here?
> Mapping:-
>
> XML_SAVE_LINE_BREAK OPTION_FORMATTED
> XML_SAVE_LINE_BREAK OPTION_FORMATTED
> XML_SAVE_INDENT OPTION_FORMATTED
> XML_SAVE_MARGIN OPTION_FORMATTED
> XML_SAVE_LINE_WIDTH OPTION_LINE_WIDTH
> XML_SAVE_DOCTYPE OPTION_SAVE_DOCTYPE
> XML_LOAD_SCHEMA OPTION_SCHEMA_LOCATION
> XML_LOAD_LAX_FORM OPTION_EXTENDED_META_DATA - already implemented
>
> When we talk about moving away from emf, what will happen to these
options?
>
> I am yet to follow all the answers to the questions I had, but after
passing
> a couple of
> options (say OPTION_FORMATTED, OPTION_SAVE_DOCTYPE) and calling load(),
I
> see that in
> SDOXMLResourceImpl.doLoad() that options are getting passed, but I do
not
> see any
> difference in the deserialized DO(see the testcase - dumping do to
console
> using xmlhelper)
> with the option ON/OFF? So what super.doLoad() is
> doing?
>
> I am attaching a patch file JIRA_1317_June21.txt, just to show what code
> changes I have done so far, this is
> far away from the solution though. I will collect all answers from this
> thread and
> refine the patch, but kind of getting lost with doLoad().
>
> Regards,
> Amita
>
>
> On 6/21/07, Frank Budinsky wrote:
> >
> > The GENERATED_LOADER was used in conjuction with the -generateLoader
> > option in JavaGenerator. The JavaDoc says this:
> >
> > * -generateLoader
> > * Generate a fast XML parser/loader for instances of the
model.
> > The details of this option are
> > * subject to change, but currently it generates two additional
> > classes in a "util" package:
> > *
> ResourceImpl and
> ResourceFactoryImpl. To use
> > the generated loader at runtime,
> > * you need to pass an option to the XMLHelper.load() method
like
> > this:
> > * Map options = new HashMap();
> > * options.put("GENERATED_LOADER",
>
> > ResourceFactoryImpl.class);
> > * XMLDocument doc = XMLHelper.INSTANCE.load(new
> > FileInputStream("somefile.xml"), null, options);
> > * Note: this option currently only works for simple schemas
> > without substitution groups or wildcards.
> >
> > Note, however, that this was always an unsupported option (prototype)
and
> > it is now completely broken, since we swiched to the -noEMF code
generator
> > patterns.
> >
> > Frank.
> >
> >
> > "kelvin goodson" wrote on 06/21/2007 05:47:37
> > AM:
> >
> > > >
> > > > 3)What is meaning of below code in XMLDocumentImpl?
> > > > if (options instanceof Map)
> > > > {
> > > > Class resourceFactoryClass =
> > > > (Class)((Map)options).get("GENERATED_LOADER");
> > > > if (resourceFactoryClass != null)
> > > > {
> > > > try
> > > > {
> > > > Object resourceFactory =
resourceFactoryClass.newInstance();
> > > > resourceSet.getResourceFactoryRegistry().
> > > getExtensionToFactoryMap().put("*",
> > > > resourceFactory);
> > > > }
> > > > catch (Exception e)
> > > > {
> > > > e.printStackTrace();
> > > > }
> > > > }
> > > > }
> > >
> > > I looked back at the svn history, and this code has been there
since
> > > the original contribution of code to Apache.
> > >
> > > My guess from the name of the option and othe
C++ SDO spec portability: DataObjectInstance
Hi, Tuscany C++ SDO introduces an off-spec class used externally by a few SCA samples, DataObjectInstance. What is the rationale for having this class? Would it be alright for the samples to use SDO API smart pointers instead, and remove this class, or is this a concept that might be worth considering for the specification? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SDO spec compliance/portability: Type enums
Hi Pete, I submitted these JIRA issues: TUSCANY-1366 C++ SDO spec portability: SDORuntimeException off-spec member functions TUSCANY-1367 C++ SDO spec compliance/portability: Type::Types::IntegerType should be renamed Type::Types::IntType TUSCANY-1368 C++ SDO portability: class interface Type off-spec enum values Michael -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 9:21 AM To: tuscany-dev@ws.apache.org Subject: Re: SDO spec compliance/portability: Type enums the num_type is just a convenient way to know the extent of an enum and is common practice. I guess the OpenDataObjectType must be a Tuscany specific extension to handle open types. I'd need to do some research to determine if this is missing from the spec or can be removed. Please raise a Jira for the renaming of IntegerType. It may be useful to raise Jiras for all these issues so we can track them. Cheers, On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote: > > 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] > > -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1368) C++ SDO portability: class interface Type off-spec enum values
C++ SDO portability: class interface Type off-spec enum values
--
Key: TUSCANY-1368
URL: https://issues.apache.org/jira/browse/TUSCANY-1368
Project: Tuscany
Issue Type: Improvement
Reporter: Michael Yoder
C++ SDO specification class interface Type has enum values
("OpenDataObjectType", "num_type")which are not in the specification, and are
being used externally by SCA. It would seem that for SDO portability these
should be taken internal to SDO or submitted to the spec committee.
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 9:21 AM
To: tuscany-dev@ws.apache.org
Subject: Re: SDO spec compliance/portability: Type enums
the num_type is just a convenient way to know the extent of an enum and is
common practice. I guess the OpenDataObjectType must be a Tuscany specific
extension to handle open types. I'd need to do some research to determine if
this is missing from the spec or can be removed.
Please raise a Jira for the renaming of IntegerType.
It may be useful to raise Jiras for all these issues so we can track them.
Cheers,
On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
>
> 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]
>
>
--
Pete
--
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-1367) C++ SDO spec compliance/portability: Type::Types::IntegerType should be renamed Type::Types::IntType
C++ SDO spec compliance/portability: Type::Types::IntegerType should be renamed Type::Types::IntType Key: TUSCANY-1367 URL: https://issues.apache.org/jira/browse/TUSCANY-1367 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-M3 Environment: portability issue - all platforms Reporter: Michael Yoder The C++ SDO 2.1 spec renamed Type::Types::IntegerType to Type::Types::IntType. This will need to be updated in the Type interface. -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 9:21 AM To: tuscany-dev@ws.apache.org Subject: Re: SDO spec compliance/portability: Type enums the num_type is just a convenient way to know the extent of an enum and is common practice. I guess the OpenDataObjectType must be a Tuscany specific extension to handle open types. I'd need to do some research to determine if this is missing from the spec or can be removed. Please raise a Jira for the renaming of IntegerType. It may be useful to raise Jiras for all these issues so we can track them. Cheers, On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote: > > 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] > > -- Pete -- 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-1366) C++ SDO spec portability: SDORuntimeException off-spec member functions
C++ SDO spec portability: SDORuntimeException off-spec member functions
---
Key: TUSCANY-1366
URL: https://issues.apache.org/jira/browse/TUSCANY-1366
Project: Tuscany
Issue Type: Improvement
Components: C++ SDO
Affects Versions: Cpp-M3
Environment: portability issue -- all platforms
Reporter: Michael Yoder
Tuscany C++ SDO specification class SDORuntimeException has off-spec member
functions used by SCA (shown in the e-mail thread below). It would seem that
for portability these should be taken internal to Tuscany SDO, or submitted to
the spec committee.
-Original Message-
From: Michael Yoder
Sent: Thursday, June 21, 2007 7:37 PM
To: 'tuscany-dev@ws.apache.org'
Subject: RE: C++ SDO spec compliance/portability: SDORuntimeException
Thanks Pete,
Yes, these issues I am putting together and posting came up when doing a
portability study using HydraSDO to build Tuscany SCA. Since the SDO spec is
separate from SCA, we were thinking this would be a good goal. That seems to
mean making them internal to Tuscany SDO or taking them to the committee.
Michael
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 9:02 AM
To: tuscany-dev@ws.apache.org
Subject: Re: C++ SDO spec compliance/portability: SDORuntimeException
Michael,
An interesting set of questions! I'm not convinced that adding methods to the
spec api classes is a compliance issue (in fact it may be impossible to
implement without modifying the spec apis ... constructors etc.) but it could
be a portability issue if it is not clear that the methods are implementation
specific.
The methods below are added so that an SDORuntimeException can contain a
"stack" of locations indicating where it was thrown/rethrown etc.. These are
only used within the Tuscany implementation so I guess could be moved to
protected and make the classes that use them friends?? I'm not sure how useful
these are anyway but the exception class pre-dates it being used for
SDORuntimeException.
There are also methods to allow simple streaming:
catch(SDORuntimeException& e)
{
cout << e;
}
I like the simplicity of this but I guess we could write an SDOUtils method to
do something similar instead.
I'm not sure if any of these should be mandated by the specification.
Cheers,
On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
>
> 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]
>
>
--
Pete
--
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 spec compliance/portability: SDORuntimeException
Thanks Pete,
Yes, these issues I am putting together and posting came up when doing a
portability study using HydraSDO to build Tuscany SCA. Since the SDO
spec is separate from SCA, we were thinking this would be a good goal.
That seems to mean making them internal to Tuscany SDO or taking them to
the committee.
Michael
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 9:02 AM
To: tuscany-dev@ws.apache.org
Subject: Re: C++ SDO spec compliance/portability: SDORuntimeException
Michael,
An interesting set of questions! I'm not convinced that adding methods
to the spec api classes is a compliance issue (in fact it may be
impossible to implement without modifying the spec apis ... constructors
etc.) but it could be a portability issue if it is not clear that the
methods are implementation specific.
The methods below are added so that an SDORuntimeException can contain a
"stack" of locations indicating where it was thrown/rethrown etc.. These
are only used within the Tuscany implementation so I guess could be
moved to protected and make the classes that use them friends?? I'm not
sure how useful these are anyway but the exception class pre-dates it
being used for SDORuntimeException.
There are also methods to allow simple streaming:
catch(SDORuntimeException& e)
{
cout << e;
}
I like the simplicity of this but I guess we could write an SDOUtils
method to do something similar instead.
I'm not sure if any of these should be mandated by the specification.
Cheers,
On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
>
> 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]
>
>
--
Pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
C++ SDO spec compliance/portability: DataFactory::setDefault
Hi, In the DataFactory interface, there are additional overloads for the setDefault member function which take URI and name parameters for a Type instead of a reference to a Type object. virtual SDO_API void setDefault( const char* typuri, const char* typnam, const char* propname, bool b ) = 0; virtual SDO_API void setDefault( const SDOString& typuri, const SDOString& typnam, const SDOString& propname, bool b ) = 0; . Would it be a good idea to file a Jira to have these submitted to the specification committe as additions? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
C++ SDO spec compliance/portability: DataFactory
Hi, In the DataFactory interface, the below member functions are exposed which aren't in the C++ 2.1 spec. Would it be appropriate to file a Jira/patch to have these removed from the spec interface? SDO_API virtual DataFactoryPtr clone(); virtual SDO_API bool generateInterface(const char* fileroot, const char *factoryname) = 0; virtual SDO_API bool generateInterface(const SDOString& fileroot, const SDOString& factoryname) = 0; virtual SDO_API void setPropertySubstitute( const char* uri, const char* inTypeName, const char* propname, const char* subname, const char* subTypeUri, const char* subTypeName) = 0; virtual SDO_API void setPropertySubstitute( const SDOString& uri, const SDOString& inTypeName, const SDOString& propname, const SDOString& subname, const SDOString& subTypeUri, const SDOString& subTypeName) = 0; virtual SDO_API void setPropertySubstitute( const Type& containertype, const char* propname, const char* subname, const Type& subtype) = 0; virtual SDO_API void setPropertySubstitute( const Type& containertype, const SDOString& propname, const SDOString& subname, const Type& subtype) = 0; Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domains, runtimes, components and cardinality
Hi, I have a few comments embedded below. Dave - Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Monday, June 18, 2007 9:55 PM Subject: Re: Domains, runtimes, components and cardinality Hi, Please see my comments inline below. Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: "tuscany-dev" Sent: Monday, June 18, 2007 5:25 AM Subject: Domains, runtimes, components and cardinality 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. I think a single Tuscany SCA runtime can only join one SCA domain. For a single machine (node), we can have multiple runtimes. These runtimes will have to share the resources, for example, using different ports for the http protocol. I'm not sure if we need to have the node concept between the SCA domain and runtime. The definition of runtime is still not clear to me. It should be possible to for a single operating system process (like a JVM) host components running in different domains. Is this scenario 1 runtime which supports multiple domains, or is a runtime the process local instantiation of a domain? 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. We might have different cases here: 1) For load-balancing, we can assign a component to multiple runtimes 2) For a singleton service, we may have to assign it to a single runtime (a backup runtime can be picked for HA). Even further, consider recursive composition. Suppose CompA is implemented by Composite Cz, which is an assembly of atomic components. CompA's composite is deployedthe atomic components in Cz are targetted to different hosting environments (I'm avoiding the use of the word runtime) because there isn't a single host that is capable of running all of them. How many runtimes does CompA a run in? Start simple, just don't want you to lose the big picture. 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 - 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]
C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string& prop)
Hi, In the DataObject interface, these member functions are present which are not in the C++ 2.1 specification: virtual const Property& getProperty(unsigned int index) = 0; virtual const Property& getProperty(const char* prop) = 0; virtual const Property& getProperty(const SDOString& prop) = 0; Since the 2.1 spec now has "getInstanceProperty(const std::string& prop)", would it be a good idea to file a Jira/patch to replace these member functions with it in the specification interface? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
C++ SDO spec compliance/portability: DataObject
Hi, In the DataObject interface, these member functions are exposed which aren't in the C++ 2.1 spec: virtual SDO_API bool hasProperty(const char* name) = 0; virtual SDO_API bool hasProperty(const SDOString& name) = 0; virtual SDO_API DataFactory* getDataFactory() = 0; virtual SDO_API void setUserData(const char* path,void* value) = 0; virtual SDO_API void setUserData(const SDOString& path, void* value) = 0; virtual SDO_API void setUserData(unsigned int propertyIndex, void* value) = 0; virtual SDO_API void setUserData(const Property& property, void* value) = 0; virtual SDO_API void setUserData(void* value) = 0; virtual SDO_API void* getUserData(const char* path) = 0; virtual SDO_API void* getUserData(const SDOString& path) = 0; virtual SDO_API void* getUserData(unsigned int propertyIndex) = 0; virtual SDO_API void* getUserData(const Property& property) = 0; virtual SDO_API void* getUserData() = 0; virtual SDO_SPI const char* objectToXPath() = 0; Would it be appropriate to file a Jira/patch to have these removed from the spec interface? Or alternatively a Jira to submit them to the spec committee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1365) Bootstrap the ODE server in the BPEL implementation
[ https://issues.apache.org/jira/browse/TUSCANY-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Riou updated TUSCANY-1365: --- Attachment: ode-init.zip Zip file to unzip in implementation-bpel > Bootstrap the ODE server in the BPEL implementation > --- > > Key: TUSCANY-1365 > URL: https://issues.apache.org/jira/browse/TUSCANY-1365 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA BPEL Implementation Extension >Reporter: Matthieu Riou > Attachments: ode-init.patch, ode-init.zip > > > I'm attaching a patch and a zip (for new files) containing the necessary code > to bootstrap the ODE BPEL server. It actually doesn't give you much as it's > just initializing all resources needed by the server and then loading it, so > nothing is there for exchanging messages. But it's already a start. > Testing is a bit rough as it's still very preliminary but here are the steps > to get the test case to run: > 1. You'll need to build ODE locally first. I'm basing the code on ODE's trunk > as some tweaks or improvements here and there will probably be needed in ODE > as well. Later on, when the implementation is bit more stable, I'll publish > snapshots and eventually transition to an ODE release. In the meantime, here > is how to build ODE (using buildr): > http://incubator.apache.org/ode/jacob.html > Run the "install" task instead of "package" to have the created jars > published in your local directory. > 2. The server initializes Derby, so you need to have a Derby database. For > now it will be looking for it in an ode-work subdirectory of the BPEL > implementation root directory (until we implement a better way to find it). > Create this directory and copy the jpadb directory found in > ode/dao-jpa-ojpa-derby/target/derby after ODE has been built in it. You > should end up with implementation-bpel/ode-work/jpadb. > 3. Run "mvn test". Maven2 being a pain, it will download the whole world. > Several things aren't actually required but come with transitive > dependencies, we'll have to exclude things at some point but for now it > should work. > If the Maven2 build fails because it couldn't download a dependency, you'll > need to add some remote repositories. Here are the ones we have in ODE: > repositories.remote << "http://pxe.intalio.org/public/maven2"; > repositories.remote << > "http://people.apache.org/repo/m2-incubating-repository"; > repositories.remote << "http://repo1.maven.org/maven2"; > repositories.remote << "http://people.apache.org/repo/m2-snapshot-repository"; > Thanks! -- 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-1365) Bootstrap the ODE server in the BPEL implementation
[ https://issues.apache.org/jira/browse/TUSCANY-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Riou updated TUSCANY-1365: --- Attachment: ode-init.patch Patch file to apply in implementation-bpel > Bootstrap the ODE server in the BPEL implementation > --- > > Key: TUSCANY-1365 > URL: https://issues.apache.org/jira/browse/TUSCANY-1365 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA BPEL Implementation Extension >Reporter: Matthieu Riou > Attachments: ode-init.patch > > > I'm attaching a patch and a zip (for new files) containing the necessary code > to bootstrap the ODE BPEL server. It actually doesn't give you much as it's > just initializing all resources needed by the server and then loading it, so > nothing is there for exchanging messages. But it's already a start. > Testing is a bit rough as it's still very preliminary but here are the steps > to get the test case to run: > 1. You'll need to build ODE locally first. I'm basing the code on ODE's trunk > as some tweaks or improvements here and there will probably be needed in ODE > as well. Later on, when the implementation is bit more stable, I'll publish > snapshots and eventually transition to an ODE release. In the meantime, here > is how to build ODE (using buildr): > http://incubator.apache.org/ode/jacob.html > Run the "install" task instead of "package" to have the created jars > published in your local directory. > 2. The server initializes Derby, so you need to have a Derby database. For > now it will be looking for it in an ode-work subdirectory of the BPEL > implementation root directory (until we implement a better way to find it). > Create this directory and copy the jpadb directory found in > ode/dao-jpa-ojpa-derby/target/derby after ODE has been built in it. You > should end up with implementation-bpel/ode-work/jpadb. > 3. Run "mvn test". Maven2 being a pain, it will download the whole world. > Several things aren't actually required but come with transitive > dependencies, we'll have to exclude things at some point but for now it > should work. > If the Maven2 build fails because it couldn't download a dependency, you'll > need to add some remote repositories. Here are the ones we have in ODE: > repositories.remote << "http://pxe.intalio.org/public/maven2"; > repositories.remote << > "http://people.apache.org/repo/m2-incubating-repository"; > repositories.remote << "http://repo1.maven.org/maven2"; > repositories.remote << "http://people.apache.org/repo/m2-snapshot-repository"; > Thanks! -- 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-1365) Bootstrap the ODE server in the BPEL implementation
Bootstrap the ODE server in the BPEL implementation --- Key: TUSCANY-1365 URL: https://issues.apache.org/jira/browse/TUSCANY-1365 Project: Tuscany Issue Type: New Feature Components: Java SCA BPEL Implementation Extension Reporter: Matthieu Riou Attachments: ode-init.patch I'm attaching a patch and a zip (for new files) containing the necessary code to bootstrap the ODE BPEL server. It actually doesn't give you much as it's just initializing all resources needed by the server and then loading it, so nothing is there for exchanging messages. But it's already a start. Testing is a bit rough as it's still very preliminary but here are the steps to get the test case to run: 1. You'll need to build ODE locally first. I'm basing the code on ODE's trunk as some tweaks or improvements here and there will probably be needed in ODE as well. Later on, when the implementation is bit more stable, I'll publish snapshots and eventually transition to an ODE release. In the meantime, here is how to build ODE (using buildr): http://incubator.apache.org/ode/jacob.html Run the "install" task instead of "package" to have the created jars published in your local directory. 2. The server initializes Derby, so you need to have a Derby database. For now it will be looking for it in an ode-work subdirectory of the BPEL implementation root directory (until we implement a better way to find it). Create this directory and copy the jpadb directory found in ode/dao-jpa-ojpa-derby/target/derby after ODE has been built in it. You should end up with implementation-bpel/ode-work/jpadb. 3. Run "mvn test". Maven2 being a pain, it will download the whole world. Several things aren't actually required but come with transitive dependencies, we'll have to exclude things at some point but for now it should work. If the Maven2 build fails because it couldn't download a dependency, you'll need to add some remote repositories. Here are the ones we have in ODE: repositories.remote << "http://pxe.intalio.org/public/maven2"; repositories.remote << "http://people.apache.org/repo/m2-incubating-repository"; repositories.remote << "http://repo1.maven.org/maven2"; repositories.remote << "http://people.apache.org/repo/m2-snapshot-repository"; Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany/ODE resources questions
Hi Matthieu Let me try to answer these questions inline On 6/20/07, Matthieu Riou <[EMAIL PROTECTED]> wrote: 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 data source, some memory optimization modes we can run in, ... These would be for the whole ODE server and not on a per-process basis. SCA does not enforce any mechanism here, I'd say you could use the class loader to get access to the configuration file, something like : - Add configuration file to class path (either by packaging to the sca contribution or by adding to the class path when the jvm gets started) and then uses classLoader.getResource() to access the file. - You could also use a system property that points to the file. 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. We don't have an extension point for transaction manager at the moment, but if this is a requirement, we could package the geronimo transaction manager and make it available. 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) Is this one database per ODE engine/server ? Then you could probably use the approach described in item 1. I have a similar scenario in application.data, and I'm adding the dataSource information for the database inside the composite file, see [1], and that get's processed by the ContributionProcessor [2]. [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-data/src/test/resources/data.composite [2] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-data/src/main/java/org/apache/tuscany/sca/implementation/data/DATAImplementationProcessor.java I think that's all for now but I'll certainly find more in the coming days :) Thanks! Matthieu Hope this helps, let me know if you have further questions... -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Toys?
I like the idea of a .composite file validator, would that be an
eclipse plugin ? Also, I might start a new thread on this, but how do
we handle extension implementation validations (e.g
implementation.data defining some other elements for the composite
file ? )
+1 for sca/tools/c++ and sca/tools/java
On 6/21/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
These sound like very useful tools.
What about for the C++ side? What about making the modules something
like sca/tools/c++ and sca/tools/java?
Brady
-Original Message-
From: Venkata Krishnan [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 11:13 AM
To: tuscany-dev@ws.apache.org
Subject: Re: SCA Toys?
This would be good to get users one step forward with respect to using
SCA.
A good tool to have would be one that validates a composite assembly -
against the xsds and then for overall consistency. I know we do quite a
bit of the latter as part of the artifact processing but wonder if it
would go an extra mile if abstracted as a tool.
I also liked the transformers that we have in the databinding modules
today. It would be good to have them as individual tools as well.
I'd go for java/tools, atleast to start with.
- Venkat
On 6/21/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> I've collected a couple of utilites that have helped me during
> debugging some problems (
>
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/sample
> -sca-toys/
> ).
> For example this is the code I drop at the end of a test to print out
> the model hierarchy that was built:
>
> // inspect the model
> Field domainCompositeField = scaDomain.getClass
> ().getDeclaredField("domainComposite");
> domainCompositeField.setAccessible(true);
> Composite domainComposite = (Composite)
> domainCompositeField.get(scaDomain);
>
> OutputStream os = new ByteArrayOutputStream();
> PrintUtil printUtil = new PrintUtil(os);
> printUtil.print(domainComposite);
> System.out.println("Assembly \n " + os.toString());
>
> I'm sure people have much smarter utils than I that they use to make
> their lives easier. If you have tools are you prepared to share them?
>
> How about we create a module:
>
> java/sca/devtools
>
> or even
>
> java/devtools
>
> Simon
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Hi Amita,
Currently Tuscany SDO is not exposing all the EMF options for load and save.
Also it's not 1:1 mapping from SDO to EMF options. That's why all the supported
SDO options are described in the
org.apache.tuscany.sdo.api.SDOHelper$XMLOptions. In order to add more options
to SDO, you need to modify SDOHelper$XMLOptions then implement the new SDO
option by either mapping to EMF's option or implementing your own. Also, I
believe load and save options are mutually exclusive which means passing save
options to load method will be a no-op.
In your test case for JIRA 1317, you cannot do something like this:
options.put(XMLResource.OPTION_SAVE_DOCTYPE, Boolean.FALSE);
because it's using EMF API not SDO's. From a SDO user point
of view
because it's using EMF API not SDO's. From a SDO user point of view, he/she
should not need to import any EMF packages in his/her SDO program.
Fuhwei
Amita Vadhavkar <[EMAIL PROTECTED]> wrote: Hi,
I got the below mapping between Tuscany's XMLOptions and emf XMLResource
Options
Is this what is intended to be passed to in load method, i.e. is it expected
to
have this mapping and pass appropriate options set to the doLoad()? Also, we
have
multiple options for line formatting whereas there is only OPTION_FORMATTED
in emf XMLResource, so what needs to be done here?
Mapping:-
XML_SAVE_LINE_BREAK OPTION_FORMATTED
XML_SAVE_LINE_BREAK OPTION_FORMATTED
XML_SAVE_INDENT OPTION_FORMATTED
XML_SAVE_MARGIN OPTION_FORMATTED
XML_SAVE_LINE_WIDTH OPTION_LINE_WIDTH
XML_SAVE_DOCTYPE OPTION_SAVE_DOCTYPE
XML_LOAD_SCHEMA OPTION_SCHEMA_LOCATION
XML_LOAD_LAX_FORM OPTION_EXTENDED_META_DATA - already implemented
When we talk about moving away from emf, what will happen to these options?
I am yet to follow all the answers to the questions I had, but after passing
a couple of
options (say OPTION_FORMATTED, OPTION_SAVE_DOCTYPE) and calling load(), I
see that in
SDOXMLResourceImpl.doLoad() that options are getting passed, but I do not
see any
difference in the deserialized DO(see the testcase - dumping do to console
using xmlhelper)
with the option ON/OFF? So what super.doLoad() is
doing?
I am attaching a patch file JIRA_1317_June21.txt, just to show what code
changes I have done so far, this is
far away from the solution though. I will collect all answers from this
thread and
refine the patch, but kind of getting lost with doLoad().
Regards,
Amita
On 6/21/07, Frank Budinsky wrote:
>
> The GENERATED_LOADER was used in conjuction with the -generateLoader
> option in JavaGenerator. The JavaDoc says this:
>
> * -generateLoader
> * Generate a fast XML parser/loader for instances of the model.
> The details of this option are
> * subject to change, but currently it generates two additional
> classes in a "util" package:
> *
ResourceImpl and
ResourceFactoryImpl. To use
> the generated loader at runtime,
> * you need to pass an option to the XMLHelper.load() method like
> this:
> * Map options = new HashMap();
> * options.put("GENERATED_LOADER",
> ResourceFactoryImpl.class);
> * XMLDocument doc = XMLHelper.INSTANCE.load(new
> FileInputStream("somefile.xml"), null, options);
> * Note: this option currently only works for simple schemas
> without substitution groups or wildcards.
>
> Note, however, that this was always an unsupported option (prototype) and
> it is now completely broken, since we swiched to the -noEMF code generator
> patterns.
>
> Frank.
>
>
> "kelvin goodson" wrote on 06/21/2007 05:47:37
> AM:
>
> > >
> > > 3)What is meaning of below code in XMLDocumentImpl?
> > > if (options instanceof Map)
> > > {
> > > Class resourceFactoryClass =
> > > (Class)((Map)options).get("GENERATED_LOADER");
> > > if (resourceFactoryClass != null)
> > > {
> > > try
> > > {
> > > Object resourceFactory = resourceFactoryClass.newInstance();
> > > resourceSet.getResourceFactoryRegistry().
> > getExtensionToFactoryMap().put("*",
> > > resourceFactory);
> > > }
> > > catch (Exception e)
> > > {
> > > e.printStackTrace();
> > > }
> > > }
> > > }
> >
> > I looked back at the svn history, and this code has been there since
> > the original contribution of code to Apache.
> >
> > My guess from the name of the option and other brushes with topics of
> > a similar nature is that this allows optimised loads of XML documents
> > of a specific nature by employing a generated Factory which loads only
> > documents conforming to s specific XML schema.
> >
> > It would be good to get a test in place to exercise this code if it is
> > still relevant. I know for sure that neither the unit tests nor the
> > CTS exercises it.
> >
> > This is standard EMF stuff, but I'm not sure whether we ever put it
> > to good use in SDO, so all I can do is translate the meaning of the
> > code to the best of my understanding, which you may al
RE: SCA Toys?
These sound like very useful tools.
What about for the C++ side? What about making the modules something
like sca/tools/c++ and sca/tools/java?
Brady
-Original Message-
From: Venkata Krishnan [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 11:13 AM
To: tuscany-dev@ws.apache.org
Subject: Re: SCA Toys?
This would be good to get users one step forward with respect to using
SCA.
A good tool to have would be one that validates a composite assembly -
against the xsds and then for overall consistency. I know we do quite a
bit of the latter as part of the artifact processing but wonder if it
would go an extra mile if abstracted as a tool.
I also liked the transformers that we have in the databinding modules
today. It would be good to have them as individual tools as well.
I'd go for java/tools, atleast to start with.
- Venkat
On 6/21/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> I've collected a couple of utilites that have helped me during
> debugging some problems (
>
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/sample
> -sca-toys/
> ).
> For example this is the code I drop at the end of a test to print out
> the model hierarchy that was built:
>
> // inspect the model
> Field domainCompositeField = scaDomain.getClass
> ().getDeclaredField("domainComposite");
> domainCompositeField.setAccessible(true);
> Composite domainComposite = (Composite)
> domainCompositeField.get(scaDomain);
>
> OutputStream os = new ByteArrayOutputStream();
> PrintUtil printUtil = new PrintUtil(os);
> printUtil.print(domainComposite);
> System.out.println("Assembly \n " + os.toString());
>
> I'm sure people have much smarter utils than I that they use to make
> their lives easier. If you have tools are you prepared to share them?
>
> How about we create a module:
>
> java/sca/devtools
>
> or even
>
> java/devtools
>
> Simon
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Toys?
On 6/21/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
This would be good to get users one step forward with respect to using
SCA.
A good tool to have would be one that validates a composite assembly -
against the xsds and then for overall consistency. I know we do quite a
bit
of the latter as part of the artifact processing but wonder if it would go
an extra mile if abstracted as a tool.
I also liked the transformers that we have in the databinding modules
today. It would be good to have them as individual tools as well.
I'd go for java/tools, atleast to start with.
- Venkat
On 6/21/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> I've collected a couple of utilites that have helped me during debugging
> some problems (
>
>
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/sample-sca-toys/
> ).
> For example this is the code I drop at the end of a test to print out
the
> model hierarchy that was built:
>
> // inspect the model
> Field domainCompositeField = scaDomain.getClass
> ().getDeclaredField("domainComposite");
> domainCompositeField.setAccessible(true);
> Composite domainComposite = (Composite)
> domainCompositeField.get(scaDomain);
>
> OutputStream os = new ByteArrayOutputStream();
> PrintUtil printUtil = new PrintUtil(os);
> printUtil.print(domainComposite);
> System.out.println("Assembly \n " + os.toString());
>
> I'm sure people have much smarter utils than I that they use to make
their
> lives easier. If you have tools are you prepared to share them?
>
> How about we create a module:
>
> java/sca/devtools
>
> or even
>
> java/devtools
>
> Simon
>
Venkat , you make a very good point. I meant to cross posted to the users
list also and didn't. I expect there are thoughts about what might be useful
or even some contributions? Have copied this note to dev and users.
Simon
Re: Stage 1 Distributed runtime checked into trunk
On 6/20/07, Simon Laws <[EMAIL PROTECTED]> wrote: 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 I've just added the binding.sca and distributed modules to the modules pom and I've added the calculated-distributed module to the samples pom. This has the effect of building and running the sample for the simple distributed runtime implementation. I still haven't fixed the EOFException that I see when ActiveMQ 4.1 is closing down so you see a couple of exceptions at the end of the sample run. They don't affect the result but I'll go see if I can get rid of them. Simon
Re: SCA Toys?
This would be good to get users one step forward with respect to using SCA.
A good tool to have would be one that validates a composite assembly -
against the xsds and then for overall consistency. I know we do quite a bit
of the latter as part of the artifact processing but wonder if it would go
an extra mile if abstracted as a tool.
I also liked the transformers that we have in the databinding modules
today. It would be good to have them as individual tools as well.
I'd go for java/tools, atleast to start with.
- Venkat
On 6/21/07, Simon Laws <[EMAIL PROTECTED]> wrote:
I've collected a couple of utilites that have helped me during debugging
some problems (
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/sample-sca-toys/
).
For example this is the code I drop at the end of a test to print out the
model hierarchy that was built:
// inspect the model
Field domainCompositeField = scaDomain.getClass
().getDeclaredField("domainComposite");
domainCompositeField.setAccessible(true);
Composite domainComposite = (Composite)
domainCompositeField.get(scaDomain);
OutputStream os = new ByteArrayOutputStream();
PrintUtil printUtil = new PrintUtil(os);
printUtil.print(domainComposite);
System.out.println("Assembly \n " + os.toString());
I'm sure people have much smarter utils than I that they use to make their
lives easier. If you have tools are you prepared to share them?
How about we create a module:
java/sca/devtools
or even
java/devtools
Simon
SCA Toys?
I've collected a couple of utilites that have helped me during debugging
some problems (
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/sample-sca-toys/).
For example this is the code I drop at the end of a test to print out the
model hierarchy that was built:
// inspect the model
Field domainCompositeField = scaDomain.getClass
().getDeclaredField("domainComposite");
domainCompositeField.setAccessible(true);
Composite domainComposite = (Composite)
domainCompositeField.get(scaDomain);
OutputStream os = new ByteArrayOutputStream();
PrintUtil printUtil = new PrintUtil(os);
printUtil.print(domainComposite);
System.out.println("Assembly \n " + os.toString());
I'm sure people have much smarter utils than I that they use to make their
lives easier. If you have tools are you prepared to share them?
How about we create a module:
java/sca/devtools
or even
java/devtools
Simon
Re: SDO spec compliance/portability: Type enums
the num_type is just a convenient way to know the extent of an enum and is common practice. I guess the OpenDataObjectType must be a Tuscany specific extension to handle open types. I'd need to do some research to determine if this is missing from the spec or can be removed. Please raise a Jira for the renaming of IntegerType. It may be useful to raise Jiras for all these issues so we can track them. Cheers, On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote: 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] -- Pete
Re: SDO spec compliance/portability: Type
I guess this one could be moved as it is only there as a convenience. Cheers, On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote: 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] -- Pete
Re: C++ SDO spec compliance/portability: SDORuntimeException
Michael,
An interesting set of questions! I'm not convinced that adding methods to
the spec api classes is a compliance issue (in fact it may be impossible to
implement without modifying the spec apis ... constructors etc.) but it
could be a portability issue if it is not clear that the methods are
implementation specific.
The methods below are added so that an SDORuntimeException can contain a
"stack" of locations indicating where it was thrown/rethrown etc.. These are
only used within the Tuscany implementation so I guess could be moved to
protected and make the classes that use them friends?? I'm not sure how
useful these are anyway but the exception class pre-dates it being used for
SDORuntimeException.
There are also methods to allow simple streaming:
catch(SDORuntimeException& e)
{
cout << e;
}
I like the simplicity of this but I guess we could write an SDOUtils method
to do something similar instead.
I'm not sure if any of these should be mandated by the specification.
Cheers,
On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
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]
--
Pete
Exposing Data as Feeds (implementation.data)
After playing around with exposing data as services [1] and some off-line chat with Jean-Sebastien, he mentioned that it would be interesting to start exposing data as feeds as well. Implementation.data comes to this purpose, It gives you a REST view of a database table, and in conjunction with biding.feed it exposes the database contents as ATOM Feeds and can easily be aggregated into feed readers or other Web 2.0 feed-friendly solutions. At the moment, this is a work in progress, and implementation.data is only supporting the get portion of ATOM, and then work on other CRUD operations. I'm about to get a sample that demonstrate this new functionality available, but you can also look at the companyFeed test scenario available in the implementation itself, as it can give you further understanding. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18908.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nightly builds and the sdo spec project
The continuun build that runs overnight perform a maven build from java/sdo. If things are working from there, it should be fine. I think we should be ok cleaning the java/spec directory Also, removing the spec/sdo would probably fix the current build issue if you build from java, where I'm currently getting : Project 'commonj:sdo-api-r2.1' is duplicated in the reactor On 6/19/07, kelvin goodson <[EMAIL PROTECTED]> wrote: I have copied the sdo-api project from the java/spec/sdo-api direcotry in svn, to the java/sdo/sdo-api directory. I plan to delete the one under the spec folder, but I guess I might break the nightly builds if I do that. Since commit [1] the new copy of the spec project is now built by the java/sdo/pom.xml reactor pom, so the api dependency will be provided by that build. Please can someone who has been involved in the nightly build configuration tell me if it is safe to remove the old project, or make it safe to do so. Thanks, Kelvin.` [1] http://svn.apache.org/viewvc?view=rev&rev=548710 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
On 6/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: as long as something works, I'm not sure why we would exclude it from a Tuscany release. I think we need a bit more clarity about what it means to include something in the release. Is it just having the code included in the src distro, or included in the src distro as part of the build, or also included in the binary distro, or included in both distro's along with itests, samples, readme's or web site doc, and mention of the new thing in the release notes? From the 0.90 release things were pulled out for not being quite there, a lot of the time spent before the final release artifacts got done was because people reviewing the distro's wanted all things up to a certain standard. Getting all this done can take a lot of work. Last minute changes often cause unexpected blocking problems in the distributions resulting in respins and more delay. If we just include everything "that works" is someone reviewing a release RC going to complain that some new sample is missing a readme, that a demo should have an Ant build script, or that some new extension doesn't even have a sample? If things must be of a certain standard then I don't think its reasonable to expect the release manager to do all the work to get things there. How about: - by default everything is kept in the src distro unless there's some reason not to - only the things mentioned on the release wiki page get included in the build, binary distribution, and mentioned in the release notes - after the brn is cut we need to ask on the ML before adding new things to the wiki release page - adding something to the wiki release page implies some commitment to help get it to the required standard in line with the release schedule. ...ant
Re: [DAS] XQuery-DAS
Unfortunately it looks like XQEngine is GPL so unusable, we can't even have code using it in SVN. The only alternative i can think of is Saxon, maybe others know of something else? ...ant On 6/21/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: Hi, Need some help marked with #. In the implementation of XQuery DAS, I am trying to start simple and then gather requirements and features on the way and keep building. #For the first attempt, I am trying with sourceforge's XQEngine as the XQuery engine, as it has no license restrictions. Has anybody any comment about which implementation is better/worse? I want to create JIRA for XQuery DAS to attach first patch on the top of code available in https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das. #Help! Need somebody to create a new Component - Java DAS XQuery. https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/dashas a clear separation of api vs. impelmentation. In the first patch, I am trying to implement org.apache.tuscany.dasinterfaces from tuscany-das-api into tuscany-das-xquery and also using ServiceProvider framework to invoke xquery implementation. The code is very basic and working for single directory/single xml file 's xquery expression evaluation and there is nothing done for building a very basic DataObject (in-progress) The beginning of the mail thread has many features, here the features to be implemented in the order or importance, please add/comments to it. In the first attempt only xml files are considered and not databases supporting XQuery. As the development progresses - will attach a detailed design doc instead of having large mails - for easy review. Features List 1) support connection to FileSystem (no authentication considered, only mapped drive and directory) 2) support xquery expessions as Command (using XQEngine to get result) 3) mapping between result of xquery Command to DataObject (XQEngine can emit the xml , form a DataObject using XMLHelper) 4) CRUD support - involves mapping from DataObject to xml document, change summary to be added to file 5) FLWOR expression as Command 6) JOIN operation (use multiple files) Test Cases List Ideally will have > 1 test case for each feature Hoping to make XQuery DAS useful to the community as an alternative to other DAS flavours. Regards, Amita On 6/15/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > Hi All, > After a while on RDB DAS beta1 , I am trying to do more on XQuery DAS. > > Tried to check different XQuery implementations available, below is > summary: > > http://www.axyana.com///products.html Quizx/open - open source > Quizx/db(XQuest) - not open source > > http://www.gnu.org/software/qexo/ - license? - kawa > it compiles XQuery expressions and programs to Java bytecodes , this does > not have > API to be used, so not of much use > > http://www.oracle.com/technology/sample_code/tech/xml/xmldb/jxqi.html - > license will be a problem > > ***http://dsd.lbl.gov/nux/api/index.html - > http://dsd.lbl.gov/nux/license.html > has good set of APIs. I am not sure if the license poses some restrictions > on use. > Looks like this will be a good choice to give first attempt for XQuery > DAS. > Any advise? > > http://saxon.sourceforge.net/ - only SAXON-B is fee and SAXON-SA is > commercial,So may not be a good choice > > I am trying to start based on > https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/ > This uses Service Provider API to separate different DAS implementations. > There is > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.htmlthread > to discuss the high level approach to provide this. Please add your comments > there for refactoring approach. > > We can use the current mail thread for XQuery DAS specific comments. Also, > I will use > a new page on http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home > > to track detailed status for XQuery DAS. I will make sure not to link this > page > to any other page, so as not to mess up with ongoing release. > > Regards, > Amita > > > On 4/4/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > > > Hi Amita > > > > Related to the features, I think it's fine to start simple and get > > improvements gradatively as we progress... > > > > Some issues that you have identified: > > - Config model more flexible to accommodate differences between > > multiple implementation > > - Factory issues, and the ability to get different implementations > > Are already available in my sandbox [1] as part of the work I did to > > accommodate multiple DAS implementations [2] > > > > It's probably good idea to keep a XQuery DAS page on the Wiki and keep > > updating it with requirements, discussions and design we are taking... > > > > [1] - > > https://svn.apache.org/repos/asf/incubator/tus
[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[ https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1317: - Attachment: JIRA_1317_June21.txt Please see the patch JIRA_1317_June21.txt, it is just the work I did so far and noway the solution. Also, working on the mail thread comments, will refine patch based on that. > Provide a way to set default XML load options to be used during Java > deserialization > > > Key: TUSCANY-1317 > URL: https://issues.apache.org/jira/browse/TUSCANY-1317 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Affects Versions: Java-SDO-beta1, Java-SDO-1.0 >Reporter: Daniel Peter > Fix For: Java-SDO-1.0 > > Attachments: JIRA_1317_June21.txt > > > XML load options can be passed when calling the XMLHelper.load(...) methods. > But there is currently no way to pass such load options to be used during > Java deserialization. > Thus a way to set default load options should be provided, e.g. > SDOUtil.setDefaultXMLOptions(HelperContext, Object options) > These default options could then be picked up during Java deserialization, > i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl. > Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be > exposed in Tuscany SDO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Hi,
I got the below mapping between Tuscany's XMLOptions and emf XMLResource
Options
Is this what is intended to be passed to in load method, i.e. is it expected
to
have this mapping and pass appropriate options set to the doLoad()? Also, we
have
multiple options for line formatting whereas there is only OPTION_FORMATTED
in emf XMLResource, so what needs to be done here?
Mapping:-
XML_SAVE_LINE_BREAK OPTION_FORMATTED
XML_SAVE_LINE_BREAK OPTION_FORMATTED
XML_SAVE_INDENT OPTION_FORMATTED
XML_SAVE_MARGIN OPTION_FORMATTED
XML_SAVE_LINE_WIDTH OPTION_LINE_WIDTH
XML_SAVE_DOCTYPE OPTION_SAVE_DOCTYPE
XML_LOAD_SCHEMA OPTION_SCHEMA_LOCATION
XML_LOAD_LAX_FORM OPTION_EXTENDED_META_DATA - already implemented
When we talk about moving away from emf, what will happen to these options?
I am yet to follow all the answers to the questions I had, but after passing
a couple of
options (say OPTION_FORMATTED, OPTION_SAVE_DOCTYPE) and calling load(), I
see that in
SDOXMLResourceImpl.doLoad() that options are getting passed, but I do not
see any
difference in the deserialized DO(see the testcase - dumping do to console
using xmlhelper)
with the option ON/OFF? So what super.doLoad() is
doing?
I am attaching a patch file JIRA_1317_June21.txt, just to show what code
changes I have done so far, this is
far away from the solution though. I will collect all answers from this
thread and
refine the patch, but kind of getting lost with doLoad().
Regards,
Amita
On 6/21/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
The GENERATED_LOADER was used in conjuction with the -generateLoader
option in JavaGenerator. The JavaDoc says this:
* -generateLoader
* Generate a fast XML parser/loader for instances of the model.
The details of this option are
* subject to change, but currently it generates two additional
classes in a "util" package:
* ResourceImpl and ResourceFactoryImpl. To use
the generated loader at runtime,
* you need to pass an option to the XMLHelper.load() method like
this:
* Map options = new HashMap();
* options.put("GENERATED_LOADER",
ResourceFactoryImpl.class);
* XMLDocument doc = XMLHelper.INSTANCE.load(new
FileInputStream("somefile.xml"), null, options);
* Note: this option currently only works for simple schemas
without substitution groups or wildcards.
Note, however, that this was always an unsupported option (prototype) and
it is now completely broken, since we swiched to the -noEMF code generator
patterns.
Frank.
"kelvin goodson" <[EMAIL PROTECTED]> wrote on 06/21/2007 05:47:37
AM:
> >
> > 3)What is meaning of below code in XMLDocumentImpl?
> > if (options instanceof Map)
> > {
> > Class resourceFactoryClass =
> > (Class)((Map)options).get("GENERATED_LOADER");
> > if (resourceFactoryClass != null)
> > {
> > try
> > {
> > Object resourceFactory = resourceFactoryClass.newInstance();
> > resourceSet.getResourceFactoryRegistry().
> getExtensionToFactoryMap().put("*",
> > resourceFactory);
> > }
> > catch (Exception e)
> > {
> > e.printStackTrace();
> > }
> > }
> > }
>
> I looked back at the svn history, and this code has been there since
> the original contribution of code to Apache.
>
> My guess from the name of the option and other brushes with topics of
> a similar nature is that this allows optimised loads of XML documents
> of a specific nature by employing a generated Factory which loads only
> documents conforming to s specific XML schema.
>
> It would be good to get a test in place to exercise this code if it is
> still relevant. I know for sure that neither the unit tests nor the
> CTS exercises it.
>
> This is standard EMF stuff, but I'm not sure whether we ever put it
> to good use in SDO, so all I can do is translate the meaning of the
> code to the best of my understanding, which you may already
> understand anyway.
>
> In an EMF resource set, there can be a set of Factories that know how
> to create java objects from resources. The resource set holds a
> mapping from file extensions for the resources to factories. If a
> request is made to load a resource file with a given extension then
> the map is used to look up the factory that will be used to load the
> resource. There is scope for using wildcards in the file extensions in
> the mapping. If you want to override existing behaviour or add new
> file extensions you can add another factory to the mapping. So here
> the one option that seems to be permitted for this operation is the
> "GENERATED_LOADER" option, for which the value must be a class which
> is a Factory that knows how to load all resources that the resource
> set is going to encounter. A new instance of this factory is created
> and lodged in the resource set's map against the "*" wildcard. So
> whenever the resource set needs to load a resource, the Factory it
> uses to attempt to do the lo
Training session at ApacheCon 2007
Hello Jean-Sebastien, I just want you to know that I have been working hard on getting a nice sample application to be presented at ApacheCon. What I have been doing is modeling Amazon as services running on Tuscany while still sticking to Amazon's latest WSDL. What I have now is a simple SCA Composite providing only one service (4 operations) through web services. It means that all the required pieces for the demo are now properly running and connected (quite tough indeed). What I did so far: - Generation of code (stub and skeleton) out of Amazon WSDL (not straightforward) - Definición of services and their operations - Implementation of one whole service (I coded the Shopping Cart) - Describe it as a component/composite for Tuscany - Get the composite running (not straightforward) - Coded a WS client which invokes the service in order to test if everything was working fine (there were some complications with databiding here) What is still required is just implementing the core business logic for the remaining services/components and their operations. Fortunately, this will be a simple task (fingers crossed). Anyway, I do not consider such functionality to be so important. I think we need to highlight the benefits of Tuscany and having Amazon's complete set of business logic is not essential for that. As soon as I consider the demo is good enough, I will start writing a tutorial about it (any help will be greatly appreciated here) which we can hand out to participants in the training session. Any feedback will be welcome. Best regards, Mario Antollini
Re: [DAS] XQuery-DAS
Hi, Need some help marked with #. In the implementation of XQuery DAS, I am trying to start simple and then gather requirements and features on the way and keep building. #For the first attempt, I am trying with sourceforge's XQEngine as the XQuery engine, as it has no license restrictions. Has anybody any comment about which implementation is better/worse? I want to create JIRA for XQuery DAS to attach first patch on the top of code available in https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das. #Help! Need somebody to create a new Component - Java DAS XQuery. https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das has a clear separation of api vs. impelmentation. In the first patch, I am trying to implement org.apache.tuscany.dasinterfaces from tuscany-das-api into tuscany-das-xquery and also using ServiceProvider framework to invoke xquery implementation. The code is very basic and working for single directory/single xml file 's xquery expression evaluation and there is nothing done for building a very basic DataObject (in-progress) The beginning of the mail thread has many features, here the features to be implemented in the order or importance, please add/comments to it. In the first attempt only xml files are considered and not databases supporting XQuery. As the development progresses - will attach a detailed design doc instead of having large mails - for easy review. Features List 1) support connection to FileSystem (no authentication considered, only mapped drive and directory) 2) support xquery expessions as Command (using XQEngine to get result) 3) mapping between result of xquery Command to DataObject (XQEngine can emit the xml , form a DataObject using XMLHelper) 4) CRUD support - involves mapping from DataObject to xml document, change summary to be added to file 5) FLWOR expression as Command 6) JOIN operation (use multiple files) Test Cases List Ideally will have > 1 test case for each feature Hoping to make XQuery DAS useful to the community as an alternative to other DAS flavours. Regards, Amita On 6/15/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: Hi All, After a while on RDB DAS beta1 , I am trying to do more on XQuery DAS. Tried to check different XQuery implementations available, below is summary: http://www.axyana.com///products.html Quizx/open - open source Quizx/db(XQuest) - not open source http://www.gnu.org/software/qexo/ - license? - kawa it compiles XQuery expressions and programs to Java bytecodes , this does not have API to be used, so not of much use http://www.oracle.com/technology/sample_code/tech/xml/xmldb/jxqi.html - license will be a problem ***http://dsd.lbl.gov/nux/api/index.html - http://dsd.lbl.gov/nux/license.html has good set of APIs. I am not sure if the license poses some restrictions on use. Looks like this will be a good choice to give first attempt for XQuery DAS. Any advise? http://saxon.sourceforge.net/ - only SAXON-B is fee and SAXON-SA is commercial,So may not be a good choice I am trying to start based on https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/ This uses Service Provider API to separate different DAS implementations. There is http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.html thread to discuss the high level approach to provide this. Please add your comments there for refactoring approach. We can use the current mail thread for XQuery DAS specific comments. Also, I will use a new page on http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home to track detailed status for XQuery DAS. I will make sure not to link this page to any other page, so as not to mess up with ongoing release. Regards, Amita On 4/4/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > Hi Amita > > Related to the features, I think it's fine to start simple and get > improvements gradatively as we progress... > > Some issues that you have identified: > - Config model more flexible to accommodate differences between > multiple implementation > - Factory issues, and the ability to get different implementations > Are already available in my sandbox [1] as part of the work I did to > accommodate multiple DAS implementations [2] > > It's probably good idea to keep a XQuery DAS page on the Wiki and keep > updating it with requirements, discussions and design we are taking... > > [1] - > https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/ > [2] - > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.html > > On 3/26/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > > > Hi All, > > I am trying to create a prototype for supporting XQuery-DAS. Below are > > some points I have gathered so far. > > Please give your comments, add to the points. > > > > 1) Basic Feature
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
The GENERATED_LOADER was used in conjuction with the -generateLoader
option in JavaGenerator. The JavaDoc says this:
* -generateLoader
* Generate a fast XML parser/loader for instances of the model.
The details of this option are
* subject to change, but currently it generates two additional
classes in a "util" package:
* ResourceImpl and ResourceFactoryImpl. To use
the generated loader at runtime,
* you need to pass an option to the XMLHelper.load() method like
this:
* Map options = new HashMap();
* options.put("GENERATED_LOADER",
ResourceFactoryImpl.class);
* XMLDocument doc = XMLHelper.INSTANCE.load(new
FileInputStream("somefile.xml"), null, options);
* Note: this option currently only works for simple schemas
without substitution groups or wildcards.
Note, however, that this was always an unsupported option (prototype) and
it is now completely broken, since we swiched to the -noEMF code generator
patterns.
Frank.
"kelvin goodson" <[EMAIL PROTECTED]> wrote on 06/21/2007 05:47:37
AM:
> >
> > 3)What is meaning of below code in XMLDocumentImpl?
> > if (options instanceof Map)
> > {
> > Class resourceFactoryClass =
> > (Class)((Map)options).get("GENERATED_LOADER");
> > if (resourceFactoryClass != null)
> > {
> > try
> > {
> > Object resourceFactory = resourceFactoryClass.newInstance();
> > resourceSet.getResourceFactoryRegistry().
> getExtensionToFactoryMap().put("*",
> > resourceFactory);
> > }
> > catch (Exception e)
> > {
> > e.printStackTrace();
> > }
> > }
> > }
>
> I looked back at the svn history, and this code has been there since
> the original contribution of code to Apache.
>
> My guess from the name of the option and other brushes with topics of
> a similar nature is that this allows optimised loads of XML documents
> of a specific nature by employing a generated Factory which loads only
> documents conforming to s specific XML schema.
>
> It would be good to get a test in place to exercise this code if it is
> still relevant. I know for sure that neither the unit tests nor the
> CTS exercises it.
>
> This is standard EMF stuff, but I'm not sure whether we ever put it
> to good use in SDO, so all I can do is translate the meaning of the
> code to the best of my understanding, which you may already
> understand anyway.
>
> In an EMF resource set, there can be a set of Factories that know how
> to create java objects from resources. The resource set holds a
> mapping from file extensions for the resources to factories. If a
> request is made to load a resource file with a given extension then
> the map is used to look up the factory that will be used to load the
> resource. There is scope for using wildcards in the file extensions in
> the mapping. If you want to override existing behaviour or add new
> file extensions you can add another factory to the mapping. So here
> the one option that seems to be permitted for this operation is the
> "GENERATED_LOADER" option, for which the value must be a class which
> is a Factory that knows how to load all resources that the resource
> set is going to encounter. A new instance of this factory is created
> and lodged in the resource set's map against the "*" wildcard. So
> whenever the resource set needs to load a resource, the Factory it
> uses to attempt to do the load will always be an instance of the class
> that was provided in the option. If the option is not provided or
> the construction of the specified instance fails then the resource set
> relies on whatever factories if already knew about to create
> resources.
>
> Regards, Kelvin.
>
> -
> 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: How to get an instance of the read composite file ?
Thank You Ant and Luciano ! ... Sam.. On 6/21/07, Luciano Resende <[EMAIL PROTECTED]> wrote: 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] -- Catch Me @: www.samjeyam.co.nr The Engine is the Heart of the Plane but Pilot is the Soul... \___(0)___/ ./ \.
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
The options are moved to lib as well (see org.apache.tuscany.sdo.api.SDOHelper.XMLOptions). Implementation of the options needs to be in the impl project since they have EMF dependencies. Frank. "kelvin goodson" <[EMAIL PROTECTED]> wrote on 06/21/2007 05:23:56 AM: > > > > 2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in > > tuscany-sdo-impl? As this class is > > in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of options > > implementation in tuscany-sdo-impl, > > as these impl classes are not visible in tuscany-sdo-lib. > > > > Frank Budinsky has the reorganisation of code from just the impl > project to an impl/lib split as work in progress [1]. So I guess we > need to understand the reason for having ResolvableImpl in the lib > project. Without deep investigation my guess is that Frank has good > reasons for making the move, so I can see a couple of alternatives, > but I need to gain more insight to know which would be best > > 1) investigate whether the correct home for the options is in the lib project > 2) provide some kind of a mapping of options between the impl layer > and the lib layer > > I think it would be good if you could put down your design ideas or > provide a prototype patch so that I can see the problem for the wider > perspective. > > Regards, Kelvin. > > [1] http://issues.apache.org/jira/browse/TUSCANY-1283 > > - > 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] 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
[
https://issues.apache.org/jira/browse/TUSCANY-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506845
]
Kelvin Goodson commented on TUSCANY-1358:
-
My response to this question is here
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01134.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]
[jira] Commented: (TUSCANY-1359) New SDOUtil: Upper and lower bound on properties where 'isMany' is true
[
https://issues.apache.org/jira/browse/TUSCANY-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506842
]
Kelvin Goodson commented on TUSCANY-1359:
-
getUpperBound() implem is already in SDOHelperImpl, so we simply need to
parallel the changes to SDOHelperImpl, SDOHelper interface and the api variant
of SDOUtil. there is no test on the existing getUpperBound() implem, so we
ought to introduce one for both APIs. It's very simple for someone to
contribute the patch with the changes to the 3 files + a test case, It's just
not top priority for me right now -- might get to it later but can't promise.
> 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]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Jumping to Q7 as I need to do something else now for a while and this is an easy one to answer. The SDOUtil in the impl project is what was being used before Frank started on his improvements to the structure. It still exists in deprecated sate to give people a chance to move over. The impl version simple delegates to the api version now. My feeling is that additions ought only to be added to the lib version. If someone needs to make use of the new feature who is still using the deprecated interface then that might provide the incentive to migrate. Regards, kelvin. 7) Why SDOUtil is lying in tuscany-sdo-impl and is used in many places? Are new changes supposed to be done only in tuscany-sdo-lib/SDOUtil? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
4)To provide code fix, code will change in (this is what I have thought so
far)
*HelperProviderBase->HelperProviderImpl->HelperContextImpl - constructor to
have options,
*XMLHelperImpl-to have member defaultOptions.
*tuscany-sdo-lib -SDOUtil code - SDOUtil.setDefaultXMLOptions(options)
A typical test case will look like -
public void testXMLOptions() throws IOException{
options = new HashMap();
options.put(SDOHelper.XMLOptions.XML_SAVE_LINE_BREAK, new Integer(1));
((HelperProviderBase)HelperProvider.INSTANCE).createDefaultHelpers(options);
XMLHelper xmlHelper =
((HelperProviderBase)HelperProvider.INSTANCE).xmlHelper();
String xml=" " +
"http://www.example.com/simple/>">
" +
"fbnt \n " +
"FlyByNightTechnology " +
"1000.0 " +
"1000.0 " +
"1000.0 " +
"1000.0 " +
"1000.0 " +
"1000.0 " +
" " +
"2000.0 " +
" " +
"";
XMLDocument xmlDoc = xmlHelper.load(new StringReader(xml), null, null);
DataObject root = xmlDoc.getRootObject();
List symbols = root.getList("symbol");
DataObject symbol = (DataObject)symbols.get(0);
String seqValue = (String)symbol.getSequence().getValue(0);
System.out.println("seqValue:"+seqValue+ "done");
System.out.println("index:"+seqValue.indexOf('\n'));
assertEquals(5, seqValue.indexOf('\n'));
}
Your suggestions appear reasonable. It would be easier for me if you
could provide a prototype patch as the basis for discussion then I can
really get to understand and brush up against the problems first hand.
If you have an issue that you can't see a way to resolve you can
provide a patch that clearly states that this is not the solution,
even if it shows compile failures, then I can help you search for the
solution.
Three are some issues with your test code. First off is the way you
access xmlHelper. Best practice is to create a new HelperContext with
the SDOUtil.createHelperContext methods. If you really need to use
the default instances then you use HelperProvide.getDefaultContext().
The other issue is the way you get the symbol value. If you are using
the existing simple.xsd then I think symbol is single valued, so I
think you can just do ...
String symbol = root.getString("symbol");
Kelvin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
3)What is meaning of below code in XMLDocumentImpl?
if (options instanceof Map)
{
Class resourceFactoryClass =
(Class)((Map)options).get("GENERATED_LOADER");
if (resourceFactoryClass != null)
{
try
{
Object resourceFactory = resourceFactoryClass.newInstance();
resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("*",
resourceFactory);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
I looked back at the svn history, and this code has been there since
the original contribution of code to Apache.
My guess from the name of the option and other brushes with topics of
a similar nature is that this allows optimised loads of XML documents
of a specific nature by employing a generated Factory which loads only
documents conforming to s specific XML schema.
It would be good to get a test in place to exercise this code if it is
still relevant. I know for sure that neither the unit tests nor the
CTS exercises it.
This is standard EMF stuff, but I'm not sure whether we ever put it
to good use in SDO, so all I can do is translate the meaning of the
code to the best of my understanding, which you may already
understand anyway.
In an EMF resource set, there can be a set of Factories that know how
to create java objects from resources. The resource set holds a
mapping from file extensions for the resources to factories. If a
request is made to load a resource file with a given extension then
the map is used to look up the factory that will be used to load the
resource. There is scope for using wildcards in the file extensions in
the mapping. If you want to override existing behaviour or add new
file extensions you can add another factory to the mapping. So here
the one option that seems to be permitted for this operation is the
"GENERATED_LOADER" option, for which the value must be a class which
is a Factory that knows how to load all resources that the resource
set is going to encounter. A new instance of this factory is created
and lodged in the resource set's map against the "*" wildcard. So
whenever the resource set needs to load a resource, the Factory it
uses to attempt to do the load will always be an instance of the class
that was provided in the option. If the option is not provided or
the construction of the specified instance fails then the resource set
relies on whatever factories if already knew about to create
resources.
Regards, Kelvin.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in tuscany-sdo-impl? As this class is in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of options implementation in tuscany-sdo-impl, as these impl classes are not visible in tuscany-sdo-lib. Frank Budinsky has the reorganisation of code from just the impl project to an impl/lib split as work in progress [1]. So I guess we need to understand the reason for having ResolvableImpl in the lib project. Without deep investigation my guess is that Frank has good reasons for making the move, so I can see a couple of alternatives, but I need to gain more insight to know which would be best 1) investigate whether the correct home for the options is in the lib project 2) provide some kind of a mapping of options between the impl layer and the lib layer I think it would be good if you could put down your design ideas or provide a prototype patch so that I can see the problem for the wider perspective. Regards, Kelvin. [1] http://issues.apache.org/jira/browse/TUSCANY-1283 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
Hi Nicole, I've inlined some comments below. On 20/06/07, Wengatz, Nicole <[EMAIL PROTECTED]> wrote: 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. I think it would be nice if OSGi didn't have to care how the service was implemented, and this is what can be achieved with SCA. But do we want to have different behaviour for different SCA implementations types? This is exactly what we don't want. The implementation.osgi approach registers in the OSGi registry whatever proxies SCA gives it. These proxies can be for other implementation types or remote bindings. Their behaviour is consistent. 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? We shouldn't have to care. If implementation.ejb/c/.net are supported in the SCA runtime, then we will get these for free. It's up to SCA to give us the right proxy which we then make available in the OSGi registry. I still think that explicit bindings are better. I still think both approaches are valid and it depends on what you're trying to achieve :-) . If you're trying to include OSGi bundles in your SCA domain, the only way to do this is with implementation.osgi. If you're trying to create a peer environment where you interoperate with OSGi bundles but they are not managed by SCA, then binding.osgi makes sense. 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 :-) Yes, I am. I look forward to meeting you there too :-) . -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: > > > > > RetailerComponent > > > > > 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: > > > RetailerService > > > > > > > > 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 pro
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Amita, I'm going to tackle your questions 1 by 1 On 19/06/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: Hi, In attempt to analyze JIRA-1317, I had some questions and would like to get some points clear. 1)Tuscany xmlHelperImpl have load() method where options can be passed in. Why save() methods with XMLDocument only have options supported and not for save() methods with DataObject? So I think here you are referring to a perceived asymmetry in the XMLHelper interfaces. This is a spec issue and I don't have the background to that. I'd like to investigate more, but I got the feeling that form the little bit of the IRC chat that was successful that this was more a curiosity for you. So perhaps we can take this one later, or you can ask the spec group. Response to Q2 coming up ... hope it has more content ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Hi Amita, I think we must resort to the mailing list since IRC is
failing us, so I'm going to work through the issues and post here as I
go. It won't be as interactive as IRC ought to be, but it will be
better than the reality of IRC :-(
Regards, kelvin.
On 21/06/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
Some more questions-
8) are these the only ones? what should be int value to make it ON/OFF?
currently no matter what it is ON, like I put a \n in a attribute value and
loaded in DO and checked
the value there, it was always preserving \n
/**
* Line Break String such as "\n", "\r\n", "\r" and "", absence/null is
the default (line.separator System Property)
*/
final String XML_SAVE_LINE_BREAK = "LineBreak";
/**
* Indent String such as "\t", "", etc. absence/null is the default ("
")
*/
final String XML_SAVE_INDENT = "indent";
/**
* Margin String such as " ", "\t\t", etc. Absence/null/"" is the
default (no margin)
*/
final String XML_SAVE_MARGIN = "margin";
/**
* Attribute formatting that exceeds the specified width as Integer will
cause a line break so that formatting will continue indented on the next
line
*/
final String XML_SAVE_LINE_WIDTH = "LINE_WIDTH";
/**
* Boolean to save a doctype declaration
*/
final String XML_SAVE_DOCTYPE = "SAVE_DOCTYPE";
/**
* Boolean to process the schemaLocation/noNamespaceSchemaLocation
attributes occurring in the instance document to [EMAIL PROTECTED]
XSDHelper#define
convert XSD(s) to Types}
*/
final String XML_LOAD_SCHEMA = "ProcessSchemaLocations";
/**
* To tolerate malformed elements and attributes (default unless set by
System property XML.load.form.lax). 0 not to.
*/
final String XML_LOAD_LAX_FORM = "load malform";
Regards,
Amita
On 6/19/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
>
> Hi,
> In attempt to analyze JIRA-1317, I had some questions and would like to
> get some
> points clear.
>
> 1)Tuscany xmlHelperImpl have load() method where options can be passed in.
> Why save() methods with
> XMLDocument only have options supported and not for save() methods with
> DataObject?
>
> 2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in
> tuscany-sdo-impl? As this class is
> in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of
> options implementation in tuscany-sdo-impl,
> as these impl classes are not visible in tuscany-sdo-lib.
>
> 3)What is meaning of below code in XMLDocumentImpl?
> if (options instanceof Map)
> {
> Class resourceFactoryClass =
> (Class)((Map)options).get("GENERATED_LOADER");
> if (resourceFactoryClass != null)
> {
> try
> {
> Object resourceFactory = resourceFactoryClass.newInstance();
>
resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("*",
> resourceFactory);
> }
> catch (Exception e)
> {
> e.printStackTrace();
> }
> }
> }
> 4)To provide code fix, code will change in (this is what I have thought so
> far)
> *HelperProviderBase->HelperProviderImpl->HelperContextImpl - constructor
> to have options,
> *XMLHelperImpl-to have member defaultOptions.
> *tuscany-sdo-lib -SDOUtil code - SDOUtil.setDefaultXMLOptions(options)
>
> A typical test case will look like -
> public void testXMLOptions() throws IOException{
> options = new HashMap();
> options.put(SDOHelper.XMLOptions.XML_SAVE_LINE_BREAK, new
> Integer(1));
>
> ((HelperProviderBase)HelperProvider.INSTANCE).createDefaultHelpers(options);
>
>
> XMLHelper xmlHelper =
> ((HelperProviderBase)HelperProvider.INSTANCE).xmlHelper();
>
> String xml=" " +
> "http://www.example.com/simple/>">
> " +
> "fbnt \n " +
> "FlyByNightTechnology " +
> "1000.0 " +
> "1000.0 " +
> "1000.0 " +
> "1000.0 " +
> "1000.0 " +
> "1000.0 " +
> " " +
> "2000.0 " +
> " " +
> "";
>
> XMLDocument xmlDoc = xmlHelper.load(new StringReader(xml), null,
> null);
> DataObject root = xmlDoc.getRootObject ();
> List symbols = root.getList("symbol");
> DataObject symbol = (DataObject)symbols.get(0);
> String seqValue = (String)symbol.getSequence().getValue(0);
> System.out.println("seqValue:"+seqValue+ "done");
> System.out.println("index:"+seqValue.indexOf('\n'));
> assertEquals(5, seqValue.indexOf('\n'));
> }
> 5)When providing fix for this JIRA, when caller to load/save provides
> options, these will override defaultOptions from XMLHelperImpl
>
> 6) What is being done in SDOXMLResourceImpl? How options are processed
> here?
>
> 7) Why SDOUtil is lying in tuscany-sdo-impl and is used in many places?
> Are new changes
> supposed to be done only in tuscany-sdo-lib/SDOUtil?
>
> Please let me know some details for above and I will be happy to ask more
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Some more questions-
8) are these the only ones? what should be int value to make it ON/OFF?
currently no matter what it is ON, like I put a \n in a attribute value and
loaded in DO and checked
the value there, it was always preserving \n
/**
* Line Break String such as "\n", "\r\n", "\r" and "", absence/null is
the default (line.separator System Property)
*/
final String XML_SAVE_LINE_BREAK = "LineBreak";
/**
* Indent String such as "\t", "", etc. absence/null is the default ("
")
*/
final String XML_SAVE_INDENT = "indent";
/**
* Margin String such as " ", "\t\t", etc. Absence/null/"" is the
default (no margin)
*/
final String XML_SAVE_MARGIN = "margin";
/**
* Attribute formatting that exceeds the specified width as Integer will
cause a line break so that formatting will continue indented on the next
line
*/
final String XML_SAVE_LINE_WIDTH = "LINE_WIDTH";
/**
* Boolean to save a doctype declaration
*/
final String XML_SAVE_DOCTYPE = "SAVE_DOCTYPE";
/**
* Boolean to process the schemaLocation/noNamespaceSchemaLocation
attributes occurring in the instance document to [EMAIL PROTECTED]
XSDHelper#define
convert XSD(s) to Types}
*/
final String XML_LOAD_SCHEMA = "ProcessSchemaLocations";
/**
* To tolerate malformed elements and attributes (default unless set by
System property XML.load.form.lax). 0 not to.
*/
final String XML_LOAD_LAX_FORM = "load malform";
Regards,
Amita
On 6/19/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
Hi,
In attempt to analyze JIRA-1317, I had some questions and would like to
get some
points clear.
1)Tuscany xmlHelperImpl have load() method where options can be passed in.
Why save() methods with
XMLDocument only have options supported and not for save() methods with
DataObject?
2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in
tuscany-sdo-impl? As this class is
in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of
options implementation in tuscany-sdo-impl,
as these impl classes are not visible in tuscany-sdo-lib.
3)What is meaning of below code in XMLDocumentImpl?
if (options instanceof Map)
{
Class resourceFactoryClass =
(Class)((Map)options).get("GENERATED_LOADER");
if (resourceFactoryClass != null)
{
try
{
Object resourceFactory = resourceFactoryClass.newInstance();
resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("*",
resourceFactory);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
4)To provide code fix, code will change in (this is what I have thought so
far)
*HelperProviderBase->HelperProviderImpl->HelperContextImpl - constructor
to have options,
*XMLHelperImpl-to have member defaultOptions.
*tuscany-sdo-lib -SDOUtil code - SDOUtil.setDefaultXMLOptions(options)
A typical test case will look like -
public void testXMLOptions() throws IOException{
options = new HashMap();
options.put(SDOHelper.XMLOptions.XML_SAVE_LINE_BREAK, new
Integer(1));
((HelperProviderBase)HelperProvider.INSTANCE).createDefaultHelpers(options);
XMLHelper xmlHelper =
((HelperProviderBase)HelperProvider.INSTANCE).xmlHelper();
String xml=" " +
"http://www.example.com/simple/>">
" +
"fbnt \n " +
"FlyByNightTechnology " +
"1000.0 " +
"1000.0 " +
"1000.0 " +
"1000.0 " +
"1000.0 " +
"1000.0 " +
" " +
"2000.0 " +
" " +
"";
XMLDocument xmlDoc = xmlHelper.load(new StringReader(xml), null,
null);
DataObject root = xmlDoc.getRootObject ();
List symbols = root.getList("symbol");
DataObject symbol = (DataObject)symbols.get(0);
String seqValue = (String)symbol.getSequence().getValue(0);
System.out.println("seqValue:"+seqValue+ "done");
System.out.println("index:"+seqValue.indexOf('\n'));
assertEquals(5, seqValue.indexOf('\n'));
}
5)When providing fix for this JIRA, when caller to load/save provides
options, these will override defaultOptions from XMLHelperImpl
6) What is being done in SDOXMLResourceImpl? How options are processed
here?
7) Why SDOUtil is lying in tuscany-sdo-impl and is used in many places?
Are new changes
supposed to be done only in tuscany-sdo-lib/SDOUtil?
Please let me know some details for above and I will be happy to ask more
questions :)
Regards,
Amita
[jira] Commented: (TUSCANY-1363) Initial implementation of OSGi Implementation type for Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506790 ] Rajini Sivaram commented on TUSCANY-1363: - Ant, Thank you very much. I wasn't expecting it to be added so quickly! - Rajini > 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]
