Re: [C++] Design of SCA and SDO public API classes
OK, so if we dont deal with exception hiding, the two are:
Employee employee = someSDOmethod_returningMyTypesafeDO();
cout << employee->getName() << endl;
DataObjectPtr employee = someSDOmethod_returningAnSDO();
cout << employee->getString("name") << endl;
..so Im not sure that type safety really increases maintainability that
much that a developer would be willing to introduce a custom step into the
build process, and maintain generated code with all the resulting issues of
upward compatibility, debugging code you didn't write, getting inevitable
bugs fixed in the generator in a timely way etc.
Im not saying typesafe is wrong, I just dont want to see it developed in the
C++ world because its cool in the java world.
Theres no design for it yet - but maybe the value in doing it will become
clearer to me if we start discussing that amongst the community.
On 15/08/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
On 15/08/06, Edward Slattery <[EMAIL PROTECTED]> wrote:
>
>
> This leads to a question which should be asked.
>
> If the MyDataObject contains a DataObject, and all typesafe calls such
as
> getName() are in fact delegated via
containedobject->getString("name")...
> what has type safety actually gained us? We had to do a codegen to
> generate
> the wrapper class, the calls are no more efficient than the dynamic API.
> All
> we really gain is the ability for the compiler to grumble if we type
> getNome() instead of getName() in our user program.
> For the sake of an aditional set of tooling to be run prior to
> compilation,
> and probably a set of integration tools to make that work from DevStudio
> as
> a pre-build step, and Eclipse etc - is the benefit worth the work? What
do
> the C++ community feel?
The benefit is simplification of the programming for the end user. It is a
lot cleaner and more maintainable to code
Employee employee = someSDOmethod_returningMyTypesafeDO();
cout << employee.getName() << endl;
than
DataObjectPtr employee = someSDOmethod_returningDOPtr();
try
{
if (employee != NULL)
{
cout << employee->getString("name") << endl;
}
}
catch (SDORuntimeException &e)
{
}
OK... I've assumed the exception handling is in the static SDO methods but
even so you can see what I'm getting at. Maybe we need a thread on what
TypeSafe SDO means for C++. Is there a spec/design?
Cheers,
--
Pete
Re: [C++] Design of SCA and SDO public API classes
Im not saying that inheritance wouldnt work in SCA - it probably would.
The issue we ran into with SDO was that we have built a system in which the
class which is visible to the user of the library is DataObject, they can
only work with that API, and dont know about DataObjectImpls. What they are
given when they create a DataObject is a DataObjectPtr - which looks like a
pointer to a DataObject to them, but is in reality a pointer to a
DataObjectImpl, so that when they call methods on it - the DataObjectImpl
does the work. (DataObject is pure abstract).
Now, in C++, extensions to the DataObject, such as a typesafe API for a
specific type of DataObject, cannot be included in the sdo library, which is
a binary, so the only option is that the user uses the exposed API of the
library in some way. If this way were to be inheritance from the only object
they can see (DataObject), then they would have to implement all the
abstract methods getInteger, getBoolean etc themselves, as these are only
implemented in DataObjectImpl.
The other solution is containment, where they get a DataObject from the sdo
library, and include it in their typesafe "MyDataObject", then delegate all
incoming calls to getInteger etc to the contained object. (This contained
object will in reality be a DataObjectImpl).
This leads to a question which should be asked.
If the MyDataObject contains a DataObject, and all typesafe calls such as
getName() are in fact delegated via containedobject->getString("name")...
what has type safety actually gained us? We had to do a codegen to generate
the wrapper class, the calls are no more efficient than the dynamic API. All
we really gain is the ability for the compiler to grumble if we type
getNome() instead of getName() in our user program.
For the sake of an aditional set of tooling to be run prior to compilation,
and probably a set of integration tools to make that work from DevStudio as
a pre-build step, and Eclipse etc - is the benefit worth the work? What do
the C++ community feel?
On 15/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Edward Slattery wrote:
[snip]
> In the case of SDO, it was just the logical pattern for implementation
> hiding.
>
> The implementation was fine up to the point where we wanted to start
> thinking about
> the static SDO api, and were proposing to allow code generators to
> inherit
> from some DataObject base class and add their own methods such as
> "getName()" etc.
>
> We cant do that with DataObject, as all the DataObject pointers given
out
> are really
> DataObjectImpls. The prototype code I put in the test directory uses
> containment instead
> of inheritance to allow a MyDataObject to contain a reference to a
> DataObject, and delegate
> its DataObjectish behaviour.
>
> cheers,
> Ed.
>
Just to confirm I understand this correctly:
Are you saying that inheritance was the logical pattern for
implementation hiding in SDO?
But then this caused a problem for generated code? Can you describe the
problem with having the pointers inherit from DataObjectImpl vs contain
a DataObjectImpl?
Also if inheritance was the logical pattern for implementation hiding in
SDO, why wouldn't it work the same way for SCA?
Maybe I'm missing something but I'm not seeing why inheritance would not
work for ComponentContext as well. Could you please explain?
Thanks,
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Design of SCA and SDO public API classes
In the case of SDO, it was just the logical pattern for implementation hiding. The implementation was fine up to the point where we wanted to start thinking about the static SDO api, and were proposing to allow code generators to inherit from some DataObject base class and add their own methods such as "getName()" etc. We cant do that with DataObject, as all the DataObject pointers given out are really DataObjectImpls. The prototype code I put in the test directory uses containment instead of inheritance to allow a MyDataObject to contain a reference to a DataObject, and delegate its DataObjectish behaviour. cheers, Ed. On 11/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I noticed two different patterns in the definition of the public SCA and SDO API classes. SCA: A delegation pattern where the public API class delegates calls to an implementation class. For example ComponentContext contains a private pointer to ComponentContextImpl. ComponentContextImpl implements the methods from ComponentContext but does not extend ComponentContext. SDO: Inheritance, where the implementation class extends the public API class. For example DataFactoryImpl extends DataFactory. Is there any particular reason for the two different patterns? Any advantages or issues with one compared the other? A related question. What do you think about reorganizing the folder structure a little to clearly separate the spec includes from the implementation specific ones? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Do we need SDO annotations in the SCDL XSDs?
Yes, the SDO Xpath support was always one of those 'must rewrite when theres
time' items.
It doesnt support dots in property names, as it uses the "." or a "[" to
indicate that the property being referenced is a many-valued property and
must be accessed via getList, using the index following the "." or "[".
I guess a better solution would be to take the element of the path between
path separators, and first validate whether the element is an expected
property of the current object. If it is just use it, otherwise see of the
last lump of the element is an index, and try again with the remainder of
the element.
It would be interesting to see what the current java implementation makes
of:
data object type bar
{
property fred - type DataObject.
}
data object type foo
{
property "a.property.name" - many valued data object of type bar
property "a.property.name.1" - single valued data object
}
foo->getDataObject("a.property.name.2"); // getting from the array
foo->getDataObject("a.property.name.1"); // getting from the single value
foo->getDataObject("a.property.name.1/fred"); // getting from element 1 of
the array
BTW - in terms of 'special characters' I assumed it meant path separators -
I guess theres no requirement to have a property name like "this/property"?
cheers,
Ed.
On 09/08/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
Good! because the SDO XPath code looks a bit messy :-(
Cheers,
On 09/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Jean-Sebastien Delfino wrote:
> > Pete Robbins wrote:
> >> I'll take a look at the XPath stuff in SDO and see if we can avoid
the
> >> annotations for the new assembly model schema. It may not be simple
> >> so we
> >> may have to annotate the schema to start with and fix this later.
> >>
> >> Cheers,
> >>
> >
> > OK, let me know. If it turns out that we need the annotations to start
> > with as a workaround to this issue with dots, then no problem I'll add
> > them. Thanks.
> >
>
> Interesting how sometimes expected design issues turn into non-issues
> once you actually write code :) I tried to use the XSDs without
> annotations, and... everything works!
>
> This is because the ModelLoader works with the base XSD complex types
> and substitution groups, which contain no dots in their names. We never
> do DataObject.get("interface.cpp") for example, we only do
> DataObject.get("interface")... So there was no problem after all :) we
> don't need any annotations in the SCDL XSDs.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Pete
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
Ive tested the vc7 and vc6 builds in debug and release modes. All works fine except three minor points which have been raised as JIRAs: 1) The Calculator in vc6 debug mode builds Calc.exe - should be Client.exe 2) The Calculator in vc7 debug builds Client.exe, but Calc.pdb - should be Client.pdb 3) The deploy and wsdeploy batch files for Calculator in vc7 and vc6 need a dot moved in the line: "if .Debug == %1." to "if Debug. == %1." Otherwise the deploy always copies the Release Dll, not the Debug dll. I think these are all trivial problems with easy solutions and the JIRAs describe the solutions, so I give this candidate a +1 On 19/07/06, Andrew Borley <[EMAIL PROTECTED]> wrote: Just tested the binaries on WinXP and Fedora Core1. All happy. +1 for release Andy On 7/18/06, David Wheeler <[EMAIL PROTECTED]> wrote: > > I just installed the linux binary version onto ubuntu 6. > Calculator sample works fine. > > -David Wheeler > > On 7/18/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > I have refreshed the distros. Please vote on the release candidate > > available > > here: http://people.apache.org/~robbinspg/RC-3b > > > > Apologies for any inconvenience. > > > > Cheers, > > > > -- > > Pete > > > > > >
Re: Fix for an alloc problem in tuscany_sdo_test
It does help , thanks a lot - fix applied. On 18/07/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Hi, I'm running into a problem with the tuscany_sdo_test from the SVN head, which fails for me on Linux with the following error: I/O warning : failed to load external entity "not_present.xsd" I/O warning : failed to load external entity "not-present.xml" I/O warning : failed to load external entity "sca-policy.xsd" I/O warning : failed to load external entity "sca-policy.xsd" I/O warning : failed to load external entity "sca-policy.xsd" I/O warning : failed to load external entity "sca-policy.xsd" I/O warning : failed to load external entity "sca-policy.xsd" I/O warning : failed to load external entity "sca-policy.xsd" I/O warning : failed to load external entity "sca-policy.xsd" I/O warning : failed to load external entity "sca-policy.xsd" I/O warning : failed to load external entity "sca-policy.xsd" terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc Aborted The problem only occurs on Linux. Line 3144 of TypeImpl.cpp tries to allocate an array and the length is not initialized / high value. This code is in an #ifdef !Windows, so the problem doesn't occur on Windows. Here's the stack trace: Thread [1] (Suspended: Signal 'SIGABRT' received. Description: Aborted.) 15 _dl_sysinfo_int80() 0x0085f7a2 14 raise() 0x0089f7f5 13 abort() 0x008a1199 12 __gnu_cxx::__verbose_terminate_handler() 0x0049125b 11 __cxa_call_unexpected() 0x0048ef71 10 std::terminate() 0x0048efa6 9 __cxa_throw() 0x0048f0ef 8 operator new() 0x0048f53c 7 operator new[]() 0x0048f5d9 6 commonj::sdo::TypeImpl::convertToInteger() at TypeImpl.cpp:3144 0xb7fc6b49 5 commonj::sdo::Setting::getIntegerValue() at Setting.cpp:234 0xb7fc119c 4 sdotest::printOldValues() at utils.cpp:73 0x0807c6a2 3 sdotest::dumpchangesummary() at utils.cpp:416 0x0807cca4 2 sdotest::setnull() at sdotest.cpp:5998 0x080635fd 1 main() at main.cpp:120 0x0807d2bb I spent some time debugging it... and found the issue in ChangeSummaryImpl.cpp, easy to fix by initializing a len local variable to 0. Here's the patch: Index: ChangeSummaryImpl.cpp === --- ChangeSummaryImpl.cpp (revision 422962) +++ ChangeSummaryImpl.cpp (working copy) @@ -756,7 +756,7 @@ CREATELOG_MAP::iterator createLogIter; -unsigned int len; +unsigned int len = 0; createLogIter = createdMap.find(ob); if (createLogIter != createdMap.end()) With this patch tuscany_sdo_test successfully runs for me. Hope this helps... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany C++ Milestone 1
I should add that the problem only occurs in the release build of Calculator, not the Debug build, and is specific to VC6 , not VC7. probably worth documenting but not a showstopper. On 12/07/06, Edward Slattery <[EMAIL PROTECTED]> wrote: And thatll teach me! The VC6 build of Calculator still has a couple of problems - mainly the Input for libs and the include path are not right. Ive put them right and checked in the changes. Hope that helps. On 12/07/06, Edward Slattery <[EMAIL PROTECTED]> wrote: > > I have tried the command line, windows vc6 and windows vc7 in both > release and debug mode. This one works for me! > +1 > > > On 12/07/06, Brent Daniel <[EMAIL PROTECTED] > wrote: > > > > FYI, I took a quick look at this today and was able to run through the > > setup and samples for the windows binary distribution without any > > problems. > > > > Brent > > > > > > On 7/12/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > I have posted a 2nd candidate for the first C++ release here: > > > http://people.apache.org/~robbinspg/RC-2 > > > > > > > > > Please vote to publish the Milestone 1 release distributions. Please > > > take some time to download the distributions, review them and test > > them > > > in your environment before voting. > > > > > > The vote is open for at least the next 72 hours. > > > At least three +1 votes are required, and only the votes from > > > Tuscany committers are binding. If the majority of all votes is > > > positive, I will send a summary of that vote to the Incubator's > > general > > > list to formally request the Incubator PMC to approve the Tuscany > > C++ > > > Milestone 1 release. For your reference the Incubator release policy > > > > > guidelines are available at > > > > > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > > . > > > > > > > > > > > > Release Summary > > > = > > > > > > Tuscany SCA C++ provides a runtime implementation for the Service > > Component > > > Architecture 0.9 specification, written in C++ and will currently > > support > > > C++ > > > component implementation types. This is not yet a complete > > implementation > > > and > > > known restrictions are described below. > > > > > > Supported SCA Assembly Model features > > > * All features are supported unless listed under the known > > restrictions > > > below. See SCA Assembly Model specification. > > > > > > Supported language bindings > > > * Component implementations written in C++. See SCA Client and > > >Implementation Model specification. > > > * Component interfaces described by C++ classes. See SCA Client and > > >Implementation Model specification. > > > > > > Supported external service and entry point bindings > > > * The web service binding is supported. This implementation will > > support > > >web services which using document literal SOAP bindings > > conforming to > > > the > > >WS-I basic profile (rpc/encoded is not yet supported). > > > > > > Known restrictions > > > * Subsystem: wiring, entry points and external services are not > > supported. > > > * Local service interfaces cannot use overloaded operations (the > > SCA > > >specification limits remote service interfaces to not using > > > overloaded operations). > > > * Each WSDL definition for a web service binding must be in a > > single WSDL > > > document. > > > * No load time validation of the deployed SCA application (run time > > > > > validation only). > > > * No metadata API. > > > > > > A sample is included which demonstrates deploying an SCA module, > > component > > > wiring, locating and invoking C++ service from C++ > > component, invoking from > > > a C++ client, and exposing a service as a web service using ws > > binding. > > > > > > > > > Cheers, > > > > > > > > > -- > > > Pete > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
Re: [VOTE] Release Tuscany C++ Milestone 1
And thatll teach me! The VC6 build of Calculator still has a couple of problems - mainly the Input for libs and the include path are not right. Ive put them right and checked in the changes. Hope that helps. On 12/07/06, Edward Slattery <[EMAIL PROTECTED]> wrote: I have tried the command line, windows vc6 and windows vc7 in both release and debug mode. This one works for me! +1 On 12/07/06, Brent Daniel <[EMAIL PROTECTED]> wrote: > > FYI, I took a quick look at this today and was able to run through the > setup and samples for the windows binary distribution without any > problems. > > Brent > > > On 7/12/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > I have posted a 2nd candidate for the first C++ release here: > > http://people.apache.org/~robbinspg/RC-2 > > > > > > Please vote to publish the Milestone 1 release distributions. Please > > take some time to download the distributions, review them and test > them > > in your environment before voting. > > > > The vote is open for at least the next 72 hours. > > At least three +1 votes are required, and only the votes from > > Tuscany committers are binding. If the majority of all votes is > > positive, I will send a summary of that vote to the Incubator's > general > > list to formally request the Incubator PMC to approve the Tuscany C++ > > Milestone 1 release. For your reference the Incubator release policy > > guidelines are available at > > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > . > > > > > > > > Release Summary > > = > > > > Tuscany SCA C++ provides a runtime implementation for the Service > Component > > Architecture 0.9 specification, written in C++ and will currently > support > > C++ > > component implementation types. This is not yet a complete > implementation > > and > > known restrictions are described below. > > > > Supported SCA Assembly Model features > > * All features are supported unless listed under the known > restrictions > > below. See SCA Assembly Model specification. > > > > Supported language bindings > > * Component implementations written in C++. See SCA Client and > >Implementation Model specification. > > * Component interfaces described by C++ classes. See SCA Client and > >Implementation Model specification. > > > > Supported external service and entry point bindings > > * The web service binding is supported. This implementation will > support > >web services which using document literal SOAP bindings conforming > to > > the > >WS-I basic profile (rpc/encoded is not yet supported). > > > > Known restrictions > > * Subsystem: wiring, entry points and external services are not > supported. > > * Local service interfaces cannot use overloaded operations (the SCA > >specification limits remote service interfaces to not using > > overloaded operations). > > * Each WSDL definition for a web service binding must be in a single > WSDL > > document. > > * No load time validation of the deployed SCA application (run time > > validation only). > > * No metadata API. > > > > A sample is included which demonstrates deploying an SCA module, > component > > wiring, locating and invoking C++ service from C++ > component, invoking from > > a C++ client, and exposing a service as a web service using ws > binding. > > > > > > Cheers, > > > > > > -- > > Pete > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Release Tuscany C++ Milestone 1
I have tried the command line, windows vc6 and windows vc7 in both release and debug mode. This one works for me! +1 On 12/07/06, Brent Daniel <[EMAIL PROTECTED]> wrote: FYI, I took a quick look at this today and was able to run through the setup and samples for the windows binary distribution without any problems. Brent On 7/12/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > I have posted a 2nd candidate for the first C++ release here: > http://people.apache.org/~robbinspg/RC-2 > > > Please vote to publish the Milestone 1 release distributions. Please > take some time to download the distributions, review them and test them > in your environment before voting. > > The vote is open for at least the next 72 hours. > At least three +1 votes are required, and only the votes from > Tuscany committers are binding. If the majority of all votes is > positive, I will send a summary of that vote to the Incubator's general > list to formally request the Incubator PMC to approve the Tuscany C++ > Milestone 1 release. For your reference the Incubator release policy > guidelines are available at > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases. > > > > Release Summary > = > > Tuscany SCA C++ provides a runtime implementation for the Service Component > Architecture 0.9 specification, written in C++ and will currently support > C++ > component implementation types. This is not yet a complete implementation > and > known restrictions are described below. > > Supported SCA Assembly Model features > * All features are supported unless listed under the known restrictions > below. See SCA Assembly Model specification. > > Supported language bindings > * Component implementations written in C++. See SCA Client and >Implementation Model specification. > * Component interfaces described by C++ classes. See SCA Client and >Implementation Model specification. > > Supported external service and entry point bindings > * The web service binding is supported. This implementation will support >web services which using document literal SOAP bindings conforming to > the >WS-I basic profile (rpc/encoded is not yet supported). > > Known restrictions > * Subsystem: wiring, entry points and external services are not supported. > * Local service interfaces cannot use overloaded operations (the SCA >specification limits remote service interfaces to not using > overloaded operations). > * Each WSDL definition for a web service binding must be in a single WSDL > document. > * No load time validation of the deployed SCA application (run time > validation only). > * No metadata API. > > A sample is included which demonstrates deploying an SCA module, component > wiring, locating and invoking C++ service from C++ component, invoking from > a C++ client, and exposing a service as a web service using ws binding. > > > Cheers, > > > -- > Pete > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clickable SCA Composite Diagram
I can get to the wiki page, but any click on anything gives "page not found". Am I missing something? The wiki page: http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca.htm The page under "service": http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca-service.htm - gives a page not found. On 11/07/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote: Raymond-- The Apache mail system is quite paranoid when it comes to accepting types of attachments. Typically, only text files pass through the filters. The best bet for attaching files for everyone is to put them on the wiki (which you did, thanks!) or to attach them to a JIRA issue. Hope that helps. Eddie On 7/10/06, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > It seems that even HTML and JPEG files cannot be attached. > > Here's the wiki page: > > http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca.htm > http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca_composite.jpg > > Thanks, > Raymond > > - Original Message - > From: "haleh mahbod" <[EMAIL PROTECTED]> > To: > Sent: Monday, July 10, 2006 6:05 PM > Subject: Re: Clickable SCA Composite Diagram > > > > where is it? > > > > On 7/10/06, Raymond Feng <[EMAIL PROTECTED]> wrote: > >> > >> Hi, > >> > >> Here's a draft clickable diagram to illustrate the concepts for SCA > >> composite. Multiple areas are defined with hyperlinks on the image. > >> Please > >> give a try to see if it's what we want on the web site. > >> > >> Thanks, > >> Raymond > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++ SDO] Results from PHP testing
thankyou for that. The crash is something which we need to fix, and I will apply your change asap. I guess it probably wouldnt stop a release, but if we are re-spinning for any other reason I will make sure its in there. I think with the SDOString it was intended that we put in place a cast operator so that current users of the const char* would be unaffected. Would you consider directly casting the value to a (const char*) as an acceptable alternative? You are right, I forgot to update the release version number - and it should be updated with the SDOString stuff . Will update that at the same time. cheers, Ed. On 10/07/06, Caroline Maynard <[EMAIL PROTECTED]> wrote: I tried building the M1 candidate in the PHP environment on Windows, with the following observations and issues: One backward-compatibility compilation problem: Type::SDOTypeNamespaceURI has been changed from a const char * to a const SDOString. This is easy enough to program round, but it seems unnecessary. Can this be reversed? One crash: See http://issues.apache.org/jira/browse/TUSCANY-529 One infrastructure comment: the runtime version is declared as 0.9.3, and has been for rather a long time. Shouldn't this be updated more regularly, in particular whenever API incompatibilities are introduced? This would make it easier to manage the code. Once I'd bypassed the two problems above, the PHP tests ran through OK, so it's looking promising. Now for some more platforms - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] binary release debug?
OK, lets pray for no optimiser bugs - I will be running the tests as soon as you say youve done it. cheers, Ed. On 10/07/06, Andrew Borley <[EMAIL PROTECTED]> wrote: +1 on this from me. Current bin distro doesn't work for me cause I've got MSVS 7.0 instead of 6 Andy On 7/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > I am going to change the windows binary distribution to a "Release" build > rather than "Debug" The MS debug dlls may not be available for all users. > > A debug build will still be possible using the source release. > > -- > Pete > > -- Cheers, Andrew Borley
Re: C++ can't get Calculator sample to run
Not sure I agree with that. The dlls appear in the bin directory - thats what is required on the PATH. Also, Im using libxml 2.6.19, I wonder if that makes a difference - you wouldnt think so Do you have iconv.dll on your path somewhere too? cheers, Ed. On 10/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote: It's actually %TUSCANY_SCACPP%\lib;%TUSCANY_SDOCPP%\lib that you need on the path, not the "bin"s. Another mistake in the instrcutions! Cheers, On 10/07/06, Luciano Resende <[EMAIL PROTECTED]> wrote: > > I have the following bat file to setup the environment : > > REM set SVN_HOME to the full path of where Subversion was installed > set SVN_HOME=D:\Opensource\svn-win32-1.3.1 > > SET AXIS2C_HOME=D:\Opensource\axis2c-bin-0.92-win32 > SET PATH=%PATH%;%AXIS2C_HOME%\bin;%AXIS2C_HOME%\lib > > SET LIBXML2_INCLUDE=D:\Opensource\libxml2-2.6.20.win32\include > SET LIBXML2_LIB=D:\Opensource\libxml2-2.6.20.win32\lib > > SET > > TUSCANY_SCACPP_SYSTEM_ROOT=D:\DEV\Projects\Tuscany\Releases\tuscany_sca_cpp- > 0.1.incubating-M1-bin > SET TUSCANY_SCACPP=D:\DEV\Projects\Tuscany\Releases\tuscany_sca_cpp- > 0.1.incubating-M1-bin > SET TUSCANY_SDOCPP=D:\DEV\Projects\Tuscany\Releases\tuscany_sdo_cpp- > 0.1.incubating-M1-bin > > > SET PATH=%PATH%;%SVN_HOME%\bin;%TUSCANY_SCACPP%\bin;%TUSCANY_SDOCPP%\bin > echo. > echo checking SVN > svn --version > echo. > > Hope this helps you get further... > > - Luciano > > > On 7/9/06, ant elder <[EMAIL PROTECTED]> wrote: > > > > I'm still not getting passed this error. I've tried the versions you > have > > below (which version to use isn't very clear in the INSTALL doc), but > > still > > get the xmlTextReaderConstEncoding could not be located error. Could you > > list out exactly what environment variables I should have set and what > > should be in my PATH? > > > >...ant > > > > On 7/8/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > > > Axis2\lib should definitely be on the path. Do you have libxml2 on > your > > > path? On wiindows you also need iconv and zlib on the path. Here'w > what > > > the > > > Axis2C doc says: > > > > > > You also need the following dlls > > > > > >- libxml2.dll [http://www.xmlsoft.org - download the version >= > > >libxml2-2.6.20.win32] > > >- iconv.dll [http://www.xmlsoft.org - download the version >= > > >iconv-1.9.1.win32] > > >- zlib1.dll [http://www.xmlsoft.org - download the version >= > > >zlib-1.2.3.win32] > > > > > > axis2c and sdo prereq these. I need to add these to the SCA doc that > > > pre-reqs axis2c and SDO! > > > > > > Cheers, > > > > > > > > > > > > On 08/07/06, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > > > I've tried following the instructions in the Calculator sample > INSTALL > > > doc > > > > and get an error in a popup window saying: > > > > > > > > This application has failed to start because axis2_engine.dll was > not > > > > found > > > > > > > > The output at the command prompt is: > > > > > > > > C:\SCA\Dist\Cpp\tuscany_sca_cpp- > > > > 0.1.incubating-M1-bin\samples\Calculator\deploy\bin> runclient.cmdadd > > 5 > > > 6 > > > > using Axis2C: C:\SCA\Dist\Cpp\axis2c-bin-0.92-win32" > > > > using TUSCANY_SDOCPP: C:\SCA\Dist\Cpp\tuscany_sdo_cpp- > > > > 0.1.incubating-M1-bin > > > > using TUSCANY_SCACPP: C:\SCA\Dist\Cpp\tuscany_sca_cpp- > > > > 0.1.incubating-M1-bin > > > > > > > > > > > > I tried adding the Axis2 lib dir to the PATH and then get a > different > > > > popup > > > > window error saying: > > > > > > > > The procedure entry point xmlTextReaderConstEncoding could not be > > > located > > > > in > > > > the dynamic link library libxml2.dll > > > > > > > > What am I doing wrong? > > > > > > > > Thanks, > > > > > > > > ...ant > > > > > > > > > > > > > > > > > -- > > > Pete > > > > > > > > > > > > > -- > Regards > > Luciano Resende > > -- Pete
Re: C++ can't get Calculator sample to run
Possibly the fact that it says it cant find an entrypoint would indicate that the libxml2 it is finding is not the right one, or maybe it cant find iconv.dll which provides the encodings. I thought we didnt rely in encodings yet, but maybe we do. On 08/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote: Axis2\lib should definitely be on the path. Do you have libxml2 on your path? On wiindows you also need iconv and zlib on the path. Here'w what the Axis2C doc says: You also need the following dlls - libxml2.dll [http://www.xmlsoft.org - download the version >= libxml2-2.6.20.win32] - iconv.dll [http://www.xmlsoft.org - download the version >= iconv-1.9.1.win32] - zlib1.dll [http://www.xmlsoft.org - download the version >= zlib-1.2.3.win32] axis2c and sdo prereq these. I need to add these to the SCA doc that pre-reqs axis2c and SDO! Cheers, On 08/07/06, ant elder <[EMAIL PROTECTED]> wrote: > > I've tried following the instructions in the Calculator sample INSTALL doc > and get an error in a popup window saying: > > This application has failed to start because axis2_engine.dll was not > found > > The output at the command prompt is: > > C:\SCA\Dist\Cpp\tuscany_sca_cpp- > 0.1.incubating-M1-bin\samples\Calculator\deploy\bin>runclient.cmd add 5 6 > using Axis2C: C:\SCA\Dist\Cpp\axis2c-bin-0.92-win32" > using TUSCANY_SDOCPP: C:\SCA\Dist\Cpp\tuscany_sdo_cpp- > 0.1.incubating-M1-bin > using TUSCANY_SCACPP: C:\SCA\Dist\Cpp\tuscany_sca_cpp- > 0.1.incubating-M1-bin > > > I tried adding the Axis2 lib dir to the PATH and then get a different > popup > window error saying: > > The procedure entry point xmlTextReaderConstEncoding could not be located > in > the dynamic link library libxml2.dll > > What am I doing wrong? > > Thanks, > > ...ant > > -- Pete
Re: [VOTE] Publish Tuscany C++ M1 release
I guess we could. I had imagined that an M1 would be a debug build, as the likelyhood of needing to use the debug symbols is high - and its going to be developers using it. On 07/07/06, Luciano Resende <[EMAIL PROTECTED]> wrote: Just one quick question... are we going to make the final C++ M1 Release as a non-debug build ? - Luciano On 7/7/06, Edward Slattery <[EMAIL PROTECTED]> wrote: > > Ive downloaded and run the sca , sdo and Calculator sample. > I used first the command line build, then visual studio 6 then visual > studio > 7 - all ran and produced a working sample. > > This gets a +1 from me. > > There are two minor issues which I would *not* consider as important > enough > for a respin: > > 1) > I noticed that the build.cmd in the sca projects/tuscany_sca direcory > doesnt > fire the ant script to build scagen. If you have ant installed and a valid > jvm, then this change to the build.cmd will fix that: > > cd ..\..\tools\scagen > ant > cd ..\..\projects\tuscany_sca > cd tuscany_sca_test > nmake -f tuscany_sca_test.mak ALL > cd .. > > 2) The calculator INSTALL instructions dont make it clear that the > build.cmdfile is in the > ides\devstudio6\projects\Calculator directory. > > There are also a lot of warnings in the code as signed/unsigned mismatch > is > reported in devstudio7 - these are not important problems and will be > fixed > as soon as possible. > > Ive raised JIRAs > > On 07/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > yup.. .the vote will run until it stops ;-) > > > > I'll be around on the mailing list but not IRC. > > > > Thanks for looking at it. > > > > Cheers, > > > > > > On 07/07/06, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > I think the 72 hours is a minimum not an exact amount of time, the > vote > > > can > > > keep running until you've got the necessary number of binding +1s. Its > > > also > > > not great that a large part of this will be over a weekend so you may > > end > > > up > > > needing to wait a bit longer. > > > > > > I'm far from being a C++ expert so so far I'm struggling to get this > > > running. I need to stop for now but I will be back on it over the > > weekend, > > > it would be great if some of you C++ guys could be around on the > mailing > > > list and IRC to answer any questions about C++ setup I may have. > > > > > > Thanks, > > > > > > ...ant > > > > > > On 7/6/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > > > > > I have posted a candidate for the first C++ release here: > > > > > > > > http://people.apache.org/~robbinspg/RC1 > > > > > > > > The code is tagged in svn: > > > > > > > > > > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/tags/cpp-0.1.incubating-M1/ > > > > < > > > > > > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/tags/cpp-0.1.incubating-M1/%C2%A0 > > > > > > > > > > > > > > > > > Please vote to publish the Milestone 1 release distributions. Please > > > > take some time to download the distributions, review them and test > > them > > > > in your environment before voting. > > > > > > > > The vote is open for the next 72 hours, please vote by July 9th, > > > > 23:00 BST. At least three +1 votes are required, and only the votes > > from > > > > Tuscany committers are binding. If the majority of all votes is > > > > positive, I will send a summary of that vote to the Incubator's > > general > > > > list to formally request the Incubator PMC to approve the Tuscany > C++ > > > > Milestone 1 release. For your reference the Incubator release policy > > > > guidelines are available at > > > > > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > > . > > > > > > > > > > > > Release Summary > > > > = > > > > > > > > Tuscany SCA C++ provides a runtime implementation for the Service > > > > Component > > > > Architecture 0.9 specification, written in C++ and will currently > > > support > > > > C++ > > > > component implementation types. This is not yet a complete > > > implementation > > > > and > > > > known rest
Re: C++ M1 Release Candidate
Good point, you should raise a JIRA that the build.cmd doesnt run it automatically. The test program is runtime/core/test/Debug/sdo_test.exe, and needs to be run from the runtime/core/test directory: cd runtime/core/test Debug\sdo_test There are currently only 108 tests running, although the doc says 111. You are supposed to get a few messages about files not found, followed by "108 tests passed". Cheers, Ed. On 07/07/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: I built the SDO release from the command line using build.cmd as it says in the INSTALL file and that worked without apparent error. At this point I would like to run the same set of tests that I would normally run from the Visual Studio build ie the sdo_test project, but I can't see how to do that. Does the test program get built from the command line? Thanks, Geoff.
Re: [VOTE] Publish Tuscany C++ M1 release
Ive downloaded and run the sca , sdo and Calculator sample. I used first the command line build, then visual studio 6 then visual studio 7 - all ran and produced a working sample. This gets a +1 from me. There are two minor issues which I would *not* consider as important enough for a respin: 1) I noticed that the build.cmd in the sca projects/tuscany_sca direcory doesnt fire the ant script to build scagen. If you have ant installed and a valid jvm, then this change to the build.cmd will fix that: cd ..\..\tools\scagen ant cd ..\..\projects\tuscany_sca cd tuscany_sca_test nmake -f tuscany_sca_test.mak ALL cd .. 2) The calculator INSTALL instructions dont make it clear that the build.cmdfile is in the ides\devstudio6\projects\Calculator directory. There are also a lot of warnings in the code as signed/unsigned mismatch is reported in devstudio7 - these are not important problems and will be fixed as soon as possible. Ive raised JIRAs On 07/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote: yup.. .the vote will run until it stops ;-) I'll be around on the mailing list but not IRC. Thanks for looking at it. Cheers, On 07/07/06, ant elder <[EMAIL PROTECTED]> wrote: > > I think the 72 hours is a minimum not an exact amount of time, the vote > can > keep running until you've got the necessary number of binding +1s. Its > also > not great that a large part of this will be over a weekend so you may end > up > needing to wait a bit longer. > > I'm far from being a C++ expert so so far I'm struggling to get this > running. I need to stop for now but I will be back on it over the weekend, > it would be great if some of you C++ guys could be around on the mailing > list and IRC to answer any questions about C++ setup I may have. > > Thanks, > > ...ant > > On 7/6/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > I have posted a candidate for the first C++ release here: > > > > http://people.apache.org/~robbinspg/RC1 > > > > The code is tagged in svn: > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/tags/cpp-0.1.incubating-M1/ > > < > > > http://svn.apache.org/repos/asf/incubator/tuscany/tags/cpp-0.1.incubating-M1/%C2%A0 > > > > > > > > > Please vote to publish the Milestone 1 release distributions. Please > > take some time to download the distributions, review them and test them > > in your environment before voting. > > > > The vote is open for the next 72 hours, please vote by July 9th, > > 23:00 BST. At least three +1 votes are required, and only the votes from > > Tuscany committers are binding. If the majority of all votes is > > positive, I will send a summary of that vote to the Incubator's general > > list to formally request the Incubator PMC to approve the Tuscany C++ > > Milestone 1 release. For your reference the Incubator release policy > > guidelines are available at > > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases . > > > > > > Release Summary > > = > > > > Tuscany SCA C++ provides a runtime implementation for the Service > > Component > > Architecture 0.9 specification, written in C++ and will currently > support > > C++ > > component implementation types. This is not yet a complete > implementation > > and > > known restrictions are described below. > > > > Supported SCA Assembly Model features > > * All features are supported unless listed under the known > restrictions > > below. See SCA Assembly Model specification. > > > > Supported language bindings > > * Component implementations written in C++. See SCA Client and > > Implementation Model specification. > > * Component interfaces described by C++ classes. See SCA Client and > > Implementation Model specification. > > > > Supported external service and entry point bindings > > * The web service binding is supported. This implementation will > support > > web services which using document literal SOAP bindings conforming > to > > the > > WS-I basic profile (rpc/encoded is not yet supported). > > > > Known restrictions > > * Subsystem: wiring, entry points and external services are not > > supported. > > * Local service interfaces cannot use overloaded operations (the SCA > > specification limits remote service interfaces to not using > > overloaded operations). > > * Each WSDL definition for a web service binding must be in a single > > WSDL > > document. > > * No load time validation of the deployed SCA application (run time > > validation only). > > * No metadata API. > > > > A sample is included which demonstrates deploying an SCA module, > component > > wiring, locating and invoking C++ service from C++ component, invoking > > from > > a C++ client, and exposing a service as a web service using ws binding. > > > > > > Cheers, > > > > -- > > Pete > > > > > > -- Pete
Re: using stdcxx in tuscany/C++
Hi, Yes, I have looked at using stdcxx, particularly in SDO code, but it applied to SCA also. We use stl internally, particularly lists, maps etc, and are currently Geoff Winn is kindly converting all my antique char* arrays to std:strings. When this is done, we would want to experiment with just inserting stdcxx in place of the implementations we use on windows and linux. This ought to be straight forward - right? I guess there must be logistical problems to overcome in converting from Microsoft stl, but still using Developer Studio to build the projects? Are there problems with clashing header file names, and can we still use the MS runtime library etc? On 06/07/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: Great news! Thanks for keeping us in the loop. Martin Sebor wrote: > Hi, > > We have heard that the Tuscany developers have been exploring > the option of using Apache stdcxx as the common implementation > of the C++ Standard Library for Tuscany/C++. We are wondering > whether this is in fact the case and, if so, what the stdcxx > team can do in order to make it as smooth as possible. > > Martin > > . > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C++ M1 Release Candidate
Ive downloaded and built the src distro on Windows using the command line, devstudio6 and devstudio7. The builds all work fine, but the calculator sample on studio7 only half works as the project descriptions are missing some of the proxies/wrappers. Add works but Div doesnt. Im just going to fix that Ed. On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote: The problem appears to be that WinXP expanding of a compressed folder can not expand the tuscany_sca_cpp-0.1.incubating-M1-src.zip (despite the fact that it was used to create the zip in the first place!). This zip can be successfully extracted using WinZip or even jar -xf so I am not going to update the zip. Any ideas on why WinXP zip expand has a problem?? I'm fairly sure that it is to do with a long path name. Cheers, On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > There is a problem with the Windows src zip for sca to do with filename > lengths. I will fix it and re-post a new zip. > > > On 06/07/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > I have posted a candidate for the first C++ release here. > > > > http://people.apache.org/~robbinspg/RC1 > > > > Would all interested parties take some time to review this so that we > > can either re-spin the release or vote on it asap. > > > > The website documentation is out of date and will be re-written to sync > > with what is in the release. Hopefully this will be done tomorrow. > > > > A Calculator sample is included which demonstrates deploying an SCA > > module, component wiring, locating and invoking C++ service from > > C++ component, invoking from a C++ client, and exposing a service as a web > > service using ws binding. > > > > > > Release Summary > > = > > > > Tuscany SCA C++ provides a runtime implementation for the Service > > Component > > Architecture 0.9 specification, written in C++ and will currently > > support C++ > > component implementation types. This is not yet a complete > > implementation and > > known restrictions are described below. > > > > Supported SCA Assembly Model features > > * All features are supported unless listed under the known > > restrictions > > below. See SCA Assembly Model specification. > > > > Supported language bindings > > * Component implementations written in C++. See SCA Client and > > Implementation Model specification. > > * Component interfaces described by C++ classes. See SCA Client and > > Implementation Model specification. > > > > Supported external service and entry point bindings > > * The web service binding is supported. This implementation will > > support > > web services which using document literal SOAP bindings conforming > > to the > > WS-I basic profile (rpc/encoded is not yet supported). > > > > Known restrictions > > * Subsystem: wiring, entry points and external services are not > > supported. > > * Local service interfaces cannot use overloaded operations (the SCA > > specification limits remote service interfaces to not using > > overloaded operations). > > * Each WSDL definition for a web service binding must be in a single > > WSDL document. > > * No load time validation of the deployed SCA application (run time > > validation only). > > * No metadata API. > > -- > > Pete > > > > > > -- > > Pete > -- Pete
Re: C++ M1 test distro
I would certainly like to take a look at these - and will do so given the time. Right now there are a few problems with building using vc7, which I am in the process of fixing - after that I will find a machine from somewhere (as the free download requires that you uninstall all the stuff I need for my work!) - and try it. On 29/06/06, Rick <[EMAIL PROTECTED]> wrote: Thanks. I hope it gets listed in the prereq. Also just curious many (as with me) don't have this. Any todo's to get working on a open source C++ or feely downloadable: Microsoft: http://msdn.microsoft.com/vstudio/express/visualc/download (could this work? don't have the bandwidth to download right now) Bloodshed: http://www.bloodshed.net/devcpp.html GNU http://gcc.gnu.org/ Pete Robbins wrote: > VC 6. Ed is working on a build for VC 7. > > On 29/06/06, Rick <[EMAIL PROTECTED]> wrote: >> >> Windows binary distros which CPP compiler? Should it be listed under >> the prereqs as needed for windows source and to build samples ? >> Pete Robbins wrote: >> > There is a refreshed version available at: >> > http://people.apache.org/~robbinspg >> > Linux bin build is RHEL3. Windows src and bin now available. >> > >> > Please give these a try and raise problems!! >> > >> > Cheers, >> > >> >> >> - >> 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: [C++] SCA usability
Having been working on the Windows build today, I agree with your summary. There might even be problems to less new users. My saviours this afternoon hav been: 1) Running the axis http server in the debugger - loading the extra sca_ws dll and setting breakpoints. 2) Checking very very carefully the env vars TUSCANY_SCACPP, TUSCANY_SDOCPP, TUSCANY_SCACPP_SYSTEM_ROOT. 3) Checking them again. 4) checking the logs in the axis logs directory - Calculator_blocking gives you what happens when the service is loaded. axis2.log tells you if the service didnt load. - I just asked the asix2c people to add some details to the log to say which dll in which path didnt load - then I think we have all bases covered. On 27/06/06, Simon Laws <[EMAIL PROTECTED]> wrote: I've spent a little time playing with the C++ SCA implementation. I want to replay my understanding to see if it is correct. When constructing a service that will have a web service binding you have to provide a number of things including myservice.h to define the class that is the service myservice.cpp to implement the class that is the service myservice.wsdl to describe the service interface Of course you have to provide the appropriate SCA configuration files also, e.g. sca.module, Tuscany-model.config etc, and you have to SCAGen the interface to generate proxies and wrappers. - At this point in time there is no WSDL -> C++ or C++ -> WSDL tooling Hence at present there is a requirement that you, as the developer of the service, ensure that the interface described in C++ matches the interface described in WSDL. - At this point in time there is no C++ SDO support for static types Hence interfaces to services that take SDOs will always descibe the interface in terms of DataObjects. - The web services interfaces adopt the doc/literal/wrapped pattern Hence the WSDL has to be constructed/used carefully in this respect to match the expectations of the runtime and the types that are used to describe WSDL message elements are not the types that find their way in and out of the C++ service implementation. It is the types that are themselves wrapped that find themselves presented to and returned from the service implementation. Is this understanding correct? Is there some way we can provide a helper function (or simple generator) that demonstrates how a service operation should handle the types it is presented with and produce a type for return based on the WSDL description of the interface? This could be as simple as providing a mechanism to print out a template C++ operation based on the model formed from the WSDL. Maybe this could be done with good documentation and samples but I'm not sure. I sense that there will be mistakes made in this area by new users;-) Regards Simon
Re: Dynamic change for SDO Types
I can speak for the Tuscany C++ implementation. In this version the data factory keeps a record of all types and their properties. When the first data object is created, the metadata becomes read-only, and properties can no longer be added to types. The only way to add dynamic content to a type is to declare it as an open type - in which case you can add any properties you like, but they apply only to the instance which you are working with, and are not known to the metadata. getInstanceProperties gives you the list of all metadata properties plus all the open ones, whilst getType().getProperties() gives only the properties defined on the metadata. regards, Ed. On 26/06/06, sensystems <[EMAIL PROTECTED]> wrote: Hello I have a conceptual question with SDO, may be you can help me to figure this out: As the dynamic DataObject will always use reflection APIs The questions are: 1) Are there APIs which allow you to change a Type? 2) If so, what's the synchronization between the type and instance my requirements says this: a) I should provide the aplication with an initial base metamodel. b) the users (using the gui)can make instances of that metamodel c) the users can add propertyes to any type d) the users can only remove the properties they added e) if a property is added to a type, the current instances should have that property set to the default value (or may be unset) d) if a property is removed from a type all the instances should have that property removed Thank you very much for your responses. sensystems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C++ M1 test distro
The changes made to the distro on Saturday have made the windows distro no longer work. I think its just a question of the calculator sample - I was working with a 'deploy' directory, where now I think it works in the calculator root, so when I run it I can see both the sca.module in my project and the sca.module in the deploy directory, and I get duplicates. I suggest we use some of Monday to sort this out - Im sure the linux one will be the one most people want anyway. cheers, Ed. On 24/06/06, Pete Robbins <[EMAIL PROTECTED]> wrote: On 24/06/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: I used this binary distro but my machine is Fedora Core3. I got the following problem building the Calculator sample: g++ -g -O2 -o calculator_client Calc.o -L/home/jeremy/Desktop/tuscany_sca-bin-0.1.incubating-M1/lib -ltuscany_sca -L/home/jeremy/Desktop/tuscany_sdo-bin-0.1.incubating-M1/lib -ltuscany_sdo -ltuscany_sdo_axiom -L/home/jeremy/Desktop/axis2c-bin-0.92-linux/lib -laxis2_util -laxis2_axiom -laxis2_wsdl -laxis2_engine -laxis2_parser -laxis2_minizip -lpthread -laxis2_http_sender -laxis2_http_receiver /usr/bin/ld: warning: libtuscany_sca_ws_reference.so.0, needed by /home/jeremy/Desktop/tuscany_sca-bin-0.1.incubating-M1 /lib/libtuscany_sca.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libstdc++.so.5, needed by /home/jeremy/Desktop/tuscany_sca-bin-0.1.incubating-M1 /lib/libtuscany_sca.so, may conflict with libstdc++.so.6 /home/jeremy/Desktop/tuscany_sca-bin-0.1.incubating-M1 /lib/libtuscany_sca.so: undefined reference to `tuscany::sca::ws::WSServiceWrapper::WSServiceWrapper(tuscany::sca::model::WireTarget*)' I assume the conflict on libstc++ is due to distro issues. If I added -ltuscany_sca_ws_reference to the automake files then it built and I was able to run the basic sample :-) Maybe someone can enlighten me wrt linking on linux with automake. If I create a lib A which references libs x,y and z, and z references P, Q and R... when I come to build an executable MyEXE I need to have -lA -lx -ly -lz -lP -lQ -lR. Is this correct? It seems odd that I need to know all the dependencies of the things I depend on. Cheers, -- Pete
Re: BOF at ApacheCon Europe in Dublin
I have registered Ant, Simon, Ed and Pete for the hackathon. cheers, Ed. On 22/06/06, Pete Robbins <[EMAIL PROTECTED]> wrote: I took the liberty of updating the BOF page on the ApacheCon WIKI to book a room: http://wiki.apache.org/apachecon/BirdsOfaFeatherEu06 I hope this is the correct way to book a session! -- Pete
Re: [C++] C++ / PHP BOF at apache con
I just got confirmation that there are not going to be any BOFs at ApacheCon Europe - so that may change our approach On 08/06/06, Edward Slattery <[EMAIL PROTECTED]> wrote: I am hoping to have a bigbank back-end coded by apachecon - it would be good to have another language as the front end to show WS interop On 08/06/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > I believe Pete was thinking of trying for a C++ BOF at ApacheCon in a > few > weeks time. In the C++ release IRC on Tuesday ( > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg03746.html) > there > was discussion of trying to get a simple sample, based loosely on the > big > bank scenario, running in C++ and also possibly across the different > implementations. Is there any appetite to use this during the BOF > (assuming > a slot is available of course) end extend the BOF scope to > interoperatbility > across implementations? > >
Re: [C++] C++ / PHP BOF at apache con
I am hoping to have a bigbank back-end coded by apachecon - it would be good to have another language as the front end to show WS interop On 08/06/06, Simon Laws <[EMAIL PROTECTED]> wrote: I believe Pete was thinking of trying for a C++ BOF at ApacheCon in a few weeks time. In the C++ release IRC on Tuesday ( http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg03746.html) there was discussion of trying to get a simple sample, based loosely on the big bank scenario, running in C++ and also possibly across the different implementations. Is there any appetite to use this during the BOF (assuming a slot is available of course) end extend the BOF scope to interoperatbility across implementations?
Re: C++ Release Manager
+1 Ed. On 07/06/06, Simon Nash <[EMAIL PROTECTED]> wrote: +1 from me as well. Simon Daniel Kulp wrote: > I'll +1 for Pete. It's always good to see a volunteer. :-) > > Dan > > > On Wednesday June 07 2006 4:28 am, Pete Robbins wrote: > >>As we work towards a binary C++ release we need to elect a release manager. >> >>I'm happy to volunteer for this. > > -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Re: dynamically stating where the root is
That looks fine. Thanks,
Ed.
On 23/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
Ed, please take a look at the code I checked in for Jira TUSCANY-401.
There is a TuscanyRuntime class which allows you to specify the default
module and also the path to the system root. The constructor takes these
in
the but I think it is probably better to have
these the other way round as the most common thing will be to specify the
module and not the root. This would allow you to code:
TuscanyRuntime runtime("myModule");
instead of
TuscanyRuntime runtime("", "myModule"); // root set to "" will use env var
What do you think?
On 18/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> Java has a TuscanyRuntime to specify the default module so I will do
the
> same. Something like:
> TuscanyRuntime::start();
>
> You will still need to set the TUSCANY_SCACPP_SYSTEM_ROOT to the root
> deployment folder for the system.
>
> Cheers,
>
>
>
> On 17/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > That's a good point. A call to initialize the runtime passing the
system
> > root and default module is a possibility. I'll look into it.
> >
> >
> > On 17/05/06, Edward Slattery <[EMAIL PROTECTED] > wrote:
> > >
> > > I am using the tuscany c++ SCA, and am finding it quite inconvenient
> > > that
> > > the root and default module are set by environment variables. As I
use
> > > a
> > > development environment which reads the env at startup, I have to
> > > alter
> > > these variables , close my studio, re-open every time I want to
change
> > > tests.
> > >
> > > I would really appreciate it if I could have a call to the runtime
> > > which
> > > overrides the environment settings, and maybe even another call
which
> > > re-instates the use of env vars. Then I could hop about between
tests,
> > > and
> > > even write a generic test client which takes the names of the root
and
> > >
> > > module as parameters.
> > >
> > > Any chance?
> > >
> > >
> >
> >
> > --
> >
> > Pete
> >
>
>
>
> --
>
> Pete
>
--
Pete
Re: problems with svn or not?
All is mysteriously working today. Thanks someone somewhere. On 22/05/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: I'm having no problems (read or write) Might want to pester your local network admin. -- Jeremy On 5/22/06, Edward Slattery <[EMAIL PROTECTED]> wrote: > I am still having problems with access to the repository using https. (http > is fine). Other projects such as Harmony report the same problem, but it > appears to be local to Hursley, they can all use https from other locations. > Are other tuscans working OK? > Our problem report is stalled as the helpline believe this is an apache > problem, but I think it must be a firewall issue. It just happens to have > started at the same time as the svn repo problems last week. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problems with svn or not?
I am still having problems with access to the repository using https. (http is fine). Other projects such as Harmony report the same problem, but it appears to be local to Hursley, they can all use https from other locations. Are other tuscans working OK? Our problem report is stalled as the helpline believe this is an apache problem, but I think it must be a firewall issue. It just happens to have started at the same time as the svn repo problems last week.
Re: [HELP] Tuscany M1 release candidate 3 available for review
RC3 builds for me without any problems. I used IBMs 5.0 java on windows XP. (Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060222a (SR1)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060222a (JIT enabled)) If we're getting really picky, the BUILDING instructions say that you should "Make sure you are in the tuscany/java directory" But really you just have to be in the root of where ever you unzipped the release to. Great job on the release candidate! Ed. On 18/05/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Hi all, A new release candidate (RC3) of our Tuscany Milestone 1 distribution is available for review and comment at: http://people.apache.org/~jsdelfino/test-incubating-M1 I'd like all the people interested in helping out to try it. Please open JIRA issues at http://issues.apache.org/jira/browse/TUSCANY for all requests and bug reports and send us any comments you have. Fixes and patches are welcome too, it's very easy to attach a patch to a JIRA issue :) RC3 contains a few bug fixes, mostly packaging and documentation related. It also introduces new Ant build scripts to allow the samples to be built offline, without Maven (this is the fix for JIRA TUSCANY-399), and a new GettingStarted.htm page at the root of the binary distribution (fix for TUSCANY-388). I am not expecting any runtime code changes in M1 at this point, but I think that we still have a little bit of work to finalize the new GettingStarted page and the readme documentation of the steps to build and run the samples. Please help us make our Milestone 1 a quality release! Thank you for your help! -- Jean-Sebastien
Re: 1) Hello and 2) Open Content issue
According to my understanding of open properties, you are right.
If the schema contains a global property of the same name, in the same
namespace, then the open content should be created following the schema
definition for that global property.
I would expect that an open property described with a cardinality of 1 would
be single-valued, and one which was unbounded would be many-valued. I would
also expect that properties defined as xsd:string type would be of SDO
dataType.
The interesting problems arise when there is no schema definition of the
corresponding global property. In that case some assumptions are made, and I
believe the default is that the newly created property will itself be an
open sequenced dataObject type. Any text content read from the XML document
will appear as text elements in the sequence, and any elements found within
the open property will also be open, unless they have a global property
definition in the schema.
On 18/05/06, kelvin goodson <[EMAIL PROTECTED]> wrote:
Hello,
given the recent set of people announcing themselves as working on
Tuscany, I guess I should say hello properly. I'm Kelvin Goodson, and
I'm
working on Java SDO.
To that end I've recently been doing some digging with SDO Java open
content
programs, and I'm not sure what the behaviour should be at times. I've
been
jotting my musings at
http://wiki.apache.org/ws/Tuscany/Java/SDO/ThinkingAloud/OpenContent.
I'd like to clarify the behaviour of the Java code with respect to the
maxOccurs values associated with global elements and wildcards (I've
opened
Jira http://issues.apache.org/jira/browse/TUSCANY-396 for this, but the
discussion here goes beyond that issue.)
Here's my starting schema ...
http://www.example.com/open";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
targetNamespace="http://www.example.com/open";>
To be able to set a value into a wildcard (), you have to be able
to get hold of a Property that is associated with a global element, the
schema above demonstrates one way to create such a beast. In the code you
can find the Property that is generated from the element "simple" with ...
Property p =
XSDHelper.INSTANCE.getGlobalProperty("
http://www.example.com/simpleGlobalElem";,
"simple", true);
so then you should I think be able to do ...
OpenQuote oq = OpenFactory.INSTANCE.createOpenQuote();
Property pc =
XSDHelper.INSTANCE.getGlobalProperty("http://www.example.com/open";,
"note", true);
((DataObject)oq).set(pc, "TBA");
but there's a problem with the code at the moment I think (see above
referenced Jira)
so at the moment you have to do something like this ...
OpenQuote oq = OpenFactory.INSTANCE.createOpenQuote();
oq.setSymbol("ww");
DataObject doq = (DataObject)oq;
boolean isElement = true;
Property pc =
XSDHelper.INSTANCE.getGlobalProperty("http://www.example.com/open";,
"note", isElement);
// value must be added as a list
List lnote = new ArrayList();
lnote.add(new String("TBA"));
doq.set(pc, lnote);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
XMLHelper.INSTANCE.save(doq, "http://www.example.com/open";,
"openStockQuote", baos);
System.out.println(baos.toString());
which gives ...
http://www.example.com/open";>
ww
TBA
Open content with max occurs > 1
The behaviour of the code here may throw some light on why the single
valued
case is as it is, and perhaps that I have misunderstood that case. Here's
where my experiments have led so far
Considering the schema ...
http://www.example.com/open";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
targetNamespace="http://www.example.com/open";>
The following document
http://www.w3.org/2001/XMLSchema-instance";
xmlns:open="http://www.example.com/open"; xsi:type="open:OpenQuote2">
ww
TBA
1
is created by the following code ...
OpenQuote2 oq = OpenFactory.INSTANCE.createOpenQuote2();
oq.setSymbol("ww");
DataObject doq = (DataObject)oq;
boolean isElement = true;
Property pc =
XSDHelper.INSTANCE.getGlobalProperty("http://www.example.com/open";,
"note", isElement);
List lnote = new ArrayList();
lnote.add(new String("TBA"));
doq.set(pc, lnote);
Property pc2 =
XSDHelper.INSTANCE.getGlobalProperty("http://www.example.com/open";,
"count", isElement);
List lcount = new ArrayList();
lcount.add(new Integer(1));
doq.set(pc2, lcount);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
XMLHelper.INSTANCE.save(doq, "http://www.example.com/open";,
"openStockQuote2", baos);
System.out.println(baos.toString());
Which kind of surprised me a bit, since I had expected the second set()
call
to overwrite the first, but now it kind of makes sense. So that makes me
reconsider the semantics I had placed upon the single cardinality case
above, and begs the ques
dynamically stating where the root is
I am using the tuscany c++ SCA, and am finding it quite inconvenient that the root and default module are set by environment variables. As I use a development environment which reads the env at startup, I have to alter these variables , close my studio, re-open every time I want to change tests. I would really appreciate it if I could have a call to the runtime which overrides the environment settings, and maybe even another call which re-instates the use of env vars. Then I could hop about between tests, and even write a generic test client which takes the names of the root and module as parameters. Any chance?
Re: build failure - doxia-site-renderer followup #369?
I am also trying the RC1 build, and getting the same problem as paul: 1K downloaded Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/doxia/doxia/1.0-alpha-8/doxia-1.0-alpha-8.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:doxia-site-renderer:jar:1.0-alpha-8 Reason: Cannot find parent: org.apache.maven.doxia:doxia for project: null:doxia-site-renderer:jar:1.0-alpha-8 I am not quite clear as to how my maven2 is looking at codehaus at all - its not in my settings.xml, I only have ibiblio: mirrors.ibiblio.org Mirror of http://repo1.maven.org/maven2/ http://www.ibiblio.org/maven2/ central Anyone any clues? On 16/05/06, Andrew Borley <[EMAIL PROTECTED]> wrote: Hi, I'm doing some building/testing on the M1-RC1 src release. When I run maven I get the following build error. I then found the missing jars had been downloaded into the tuscany-incubating-M1-src\sca\bindings\sunjars\target\celtix-install\celtix\lib directory and manually added them via the comands below makes it all work again. Is this a side effect of the problems with the codehaus.org server, another maven timeout thing or should this be a new JIRA? Cheers Andrew [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) javax.jws:jsr181-api:jar:2.0-JAXWS-2.0-EA3 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.jws -DartifactId=jsr181-api \ -Dversion=2.0-JAXWS-2.0-EA3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-tools:jar:1.0 4) javax.jws:jsr181-api:jar:2.0-JAXWS-2.0-EA3 2) javax.xml:saaj-api:jar:1.3 Try downloading the file manually from: https://jax-ws.dev.java.net/files/documents/4202/24765/JAXWS_SI_20051128.jar Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=saaj-api \ -Dversion=1.3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-tools:jar:1.0 4) javax.xml:saaj-api:jar:1.3 3) javax.xml:jaxws-api:jar:2.0-JAXWS-2.0-EA3 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=jaxws-api \ -Dversion=2.0-JAXWS-2.0-EA3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-tools:jar:1.0 4) org.objectweb.celtix:celtix-common:jar:1.0 5) javax.xml:jaxws-api:jar:2.0-JAXWS-2.0-EA3 4) javax.annotation:jsr250-api:jar:2.0-JAXWS-2.0-EA3 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=javax.annotation-DartifactId=jsr250-api \ -Dversion=2.0-JAXWS-2.0-EA3 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 2) org.objectweb.celtix:celtix-rt:jar:1.0 3) org.objectweb.celtix:celtix-tools:jar:1.0 4) org.objectweb.celtix:celtix-common:jar:1.0 5) javax.annotation:jsr250-api:jar:2.0-JAXWS-2.0-EA3 -- 4 required artifacts are missing. for artifact: org.apache.tuscany.sca.bindings:tuscany-binding-celtix:jar:incubating-M1 from the specified remote repositories: central (http://repo1.maven.org/maven2), objectweb (http://maven.objectweb.org/maven2), ibiblio (http://www.ibiblio.org/maven2)
problems with maven repositories
I didnt seem to be able to run the "mvn site" to build the tuscany site today. I got an error saying that maven couldnt locate the ant plugin on "central". I tried deleting the local repository (documents and settings/me/.m2/repository). That just made it fail quicker by not finding the site plugin. I tried moving from mvn 2.0.1 to 2.0.4. - that changed nothing. I found an old mail on the list where others had similar problems, saying I might try adding this to my maven/conf/setting.xml: mirrors.dotsrc.org Mirror of http://repo1.maven.org/maven2/ http://mirrors.dotsrc.org/maven2/ central public.planetmirror.com Mirror of http://repo1.maven.org/maven2/ http://public.planetmirror.com/pub/maven2/ central I did that, and got an xml file created under the local repository, seemingly coming from planetmirror, but with all the end-tags missing so it was not much use. Finally I deleted the planetmirror mirror, and the other one mirrors.dotsrc.org kicked in and everything worked. Does anyone know what made maven not work in the first place, or what made it work in the end? Ed.
Re: [C++] Options for string handling in SDO
FWIW I would think of creating an SDO string class which can be constructed from a char* or a std::string, and make the methods use the SDO string, such that either char* or std::string can be input. On 12/05/06, Simon Laws <[EMAIL PROTECTED]> wrote: Hi Geoff When you talk about string objects do you mean instances of the ANSI string class (basic_string) or is this a special SDO designed string class? Also why is this an either/or? It would seem like a useful thing to have an interface that allows string objects to be used but not sure I would want to loose the ability to use C strings as well. Simon On 5/12/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > Much of the string data in SDO for C++ is handled as C style, > null-terminated arrays of characters. I'm trying to move that to a style > where most string data is represented as true string objects. > > The painless (less painful) way to do that is to leave the externals alone > and to introduce string objects internally, converting between string > objects and C-style strings at the earliest convenient point when called > and > the last convenient point on return. > > The alternative is to extend the public interface with extra methods that > take string objects as arguments rather than C-style strings. In this case > we would have to publicise a new string class as well. > > Does anyone have any opinions on which of these is preferable (or any > other > alternatives)? We could of course make the internal only changes first and > add an extended public interface later. > > Regards, > > Geoff. > >
Re: New Wiki page for SDO Java documentation
Our paths have crossed a bit here. If all goes well the page should be at http://wiki.apache.org/ws/Tuscany/TuscanyJava/SDOJavaOverview On 12/05/06, kelvin goodson <[EMAIL PROTECTED]> wrote: I've added a new page to the WIKI to cover SDO Java project details. http://wiki.apache.org/ws/Tuscany/SDOJavaOverview Please take a look. Any comments/ typo catches gratefully received. -- Best Regards Kelvin Goodson
Re: wiki changes
yes, I didnt discover the rename option until after I had made the changes. I will rename the pages so the change history is preserved. On 12/05/06, kelvin goodson <[EMAIL PROTECTED]> wrote: I'm not sure how important others consider this, but the change history for a page is lost in this process. I for one have on more than one occasion looked at the page info to see who the "expert" is on a given field. Can we not move the pages (along with their history) from the Tuscany to the Tuscany/Java root? I'll dig around to see if it is possible. Cheers, Kelvin. On 5/12/06, Edward Slattery <[EMAIL PROTECTED]> wrote: > > OK, in the interests of getting this moving, I have made the changes. > There is a main Tuscany page, and three subsidiary pages for PHP, C++ and > Java. > I have DUPLICATED all the subsidiary Java pages, so there is curently a > Tuscany/TuscanyJava/Extending, as well as a Tuscany/Extending. > > You have three choices: > > 1) Tell me you are OK with the changes, and I will delete the > Tuscany/ > > 2) Delete your own duplicate pages > > 3) Tell me you hate it and want it back how it was. > > cheers, > Ed. > > On 12/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > We certainly need to get some C++ information up there so... +1 from me. > > > > On 12/05/06, Edward Slattery <[EMAIL PROTECTED]> wrote: > > > > > > Anyone object if I move the wiki around so we have a common Tuscany > main > > > page and sub-pages for java, c++ and php? > > > > > > > > > > > > -- > > Pete > > > > > > -- Best Regards Kelvin Goodson
Re: wiki changes
OK, in the interests of getting this moving, I have made the changes. There is a main Tuscany page, and three subsidiary pages for PHP, C++ and Java. I have DUPLICATED all the subsidiary Java pages, so there is curently a Tuscany/TuscanyJava/Extending, as well as a Tuscany/Extending. You have three choices: 1) Tell me you are OK with the changes, and I will delete the Tuscany/ 2) Delete your own duplicate pages 3) Tell me you hate it and want it back how it was. cheers, Ed. On 12/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote: We certainly need to get some C++ information up there so... +1 from me. On 12/05/06, Edward Slattery <[EMAIL PROTECTED]> wrote: > > Anyone object if I move the wiki around so we have a common Tuscany main > page and sub-pages for java, c++ and php? > > -- Pete
wiki changes
Anyone object if I move the wiki around so we have a common Tuscany main page and sub-pages for java, c++ and php?
Re: [c++] calculator sample has some old stuff in it.
Yes, I was talking windows On 09/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote: I assume you are talking about the Windows project/scripts. It looks fine on Linux. Cheers, On 09/05/06, Edward Slattery <[EMAIL PROTECTED]> wrote: > > The calculator sample still uses the old SCA4CPP env vars, should be > TUSCANY_SCACPP. I am going to make a patch to fix this, > and to add some details of what 'scagen' is, so its easier to build. > Ed > > -- Pete
[c++] calculator sample has some old stuff in it.
The calculator sample still uses the old SCA4CPP env vars, should be TUSCANY_SCACPP. I am going to make a patch to fix this, and to add some details of what 'scagen' is, so its easier to build. Ed
Re: too many emails
In gmail, use "edit labels" and create a new filter. Define the filter you want , such as "title contains [jira], and redirect these out of your inbox and into a label. On 05/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote: Frank, I use gmail and filter each mailing list into it's own label. I filter out anything with [JIRA] in the title to another label. Works quite well. If you want a gmail address I can send you an invite. Cheers, On 05/05/06, Frank Budinsky <[EMAIL PROTECTED]> wrote: > > Hi, > > Is it just me, or is anyone else finding it hard "to see the forest for > the trees" given all the emails like these from Sebastien (actually JIRA) > every day lately? In the process of deleting all these from my inbox, I'm > accidentally losing some important ones in the middle. Does anyone know if > there's a way to filter/handle these things? > > Thanks, > Frank. > > "Jean-Sebastien Delfino (JIRA)" wrote on > 05/04/2006 05:58:20 PM: > > > [ http://issues.apache.org/jira/browse/TUSCANY-159?page=all ] > > > > Jean-Sebastien Delfino reassigned TUSCANY-159: > > -- > > > > Assign To: Jean-Sebastien Delfino > > > > > Helloworld sample modules and packages should be renamed to > > simpler / shorter names. > > > > > > > > > > > > > Key: TUSCANY-159 > > > URL: http://issues.apache.org/jira/browse/TUSCANY-159 > > > Project: Tuscany > > > Type: Bug > > > > > Components: Java SCA Samples > > > Versions: M1 > > > Reporter: Jean-Sebastien Delfino > > > Assignee: Jean-Sebastien Delfino > > > Fix For: M1 > > > > > > > > The helloworld sample packages should be renamed to simpler / > > shorter package names. I suggest helloworld, helloworldweb, > > helloworldmc, etc. The sample module names should also be cleaned > > up, I suggest we name the SCA modules like the Maven modules, > > helloworld, helloworldweb, helloworldmc etc. > > > > -- > > This message is automatically generated by JIRA. > > - > > If you think it was sent incorrectly contact one of the administrators: > >http://issues.apache.org/jira/secure/Administrators.jspa > > - > > For more information on JIRA, see: > >http://www.atlassian.com/software/jira > > > > -- Pete
Re: [C++] QName and Uri
OK, thanks. Ed. On 04/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote: Ed, this allows me to what I want. There is a problem though... you need copy constructor and operator= methods on TypeDefinitions, TypeDefinition and PropertyDefinition to copy the impl. I'll raise a Jira for this (and probably fix it). Cheers, On 02/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > Great. I'll take a look at it and see if I can use it to achieve what I > need. > > Cheers, > > > On 02/05/06, Edward Slattery <[EMAIL PROTECTED]> wrote: > > > > A while ago, Pete raised a requirement to create Types in a DataFactory > > which are of type URI, but know that they came from a QName originally. > > We store this information in a TypeDefinition class when loading from > > XSD, > > so the easy way to allow Types to be created on the fly with this > > feature > > would be to expose TypeDefinition as a class, and let the user crate a > > list > > of TypeDefinitions, which can be passed back to the DataFactory > > DefineTypes > > method. > > > > I have therefore exposed TypeDefinition, TypeDefiniitons and > > PropertyDefinition classes. I hope this helps. > > > > > > > -- > > Pete > -- Pete
Re: Cross language interop
With regard to the interop scenario concerning moving data graphs from location to location, I am a bit concerned that we are not covering the other option. With the coming of AJAX, some people are looking more at leaving the data where it is, and using the API to modify it on the server. How does this fit with SDO? Currently (certainly in the C++ implementation), we load the data into objects in memory from the data storage, and can then serialize them to XML to be moved around. If we imagine a case where ajax is used to call get/set APIs on data objects, then perhaps we dont even need to load the data from the database until its used. I feel the need for an SDO implmentation which just wraps data access, and does nothing until a data object is actually requested, at which point it uses whatever mechanism is used by the data access service (stored procs etc) to load that individual data object, and send that to the client. Perhaps thats really a separate thread - what do you all think? On 03/05/06, Kevin Williams <[EMAIL PROTECTED]> wrote: kelvin goodson wrote: [snip] > > With regards to sharing change histories, I imagine the primary use case > for change histories is when you give a give a modified graph back to the > "same" DAS for writing back to the original source. So I in terms of > cross > language interoperability I would extrapolate that the scenario we > would be > supporting would be that of fairly tightly coupled DAS > implementations, all > accessing the same source. I may be wrong, but It doesn't sound like a > frequently encountered scenario, so whilst it sounds like goodness, it > wouldn't be at the top of my priority list. > [snip] I have also not seen many interop scenarios requiring cooperation between two different DAS implementations. The only one that comes to mind is reading from one database and writing to another. This would be very cool, especially if the two DAS implementations were in different languages(C++, Java, PHP, Ruby), but I doubt that this scenario will be common. I think a more frequent interop scenario will involve reading data from a data source and shipping it to some remote engine for processing. The modified graph would be shipped back to the originating DAS and the changes reflected to the originating data source. The remote engine could be implemented in another language or, if it is the same language, it could be using a different implementation of SDO.
Re: Cross language interop
On the subject of interop, what are we going to do about some form of compliance suite? We will need to define the range of interop expected, because I guess both Java and C++ implementations interpret things which are not covered by the spec. I am quite sure we do this in different ways. I think it would only be sensible to test interop within the specified behaviour, and highlight as we go along where the specification is open to interpretation. cheers, Ed. On 03/05/06, Edward Slattery <[EMAIL PROTECTED]> wrote: Can the Java SDO handle the Primer sample without moidification? The C++ one certainly cannot as it uses ecore: stuff , which I dont have. cheers, Ed. On 03/05/06, kelvin goodson <[EMAIL PROTECTED]> wrote: > > There's a pair of files called "Primer.xsd" and "PrimerSample.xml" which > I > have used in the past which come from Eclipse EMF and > is as comprehensive in its coverage of schema as I have ever > needed. I'm > not sure how we stand on being able to distribute these as part of the > test > suite in Tuscany. A quick google shows the files available from the > article > > > http://www.eclipse.org/newsportal/article.php?id=3666&group=eclipse.tools.emf > as attachments > > http://www.eclipse.org/newsportal/attachment.php?group=eclipse.tools.emf&id=3666&attachment=2 > and > > http://www.eclipse.org/newsportal/attachment.php?group=eclipse.tools.emf&id=3666&attachment=3 > > With regards to sharing change histories, I imagine the primary use > case > for change histories is when you give a give a modified graph back to > the > "same" DAS for writing back to the original source. So I in terms of > cross > language interoperability I would extrapolate that the scenario we would > be > supporting would be that of fairly tightly coupled DAS implementations, > all > accessing the same source. I may be wrong, but It doesn't sound like a > frequently encountered scenario, so whilst it sounds like goodness, it > wouldn't be at the top of my priority list. > > I don't have a strong feeling yet for the shape of tests we should do, > but > perhaps we could talk about which interop tests we want to do on the IRC > channel in the next regular slot (I'm assuming that's Monday May 8th, > at: > 15:30 GMT, 16:30 BST, 08:30am PST, 11:30am EDT, 21:00 Bangalore) > > Cheers, kelvin. > > On 5/2/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > I spent a little time getting familiar with PHP/SDO and had some more > > thoughts about cross language interop testing. For SDO the most basic > test > > is to read and write an XML file from PHP/JAVA/C++ and compare the > > results. > > We could develop this to test other functions such as creating, > updating > > and > > deleting content and again comparing the content from the different > > implementations. Assuming we start with the same input we would expect > the > > outputs to be compatible. > > > > Is there an XML file somewhere that contains the full set of supported > > > types > > and type constructs? > > > > Where relational DASs are implemented Similar tests could be carried > out > > with relational data ensuring that type conversions are performed > > accurately > > and consistently across implementations by reading out of a database > and > > printing out the data for comparison or by inserting back into a > database > > for comparison. > > > > We could also look at how consistently the implementations convert > from > > one > > DAS type to another but I guess this is not strictly an > interoperability > > issue. > > > > Is there an intention that SDO change histories will be shared? If so > this > > is something else that you could expect to be transferred across > language > > boundaries and hence we should think about how to test this. > > > > Once the work is done to have C++ support Axis2 we should do some SCA > > interop testing also. In the near term we could do some basic testing > > based > > on SDO/axiom conversions if it's thought that to be worth it. > > > > I'm happy to spend time setting up tests if we can agree which ones > are > > required. > > > > Thoughts > > > > Regards > > > > Simon > > > > > > > -- > Best Regards > Kelvin Goodson > >
Re: Cross language interop
Can the Java SDO handle the Primer sample without moidification? The C++ one certainly cannot as it uses ecore: stuff , which I dont have. cheers, Ed. On 03/05/06, kelvin goodson <[EMAIL PROTECTED]> wrote: There's a pair of files called "Primer.xsd" and "PrimerSample.xml" which I have used in the past which come from Eclipse EMF and is as comprehensive in its coverage of schema as I have ever needed. I'm not sure how we stand on being able to distribute these as part of the test suite in Tuscany. A quick google shows the files available from the article http://www.eclipse.org/newsportal/article.php?id=3666&group=eclipse.tools.emf as attachments http://www.eclipse.org/newsportal/attachment.php?group=eclipse.tools.emf&id=3666&attachment=2 and http://www.eclipse.org/newsportal/attachment.php?group=eclipse.tools.emf&id=3666&attachment=3 With regards to sharing change histories, I imagine the primary use case for change histories is when you give a give a modified graph back to the "same" DAS for writing back to the original source. So I in terms of cross language interoperability I would extrapolate that the scenario we would be supporting would be that of fairly tightly coupled DAS implementations, all accessing the same source. I may be wrong, but It doesn't sound like a frequently encountered scenario, so whilst it sounds like goodness, it wouldn't be at the top of my priority list. I don't have a strong feeling yet for the shape of tests we should do, but perhaps we could talk about which interop tests we want to do on the IRC channel in the next regular slot (I'm assuming that's Monday May 8th, at: 15:30 GMT, 16:30 BST, 08:30am PST, 11:30am EDT, 21:00 Bangalore) Cheers, kelvin. On 5/2/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > I spent a little time getting familiar with PHP/SDO and had some more > thoughts about cross language interop testing. For SDO the most basic test > is to read and write an XML file from PHP/JAVA/C++ and compare the > results. > We could develop this to test other functions such as creating, updating > and > deleting content and again comparing the content from the different > implementations. Assuming we start with the same input we would expect the > outputs to be compatible. > > Is there an XML file somewhere that contains the full set of supported > types > and type constructs? > > Where relational DASs are implemented Similar tests could be carried out > with relational data ensuring that type conversions are performed > accurately > and consistently across implementations by reading out of a database and > printing out the data for comparison or by inserting back into a database > for comparison. > > We could also look at how consistently the implementations convert from > one > DAS type to another but I guess this is not strictly an interoperability > issue. > > Is there an intention that SDO change histories will be shared? If so this > is something else that you could expect to be transferred across language > boundaries and hence we should think about how to test this. > > Once the work is done to have C++ support Axis2 we should do some SCA > interop testing also. In the near term we could do some basic testing > based > on SDO/axiom conversions if it's thought that to be worth it. > > I'm happy to spend time setting up tests if we can agree which ones are > required. > > Thoughts > > Regards > > Simon > > -- Best Regards Kelvin Goodson
Re: Problems retrieving source for SDO for C++
Heres another 'gotcha' that I got caught by. If you check out using http:// instead of https://, then you get a very similar error to the one you are getting, but can check out using update. However, you are never allowed to check anything back in, and get (alternately) error 403, error 200, and just a silent hang when trying to check in your code. On 02/05/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: On 27/04/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > Geoff, I've seen this behaviour too using both TortoiseSVN and subclipse > from eclipse. It's not just on the cpp tree of Tuscany. It seems to happen > fairly randomly. > > On 26/04/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > > > I've tried to retrieve the source for SDO for C++ from the repository > > using > > the following command. > > > > E:> svn checkout http://svn.apache.org/repos/asf/incubator/tuscany/cpp > > > > When I do this fo rthe first time, I get what looks like a failure > > > > svn: REPORT request failed on '/repos/asf/!svn/vcc/default' > > svn: REPORT of '/repos/asf/!svn/vcc/default': 200 OK ( > > http://svn.apache.org) > > > > However, if I then issue the same command again, the extract works > without > > a > > problem (ie lots of files get fetched). > > > > I'm using svn V1.3.0 and I've also tried TortoiseSVN 1.3.3 - which gives > > essentially the same behaviour, failing on this first attempt but then > > succeeding. Is this normal? It feels to me that I'm failing to do some > > setup > > step before attempting the checkout but I can't see what that is. > > > > Thanks and regards, > > > > Geoff. > > > > > > > -- > Pete > While fixing a completely different problem, I discovered that svn checkout works fine when I have my Zone Labs firewall switched off. I'll investigate this a bit further and see if I can find a way to make the two co-exist. Geoff.
[C++] QName and Uri
A while ago, Pete raised a requirement to create Types in a DataFactory which are of type URI, but know that they came from a QName originally. We store this information in a TypeDefinition class when loading from XSD, so the easy way to allow Types to be created on the fly with this feature would be to expose TypeDefinition as a class, and let the user crate a list of TypeDefinitions, which can be passed back to the DataFactory DefineTypes method. I have therefore exposed TypeDefinition, TypeDefiniitons and PropertyDefinition classes. I hope this helps.
Re: C++ release before ApacheCon Europe
+1. From the SDO C++ point of view, the interop that could be done by then would be at the serialized level - I.E being able to load/save the same XML in both systems. In terms of Axis2C support, I am looking into providing a utility to write AXIOM from SDOs and SDO types. Ideally I would do that by creating AXIOM objects directly from SDO properties, but the quick solution would be to stream the SDO to XML, and then use axis2 to read the XML. cheers, Ed. On 01/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote: I think it would be a good idea to have a release of the C++ subproject before ApacheCon Europe (Last week in June). I'll set up a wiki page along the lines of the Java "Tasks" page to set out what we need to do to get to a release. I'd like to have an IRC chat (Wednesday?) to discuss the functional content of this proposed release and how we get there. Current thoughts are to have webservice support using Axis2C and a sample to demonstrate interoperability with the Java release and ... Cheers, -- Pete
Re: [C++] SDO Uri and QName
I will look into that and see what I can do. It looks reasonably easy, but I would have to give you some constructors which do not include the internal "SDOXMLString" - I would give you ones which take a char* - (until I find someone who would be willing to implement an STL interface to the whole SDO library.) On 24/04/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > Thinking a bit more about this it would be nice to expose the > XSDHelperImpl > method: > void defineTypes(TypeDefinitions& types); > > Then I could create my own TypeDefinitions including the schema > information > and simply call this method. This would require that the TypeDefinitions, > TypeDefinition and PropertyDefinitions were available to me to use. > > Cheers, > > > On 24/04/06, Edward Slattery <[EMAIL PROTECTED]> wrote: > > > > I think it makes a lot of sense. I dont currently have an "isQName" > flag, > > but I do have a whole lot of flags such as "isFromList" which tell me > that > > the original many-valued element was loaded from a XSD element. ( > I > > have implemented as a single valued element with a property > called > > "values", but it looks to the DataObject API like a multi-valued element > > with no properties). > > I agree that there is a more general need toretain more context upwards > > from > > XSD to DataFactory. > > Is anyone else having similar requirements? > > > > regards, > > Ed. > > > > > > On 21/04/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > > > The current SDO implementation handles the mapping of QName to the SDO > > Uri > > > type as per the specification. So if I use XSDHelper to load a schema > > > which > > > defines a property as type xs:QName, e.g. > name="joe" > > > type="xs:QName" />then use XMLHelper to load my xml containing > ..<.. > > > joe="ns1:fred" xmlns:ns1="myNS"...> then the value stored in the DO is > > > "myNS#fred". All fine... this is as it should be according to the > spec. > > > > > > My problem is that I want to define the types programatically rather > > than > > > using XSDHelper using DataFactory::addPropertyToType(). There is > no > > > way > > > to say "treat this as a QName" so when I use XMLHelper to load my xml > > the > > > value stored in the DO is "ns1:myNS". > > > > > > Should there be an interface to add schema information to a Property > (or > > > Type)? As well as "isQname" there are other attributes available from > a > > > schema that can not be added using the current API such as "isElement" > > > "isAttribute" to control the serialization to an element/attribute. > > > > > > Does this make sense? > > > > > > -- > > > Pete > > > > > > > > > > > > > -- > Pete > >
Re: [C++] SDO Uri and QName
I think it makes a lot of sense. I dont currently have an "isQName" flag, but I do have a whole lot of flags such as "isFromList" which tell me that the original many-valued element was loaded from a XSD element. ( I have implemented as a single valued element with a property called "values", but it looks to the DataObject API like a multi-valued element with no properties). I agree that there is a more general need toretain more context upwards from XSD to DataFactory. Is anyone else having similar requirements? regards, Ed. On 21/04/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > The current SDO implementation handles the mapping of QName to the SDO Uri > type as per the specification. So if I use XSDHelper to load a schema > which > defines a property as type xs:QName, e.g. type="xs:QName" />then use XMLHelper to load my xml containing ..<.. > joe="ns1:fred" xmlns:ns1="myNS"...> then the value stored in the DO is > "myNS#fred". All fine... this is as it should be according to the spec. > > My problem is that I want to define the types programatically rather than > using XSDHelper using DataFactory::addPropertyToType(). There is no > way > to say "treat this as a QName" so when I use XMLHelper to load my xml the > value stored in the DO is "ns1:myNS". > > Should there be an interface to add schema information to a Property (or > Type)? As well as "isQname" there are other attributes available from a > schema that can not be added using the current API such as "isElement" > "isAttribute" to control the serialization to an element/attribute. > > Does this make sense? > > -- > Pete > >
Re: [C++] Axis2C ws bindings
I have done some preliminary work on SDO integration with axis2C, and have talked to some of the axis2c people about the work. There are two areas I see that we could be worked on. The first is a conversion from an SDO data graph to a tree of AXIOM objects. This could be done by taking SDOXMLWriter for inspiration, and replacing the actual writing to XML part with a creation of an AXIOM element or attribute. We could then flow SDOs over axis2c, and provided we had the same data factory at the other end, could re-build them with an SDOAxiomReader utility. I also assume (maybe wrongly) that there is nothing preventing me using the SDOAxiomWriter to write XSD information, so we could flow both the data and the metadata if required. The second area of interest is the guththila parser. I have tested that it can replace our libxml2 parser, and it seems to be capable of doing that. We could investigate having a kind of pluggable parser layer, and switch parsers between libxml2 and guththila. We would have to work out the best way of integrating - I.E take a copy of guththila and build with it, or have axis2c as a dependency of SDO for C++? The second is cleaner, but I imagine the PHP group might want the option of building SDO with only libxml2 for now. I would be interested to know how the integration of the java SDO is being handled. Anyone aware? On 21/03/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > The current SCA C++ implementation supports webservice binding using Axis > 1.x (there are some outstanding problems with this). I would like to move > up > to use Axis2C. > > One way to do this is to discard the Axis 1.x binding code and replace > with > Axis2C. A better way would be to restructure the code to allow bindings to > be more pluggable. As a starting point I think it would be useful, as > discussed on another thread, to have a Wiki page outlining the current > code > architecture/structure which would be of use for anyone who would like to > help out. > > As part of this it would also be really good to have an SDO C++ > integration > with Axis2C. > > Pete > >
Re: [SDO C++] JIRA Issues: Specification or Implementation concerns?
I think I raised all the issues against SDO C++. The purpose of them is to track the current differences between what is specified and what is implemented, with the aim of making the implementation of the C++ SDO closer to the C++ specification, and if possible and desirable, making the C++ interface closer to the java specification. None of the issues raised are intended to imply a change of the specification to closer reflect the implementation. If in implementing the code, a divergeance from the spec seems useful, it will be raised as a concern on the SDO spec group. On 09/03/06, Mike Edwards <[EMAIL PROTECTED]> wrote: > > Folks, > > I notice a number of JIRA issues raised against the SDO C++ > implementation that have the smell of being specification issues rather > than implementation issues. > > If the issues really do imply changing or extending the specification of > SDO for C++, then I believe that the issues should rightly be raised > against the specification itself (the spec group have their own > infrastructure and email lists). > > I'm OK with having "tracker" issues raised in the Tuscany project which > point to issues raised with the specs, but it must be clear that any > changes to the specs must ultimately be made by the specification teams. > > > Yours, Mike. >
Re: SDO without XML?
I would like to be included in that bit of design when it happens. The C++
implementation of the DataFactory has addType(uri,name, several bools) and
addPropertyToType(typeuri, typename,
name, propuri, propname, several bools), so the factory can be used to
define the types and
properties. It would be good if the two could converge.
regards,
ed.
On 17/01/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:
>
> Defining an SDO model using annotated Java interfaces is something that
> SDO intends to allow in the future, but currently (in version 2) it isn't
> defined in the spec.
>
> We'd like to start to add this kind of support in the Tuscany impl, but it
> would be forging new ground - we'd need to work with the SDO spec people
> to make sure that we're doing it in a way consistent with future versions
> of the spec.
>
> Currently, you need to define your SDO metamodel using XML Schema.
>
> Frank.
>
>
>
>
> Jeremy Boynes <[EMAIL PROTECTED]>
> 01/17/2006 03:18 PM
> Please respond to
> tuscany-dev
>
>
> To
> tuscany-dev@ws.apache.org
> cc
>
> Subject
> SDO without XML?
>
>
>
>
>
>
> I am writing some unit tests which use SDO and would like to create
> instances of my interfaces without having to mess with XML or schemas.
> Is it possible to configure the DataFactory to create instances of an
> interface based purely on definitions in the interface class itself?
>
> I was looking to do something like:
> setup() {
>JavaHelper.define(MyInterface.class);
> }
> testFoo() {
>MyInterface foo = dataFactory.create(MyInterface.class);
> }
>
> Thanks
> --
> Jeremy
>
>
>
Re: svn commit: r366393 - /incubator/tuscany/sandbox/sebastien/
Im happy - if its for sharing not storage that seems a good thing to do. Ed On 06/01/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > I created this directory under sandbox primarily to check that my SVN > commit > access was working... > > But I think that you're raising an interesting question about the sandbox > directory: > The directory I created under sandbox is where I'll want to do prototyping > work and experiments to avoid breaking the code in the trunk, and I don't > want this sandbox to be "private" because I'll want to share and discuss > these prototypes/experiments with all the people working on the project... > Isn't that the primary purpose of sandboxes? > > I don't think that this will confuse people if we make clear that > everything > understands that the tree under the sandbox directory is for prototypes, > experiments, and under-construction stuff. I just took a look at other > Apache projects, axis2, synapse and beehive, and they seem use a sandbox > (or > scratch) directory in a similar way, but that doesn't necessarily mean > that > it's the "right" thing to do... > > So what do the other people on the list think? Do we want to establish > some > guidelines for what we do in sandboxes? Are there any Apache best > practices > that we could point people to? > > > On 1/6/06, Edward Slattery <[EMAIL PROTECTED]> wrote: > > > > Are we checking in private sandboxes to this tree? Wont that confuse > > people? > > > > On 06/01/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > Author: jsdelfino > > > Date: Thu Jan 5 18:19:36 2006 > > > New Revision: 366393 > > > > > > URL: http://svn.apache.org/viewcvs?rev=366393&view=rev > > > Log: > > > created my sandbox directory > > > > > > Added: > > >incubator/tuscany/sandbox/sebastien/ > > > > > > > > > > > > -- > Jean-Sebastien > >
Re: svn commit: r366393 - /incubator/tuscany/sandbox/sebastien/
Are we checking in private sandboxes to this tree? Wont that confuse people? On 06/01/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Author: jsdelfino > Date: Thu Jan 5 18:19:36 2006 > New Revision: 366393 > > URL: http://svn.apache.org/viewcvs?rev=366393&view=rev > Log: > created my sandbox directory > > Added: >incubator/tuscany/sandbox/sebastien/ > >
Re: Java code contribution committed
We added the C++ code this morning directly in the cpp area, and have stacked up the changes made over the break so that we can apply them now. We will begin to do that tomorrow. Ed. On 05/01/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > I committed the Java implementation covered by the joint CCLA under > contrib/java as a staging area before moving it under the main java root. > > Should we do the move now and start work in the new tree or leave it > where it is until we have had a chance to apply patches for changes made > over the break? > > -- > Jeremy >
Re: PHP subproject
I can give you a pointer to the PHP version of SDO, which is currently
available on PECL, and is using the C++ version of SDO. The longer term
objective of that project is to have an SCA implementation for the PHP
community.
Here are two links:
*
http://pecl.php.net/package/sdo
*
http://www.php.net/manual/en/ref.sdo.php
On 19/12/05, Lee Provoost <[EMAIL PROTECTED]> wrote:
>
> Hi!
>
> I'm a master computer science student at the software technology group
> of the university of utrecht (netherlands). SOA technologies will be
> part of my master thesis and the Tuscany project seems very interesting
> for my project. I have also years of experience in PHP, I did several
> projects for insurance companies and software companies and I am very
> interested in participating in the PHP subproject.
>
> Can anyone give me some pointers to material or persons to talk to
> regarding this sub project? In a later stage I would also be interested
> in being involved in the BPEL subproject.
>
> Kind regards
>
> Lee Provoost
>
> --
> Lee Provoost
> Software Technology Group
> Department of Information and Computing Sciences
> University of Utrecht, P.O. Box 80089 3508 TB, Utrecht, The Netherlands
> {l.provoost} @students.uu.nl
> http://blogs.webcoder.be/lee
>
>
