Re: WorkManager in JavaComponentBuilder
I've applied the patch in 422953. Thanks Meeraj!
Jim
On Jul 17, 2006, at 2:25 AM, Meeraj Kunnumpurath wrote:
Jim,
Could you pls have a look and apply the attached patch.
Ta
Meeraj
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 22:50
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder
Jim,
I think it's ok, if I understand it right.
I think the Tuscany runtime components should only know about the
WorkScheduler abstraction. We will configure a Jsr237 or JCA work
scheduler based on the host environment and configure it with an
appropriate work manager provided by the host environment. If no work
managers are available, by default we will use the Jsr237WorkScheduler
configured with the ThreadPoolWorkManager.
BTW, If you are working on this tonight (or today for you), could you
pls remove the synchronized keyword from the ThreadPoolWorkManager
callback methods. The underlying collection I use for keeping track of
the listeners is thread-safe.
Ta
Meeraj
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:56
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder
Thanks Meeraj,
I forgot about the abstraction conversation about a week back...So I'm
just thinking about how to get this into a system service. What do you
think of this:
1. Add @Autowire to the Jsr237WorkScheduler constructor as in
@Constructor(workManager)
public Jsr237WorkScheduler(@Autowire WorkManager
jsr237WorkManager) {
//...
}
2. Configure ThreadPoolWorkManager as a system service.
The runtime will autowire them together.
3. Have JavaComponentBuilder (or better, ComponentBuilderExtension)
have
an autowire to WorkScheduler
For Step 1, we need to add the @Constructor tag for now - I need to
make
a few changes to the annotation processing to allow just specifying
@Autowire on the param.
Jim
On Jul 15, 2006, at 1:41 PM, Meeraj Kunnumpurath wrote:
Jim/Ignacio,
There is abstract called WorkScheduler in the SPI, that hides whether
you are using a JCA or commonj work manager. The two implementations
are JcaWorkScheduler and Jsr237WorkScheduler. The Jsr237WorkScheduler
can be injected with a ThreadPoolWorkManager. This way, depending on
the host environment we can inject a work manager provided by the
environment.
Ta
Meeraj
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:38
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder
Forgot to mention (you may already know this):
You can use Meeraj's work manager, ThreadPoolWorkManager, as the
system service.
Jim
On Jul 15, 2006, at 1:34 PM, Jim Marino wrote:
Ignacio,
Can you check the package name of WorkManager? It should be
commonj.work.WorkManager as opposed to
javax.resource.spi.work.WorkManager? Using comonj on my machine
compiles and runs.
Once you get past that, you'll need to have the work manager system
service deployed as part of the runtime. Could you add this to the
system.scdl in the launcher project under ../main/resource/META-INF/
tuscany? Once you have changed JavaComponentBuilder to add the
autowire, the WorkManager should be picked up.
If you could submit the changes as a patch, I'll add them to the
repo.
Thanks,
Jim
On Jul 15, 2006, at 12:43 PM, Ignacio Silva-Lepe wrote:
All I do is to run mvn from chianti/sca, after adding the autowire
to
JavaComponentBuilder
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Saturday, July 15, 2006 2:59 PM
Subject: Re: WorkManager in JavaComponentBuilder
On Jul 15, 2006, at 11:45 AM, Ignacio Silva-Lepe wrote:
To allow JavaAtomicComponent to create a new
AsyncJavaTargetInvoker, it needs to supply the new target invoker
with a work manager. My first try (which may not be the
appropriate
thing to do) was to get a work manager autowired into
JavaComponentBuilder, which then passes it to
JavaAtomicComponent.
That is how I would do it.
However when I do this I get a NoClassDefFoundError when the
build
tries to run the samples (local.wire, local.wire.cdi,
calculator).
I could add the dependency to each sample's pom.xml, which seems
to
eliminate the error sample by sample. Or I could add the
dependency to the entire samples directory's pom.xml, which at
the
moment has no dependencies. Or I could just be doing the wrong
thing and I should supply the work manager in some other way.
Thoughts?
The work manager dependency shouldn't be surfaced to the samples
since it is an implementation detail of the runtime. How are you
executing the samples? I'm wondering if the appropriate jars are
not
being put on the classpath?
Jim
--
-
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving chianti to trunk
Hi Jeremy, On 7/18/06, Jeremy Boynes [EMAIL PROTECTED] wrote: With the vote in favour of switching, I am about to start moving chianti into trunk. I will move the current sca parts into a branch (branches/pre-chianti) and move the chianti code into trunk. I will make the version in the poms 1.0-SNAPSHOT like the SDO tree. I expect to complete this tomorrow or possibly Wed if there are build issues. If anyone has a bunch of uncommitted changes or a big patch for submission please speak up soon to avoid merge issues. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk
Hi, I can run the all the test cases successfully using mvn clean install. Can you post me the stacktrace? The patch includes the following: 1) Refactor the transformer interfaces to have PullTransformer, PushTransformer and DataPipe extend from Transformer 2) Add cache to shortest path to the graph 3) Add annotations for databinding 4) Add more transformer implementations 5) Improve Mediator interface and implementation (spinned off from TransformerRegistryImpl) (To be integrated as a system service). 6) Add more test casses Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 17, 2006 10:49 PM Subject: Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk On Jul 17, 2006, at 10:01 PM, Raymond Feng wrote: Hi, Jeremy. I have a big patch for the databinding as attached. It includes code improvements, more transformers and test cases. Please review and apply. I applied this but it is a big large to review easily - can you break down what is going on in there? I did have a problem with MediatorTestCase failing but rather than hold off I commented out the tests. Please can you have a look at those and get them working again. Thanks Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving chianti to trunk
Hi Jeremy, I have two patches one in SDO-Impl and another in SCA-Tools (Java2WSDL tooling) that need to be reviewed and applied to M1+. The Jiras are Tuscany-535 and Tuscany-120 respectively. But then they are to applied over M1+. Also, what is the plan for sca-tools in Chianti? Thanks Venkat On 7/18/06, Jeremy Boynes [EMAIL PROTECTED] wrote: With the vote in favour of switching, I am about to start moving chianti into trunk. I will move the current sca parts into a branch (branches/pre-chianti) and move the chianti code into trunk. I will make the version in the poms 1.0-SNAPSHOT like the SDO tree. I expect to complete this tomorrow or possibly Wed if there are build issues. If anyone has a bunch of uncommitted changes or a big patch for submission please speak up soon to avoid merge issues. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany weekly IRC chat log (July-06-2006)
Hi, I just could not log into the IRC... not sure where the problem actually was. Getting to the subject of the image I posted. I am not sure how to upload it into the wiki. To which page should I be attaching it... If somebody can help me with this info I can post the image there.. Also if there is anything that you guys want me to do with the me, please let me know. Thanks. - Venkat On 7/17/06, Simon Laws [EMAIL PROTECTED] wrote: That of course should read July-17-06 On 7/17/06, Simon Laws [EMAIL PROTECTED] wrote: Here is the discussion from today's IRC chat (sorry about the slightly wonky format as I had to cut and paste from my client). The topics of discussion were content updates to the Tuscany web site and the process by which the web site is produced. In summary we are going to progress the following this week. jboyneslayout and nav, slaws what is SCA, kgoodson what is SDO kevinDAS cr22rc help with the web site production toolkit and site content as time allows dwheelerimage stuff Of course everyone is invited to help out here so don't be shy. Simon kgoodsonshall we pick up where we were on improving the website with a clickable picture before OSCon? kgoodsonwhat other topics? --|kevin (n= [EMAIL PROTECTED]) has joined #tuscany slawsi'm just back on line form leave and saw mail about the website, e.g. the nice clickable picture, but i'm confused about what the status is and who is doing what - can you give a quick update rfengThe OSCON is coming, I guess we need to improve the web site as we agreed last time, right? --|simonnash (n= [EMAIL PROTECTED] ) has joined #tuscany simonnashhi slawshi simon - kelivin is just kicking off a discussion on website progress jboyneshi, sorry, I'm back as well kgoodsonhi simon, it's a little quiet, but we are just about to take stock of where the website improvemnt is/is going -- there don't seem tyo be any other topics at the moment -- jeremy has had to disappear jboyneswe have a clckable on the wiki, yes? kgoodsoni liked raymonds picture, with the clickable links, there was aanother picture on the mailing list i think that I cant locate at the moment which was a higher level modular diagram kgoodsonhes, clickable http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca.htm http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29SCADiagram/attachments/sca.htm rfengthe other one is for tuscany architectural layers, I guess slawsyes - high level - was attached as a zip to a mail rfengcan somebody upload it to WIKI as well? kgoodsonyes, am i right in thinking that the one you, rfeng, have done would be linked to from the higher level one? slawshigh level one was on a mail from Venkata Krishnan rfengthe one I prototyped is for SCA composite PM --|jmarino (n= [EMAIL PROTECTED] ) has joined #tuscany slawscan;t find it in the dev archive for some reason kgoodsonhave found it, i will attach to wiki slawsok - great jboynesI checked the toolkit from the incubator site into my sandbox - has anyone had a chance to look at it? slawssorry jeremy - have been out - is this the toolkit for building the website? kgoodsonwiki seems not to want to create a new page, waiting .. jboynesslaws: yes, the toolkit I mentioned last time which has been picked up by a couple of projects (including the incubator) rfengjust point to the new URL you want to place the new page, then you'll see the option to create the new page slawsjboynes: ok - ta - haven't tried it yet but can give it a whirl jboynesok jboynesanyone else interested or does anyone have any alternatives? kgoodsonyes i'm intersted but i don't really know what it buys us jboynesit's simpler than mvn slawsso, coming back to my first question, who is doing what on the website? jboynesI set up the toolkit thing and was waiting for feedback cr22rcjust a command to run for mvn jboynes? cr22rcxdocs are a pain ... does it get us away from that ? rfengI'm stuck in something else this week jboynesyou can use xml or html slawsok - and rfeng made the clickable diagram and we also have a top level diagram contributed - anything else? dwheelerI believe I was going to try and come up with a prettier diagram(s) for the clickable diagram interface. cr22rcI need to look at the other TK too see what it buys us dwheelerbased on the ones we have kgoodsonfinally i have the architecture diag n the wiki ... kgoodson http://wiki.apache.org/ws/Tuscany/ClickableImages?action=show cr22rcto do the site now
[jira] Resolved: (TUSCANY-532) M1 documentation improvements
[ http://issues.apache.org/jira/browse/TUSCANY-532?page=all ] Pete Robbins resolved TUSCANY-532. -- Fix Version/s: Cpp-current Resolution: Fixed M1 documentation improvements - Key: TUSCANY-532 URL: http://issues.apache.org/jira/browse/TUSCANY-532 Project: Tuscany Issue Type: Improvement Components: C++ Build Affects Versions: Cpp-M1 Reporter: Andrew Borley Fix For: Cpp-current Attachments: TUSCANY-532-2.patch, TUSCANY-532-3.patch, TUSCANY-532-4.patch, TUSCANY-532-5.patch, TUSCANY-532-6.patch, TUSCANY-532.patch Clear up documentation by addressing the various issues raised on the mailing list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-534) Windows binary release should not be debug version
[ http://issues.apache.org/jira/browse/TUSCANY-534?page=all ] Pete Robbins resolved TUSCANY-534. -- Resolution: Fixed Windows binary release should not be debug version -- Key: TUSCANY-534 URL: http://issues.apache.org/jira/browse/TUSCANY-534 Project: Tuscany Issue Type: Improvement Components: C++ Build Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-current Change the distribution binary build of windows to be non-debug -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-524) ant for building scagen not run on windows
[ http://issues.apache.org/jira/browse/TUSCANY-524?page=all ] Pete Robbins reassigned TUSCANY-524: Assignee: Pete Robbins ant for building scagen not run on windows -- Key: TUSCANY-524 URL: http://issues.apache.org/jira/browse/TUSCANY-524 Project: Tuscany Issue Type: Bug Components: C++ Build Affects Versions: Cpp-current Reporter: Ed Slattery Assigned To: Pete Robbins Priority: Minor The windows build script does not run the ant task to build scagen - this would do it... cd ..\..\tools\scagen ant cd ..\..\projects\tuscany_sca cd tuscany_sca_test nmake -f tuscany_sca_test.mak ALL cd .. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-525) INSTALL of calculator doesnt say where the build.cmd is located.
[ http://issues.apache.org/jira/browse/TUSCANY-525?page=all ] Pete Robbins closed TUSCANY-525. Fix Version/s: Cpp-current Resolution: Fixed INSTALL of calculator doesnt say where the build.cmd is located. Key: TUSCANY-525 URL: http://issues.apache.org/jira/browse/TUSCANY-525 Project: Tuscany Issue Type: Bug Components: C++ Build Environment: windows Reporter: Ed Slattery Priority: Trivial Fix For: Cpp-current its under ides/devstudio6/projects/Calculator -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-540) WSEntrypoint code has return pointer scoping problem
[ http://issues.apache.org/jira/browse/TUSCANY-540?page=all ] Pete Robbins closed TUSCANY-540. Fix Version/s: Cpp-current Resolution: Fixed WSEntrypoint code has return pointer scoping problem Key: TUSCANY-540 URL: http://issues.apache.org/jira/browse/TUSCANY-540 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current, Cpp-M1 Reporter: Andrew Borley Fix For: Cpp-current Attachments: TUSCANY-540.patch For a WS Entrypoint call the pointers in EntryPointProxy.cpp that hold the component return value fall out of scope, thus bad data is returned. This manifests in a release build of the dll but not the debug build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-517) Show component-to-component invocation in Calculator sample
[ http://issues.apache.org/jira/browse/TUSCANY-517?page=all ] Pete Robbins closed TUSCANY-517. Fix Version/s: Cpp-current Resolution: Fixed Show component-to-component invocation in Calculator sample --- Key: TUSCANY-517 URL: http://issues.apache.org/jira/browse/TUSCANY-517 Project: Tuscany Issue Type: Improvement Components: C++ SCA Affects Versions: Cpp-M1 Reporter: Andrew Borley Priority: Minor Fix For: Cpp-current Attachments: TUSCANY-517.patch We need to include a sample that shows component-to-component invocation. The Calculator sample would be a good candidate - we could have a DivideService that is invoked by the Calculator div operation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WorkManager in JavaComponentBuilder
Ta
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 18 July 2006 07:03
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder
I've applied the patch in 422953. Thanks Meeraj!
Jim
On Jul 17, 2006, at 2:25 AM, Meeraj Kunnumpurath wrote:
Jim,
Could you pls have a look and apply the attached patch.
Ta
Meeraj
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 22:50
To: tuscany-dev@ws.apache.org
Subject: RE: WorkManager in JavaComponentBuilder
Jim,
I think it's ok, if I understand it right.
I think the Tuscany runtime components should only know about the
WorkScheduler abstraction. We will configure a Jsr237 or JCA work
scheduler based on the host environment and configure it with an
appropriate work manager provided by the host environment. If no work
managers are available, by default we will use the Jsr237WorkScheduler
configured with the ThreadPoolWorkManager.
BTW, If you are working on this tonight (or today for you), could you
pls remove the synchronized keyword from the ThreadPoolWorkManager
callback methods. The underlying collection I use for keeping track of
the listeners is thread-safe.
Ta
Meeraj
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:56
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder
Thanks Meeraj,
I forgot about the abstraction conversation about a week back...So I'm
just thinking about how to get this into a system service. What do you
think of this:
1. Add @Autowire to the Jsr237WorkScheduler constructor as in
@Constructor(workManager)
public Jsr237WorkScheduler(@Autowire WorkManager
jsr237WorkManager) {
//...
}
2. Configure ThreadPoolWorkManager as a system service.
The runtime will autowire them together.
3. Have JavaComponentBuilder (or better, ComponentBuilderExtension)
have an autowire to WorkScheduler
For Step 1, we need to add the @Constructor tag for now - I need to
make a few changes to the annotation processing to allow just
specifying @Autowire on the param.
Jim
On Jul 15, 2006, at 1:41 PM, Meeraj Kunnumpurath wrote:
Jim/Ignacio,
There is abstract called WorkScheduler in the SPI, that hides whether
you are using a JCA or commonj work manager. The two implementations
are JcaWorkScheduler and Jsr237WorkScheduler. The Jsr237WorkScheduler
can be injected with a ThreadPoolWorkManager. This way, depending on
the host environment we can inject a work manager provided by the
environment.
Ta
Meeraj
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 15 July 2006 21:38
To: tuscany-dev@ws.apache.org
Subject: Re: WorkManager in JavaComponentBuilder
Forgot to mention (you may already know this):
You can use Meeraj's work manager, ThreadPoolWorkManager, as the
system service.
Jim
On Jul 15, 2006, at 1:34 PM, Jim Marino wrote:
Ignacio,
Can you check the package name of WorkManager? It should be
commonj.work.WorkManager as opposed to
javax.resource.spi.work.WorkManager? Using comonj on my machine
compiles and runs.
Once you get past that, you'll need to have the work manager system
service deployed as part of the runtime. Could you add this to the
system.scdl in the launcher project under ../main/resource/META-INF/
tuscany? Once you have changed JavaComponentBuilder to add the
autowire, the WorkManager should be picked up.
If you could submit the changes as a patch, I'll add them to the
repo.
Thanks,
Jim
On Jul 15, 2006, at 12:43 PM, Ignacio Silva-Lepe wrote:
All I do is to run mvn from chianti/sca, after adding the autowire
to
JavaComponentBuilder
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Saturday, July 15, 2006 2:59 PM
Subject: Re: WorkManager in JavaComponentBuilder
On Jul 15, 2006, at 11:45 AM, Ignacio Silva-Lepe wrote:
To allow JavaAtomicComponent to create a new
AsyncJavaTargetInvoker, it needs to supply the new target invoker
with a work manager. My first try (which may not be the
appropriate
thing to do) was to get a work manager autowired into
JavaComponentBuilder, which then passes it to
JavaAtomicComponent.
That is how I would do it.
However when I do this I get a NoClassDefFoundError when the
build
tries to run the samples (local.wire, local.wire.cdi,
calculator).
I could add the dependency to each sample's pom.xml, which seems
to
eliminate the error sample by sample. Or I could add the
dependency to the entire samples directory's pom.xml, which at
the
moment has no dependencies. Or I could just be doing the wrong
thing and I should supply the work manager in some other way.
Thoughts?
The work manager dependency shouldn't be surfaced to the samples
since it is an implementation detail of the runtime. How
Fix for an alloc problem in tuscany_sdo_test
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: Chianti extension manual
Eric, I had a quick look at the DocBook site, but it lacks an overview, and the links to the online html versions of the books seem to be unavailable. I could see the schemata that clearly describe documentation layout, but I couldn't get an idea of what tooling was available to edit and produce the documentation. Can you summarise its features? Cheers, Kelvin. On 7/17/06, Eric Le Goff [EMAIL PROTECTED] wrote: I guess docbook (http://www.docbook.org/) is often used for this kind of docs My 2 cents. On 7/13/06, Jim Marino [EMAIL PROTECTED] wrote: I've started a manual for extending Chianti. It's obviously very rough and missing many pieces but comments and contributions are welcome. If you plan on editing it, please let me know so we don't collide. Also, this is a good point to raise the question of how we want to construct user manuals. I seem to recall Hibernate having a good process which results in the output of multiple formats, including pdf, single page html, and multi-page html. Any suggestions? For the time being, I've left it in Word but plan to switch to a more open format. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric LE GOFF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards Kelvin Goodson
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: Tuscany weekly IRC chat log (July-06-2006)
Hi Venkat here's the moinmojn help page http://moinmoin.wikiwikiweb.de/HelpOnActions/AttachFile basically just write attachment:name_for_attachment in the text body, then when you preview/view it, until the attachment is name resolved to an upoloaded file, it will offer you the opportunity upload a file for the named attachment. Be aware that for certain file extensions in the attachment name (e.g. foo.gif) the behaviour will be different --- it inlines certain recognised extensions or places hyperlinks in the page for attachment names without recognised extensions. Cheers, Kelvin. On 7/18/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I just could not log into the IRC... not sure where the problem actually was. Getting to the subject of the image I posted. I am not sure how to upload it into the wiki. To which page should I be attaching it... If somebody can help me with this info I can post the image there.. Also if there is anything that you guys want me to do with the me, please let me know. Thanks. - Venkat On 7/17/06, Simon Laws [EMAIL PROTECTED] wrote: That of course should read July-17-06 On 7/17/06, Simon Laws [EMAIL PROTECTED] wrote: Here is the discussion from today's IRC chat (sorry about the slightly wonky format as I had to cut and paste from my client). The topics of discussion were content updates to the Tuscany web site and the process by which the web site is produced. In summary we are going to progress the following this week. jboyneslayout and nav, slaws what is SCA, kgoodson what is SDO kevinDAS cr22rc help with the web site production toolkit and site content as time allows dwheelerimage stuff Of course everyone is invited to help out here so don't be shy. Simon kgoodsonshall we pick up where we were on improving the website with a clickable picture before OSCon? kgoodsonwhat other topics? --|kevin (n= [EMAIL PROTECTED]) has joined #tuscany slawsi'm just back on line form leave and saw mail about the website, e.g. the nice clickable picture, but i'm confused about what the status is and who is doing what - can you give a quick update rfengThe OSCON is coming, I guess we need to improve the web site as we agreed last time, right? --|simonnash (n= [EMAIL PROTECTED] ) has joined #tuscany simonnashhi slawshi simon - kelivin is just kicking off a discussion on website progress jboyneshi, sorry, I'm back as well kgoodsonhi simon, it's a little quiet, but we are just about to take stock of where the website improvemnt is/is going -- there don't seem tyo be any other topics at the moment -- jeremy has had to disappear jboyneswe have a clckable on the wiki, yes? kgoodsoni liked raymonds picture, with the clickable links, there was aanother picture on the mailing list i think that I cant locate at the moment which was a higher level modular diagram kgoodsonhes, clickable http://wiki.apache.org/ws-data/attachments/Tuscany(2f)SCADiagram/attachments/sca.htmhttp://wiki.apache.org/ws-data/attachments/Tuscany%282f%29SCADiagram/attachments/sca.htm http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29SCADiagram/attachments/sca.htm rfengthe other one is for tuscany architectural layers, I guess slawsyes - high level - was attached as a zip to a mail rfengcan somebody upload it to WIKI as well? kgoodsonyes, am i right in thinking that the one you, rfeng, have done would be linked to from the higher level one? slawshigh level one was on a mail from Venkata Krishnan rfengthe one I prototyped is for SCA composite PM --|jmarino (n= [EMAIL PROTECTED] ) has joined #tuscany slawscan;t find it in the dev archive for some reason kgoodsonhave found it, i will attach to wiki slawsok - great jboynesI checked the toolkit from the incubator site into my sandbox - has anyone had a chance to look at it? slawssorry jeremy - have been out - is this the toolkit for building the website? kgoodsonwiki seems not to want to create a new page, waiting .. jboynesslaws: yes, the toolkit I mentioned last time which has been picked up by a couple of projects (including the incubator) rfengjust point to the new URL you want to place the new page, then you'll see the option to create the new page slawsjboynes: ok - ta - haven't tried it yet but can give it a whirl jboynesok jboynesanyone else interested or does anyone have any alternatives? kgoodsonyes i'm intersted but i don't really know what it buys us jboynesit's simpler than mvn slawsso, coming back to my first question, who is doing what on the website?
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
RC3 binaries tested on Windows Fedore Core1 following the documentation. All happy'n'dandy aside from a tiny doc formatting issue - if you need to respin the builds, let me know I'll put a patch up, otherwise not worth bothering with. +1 for this release Andy On 7/18/06, Pete Robbins [EMAIL PROTECTED] wrote: I have posted a 3rd candidate for the first C++ release here: http://people.apache.org/~robbinspg/RC-3 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
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
OK thanks. I see the numbering problkem and have fixed it. Cheers, On 18/07/06, Andrew Borley [EMAIL PROTECTED] wrote: RC3 binaries tested on Windows Fedore Core1 following the documentation. All happy'n'dandy aside from a tiny doc formatting issue - if you need to respin the builds, let me know I'll put a patch up, otherwise not worth bothering with. +1 for this release Andy On 7/18/06, Pete Robbins [EMAIL PROTECTED] wrote: I have posted a 3rd candidate for the first C++ release here: http://people.apache.org/~robbinspg/RC-3 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 -- Pete
Re: Moving chianti to trunk
Jeremy, Before you do this, I'd prefer to see some discussion about the functional differences between chianti and the current trunk code and how we would see these being addressed, as I said in my previous email on this subject. What do you (or others) think about this? Simon Jeremy Boynes wrote: With the vote in favour of switching, I am about to start moving chianti into trunk. I will move the current sca parts into a branch (branches/pre-chianti) and move the chianti code into trunk. I will make the version in the poms 1.0-SNAPSHOT like the SDO tree. I expect to complete this tomorrow or possibly Wed if there are build issues. If anyone has a bunch of uncommitted changes or a big patch for submission please speak up soon to avoid merge issues. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving chianti to trunk
For me the vote said it all; its good to go to switch. I think I can understand your position and probably would side with you if it wasn't for two things: We have a release so users just wanting to understand SCA and the basics of Tuscany have something stable to work with. Also this is just a switch, the head of the trunk should be preserved in a branch. Just before the switch I would recommend both have tags too. Doing this doesn't stop any discussion, it doesn't stop bringing function/code from the current head back in to Chianti; it even doesn't prevent in the case community decides we prefer to switch back. Simon Nash wrote: Jeremy, Before you do this, I'd prefer to see some discussion about the functional differences between chianti and the current trunk code and how we would see these being addressed, as I said in my previous email on this subject. What do you (or others) think about this? Simon Jeremy Boynes wrote: With the vote in favour of switching, I am about to start moving chianti into trunk. I will move the current sca parts into a branch (branches/pre-chianti) and move the chianti code into trunk. I will make the version in the poms 1.0-SNAPSHOT like the SDO tree. I expect to complete this tomorrow or possibly Wed if there are build issues. If anyone has a bunch of uncommitted changes or a big patch for submission please speak up soon to avoid merge issues. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving chianti to trunk
Yes, that would be very useful. Also we could make up some design documentation from abstracts of this discussion. Also, I am wondering if it would make sense to move Chianti in phases as the design issues are discussed, sorted out and implemented. For example we could target to have a basic HelloWorld working, which demonstrates how compose components, start the runtime, deploy a composite (or should I say module) and the client programming model to invoke the services. If this is the target then we identify the blocks that would be required for this and expedite towards making this available in the trunk. What I mean by expedite is the entire community prioritizes to work in a concerted way towards this. This Once we make this base then the community can get on to the things that interests them. There is another perspective I come to this from - assuming the user world has got a hang of SCA through our M1 release, they would be eager to follow up on the developments. If the architecture and model has changed, let it be so, but then can they try this change rightaway from a version of code from the trunk even if it is just a HelloWorld for now. Or do we ask them to wait till we get something bulkier with serveral extension types and containers plugged and working? I would say the former because we need to keep the interest sustained, especially now that we have some critiques blogging us down. Thanks. - Venkat On 7/18/06, Simon Nash [EMAIL PROTECTED] wrote: Jeremy, Before you do this, I'd prefer to see some discussion about the functional differences between chianti and the current trunk code and how we would see these being addressed, as I said in my previous email on this subject. What do you (or others) think about this? Simon Jeremy Boynes wrote: With the vote in favour of switching, I am about to start moving chianti into trunk. I will move the current sca parts into a branch (branches/pre-chianti) and move the chianti code into trunk. I will make the version in the poms 1.0-SNAPSHOT like the SDO tree. I expect to complete this tomorrow or possibly Wed if there are build issues. If anyone has a bunch of uncommitted changes or a big patch for submission please speak up soon to avoid merge issues. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-553) Add a static null SDOString to the SDOString class
Add a static null SDOString to the SDOString class -- Key: TUSCANY-553 URL: http://issues.apache.org/jira/browse/TUSCANY-553 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Environment: Windows and Linux Reporter: Geoff Winn Priority: Minor It is frequently necessary to create null strings as default parameters or to represent enmpty return values. Where these values are read only they can be references to a single class static. Add this static to the class for later use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving chianti to trunk
On Jul 17, 2006, at 11:12 PM, Venkata Krishnan wrote: Hi Jeremy, I have two patches one in SDO-Impl and another in SCA-Tools (Java2WSDL tooling) that need to be reviewed and applied to M1+. The Jiras are Tuscany-535 and Tuscany-120 respectively. But then they are to applied over M1+. Also, what is the plan for sca-tools in Chianti? SDO will not be affected (chianti uses a link to SDO from trunk). The SCA tools only seem to use the XMLUtil class from the model modules. I would suggest we move the code they need from there (the name mangling AIUI) into tools and leave them otherwise unchanged. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-553) Add a static null SDOString to the SDOString class
[ http://issues.apache.org/jira/browse/TUSCANY-553?page=all ] Geoff Winn updated TUSCANY-553: --- Attachment: TUSCANY-553.patch Patch built and tested on Red Hat Enterprise Linux 3 and Windows XP SP2 with VC7 Add a static null SDOString to the SDOString class -- Key: TUSCANY-553 URL: http://issues.apache.org/jira/browse/TUSCANY-553 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Environment: Windows and Linux Reporter: Geoff Winn Priority: Minor Attachments: TUSCANY-553.patch It is frequently necessary to create null strings as default parameters or to represent enmpty return values. Where these values are read only they can be references to a single class static. Add this static to the class for later use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
Sorry to be a stickler but I *think* I followed the docs direction with only sdo binary windows download to get samples working. If you follow that path there is no mention I *think* of adding libxml2 and the axis2c to your path. If this is correct and you are going to refresh again maybe might want to adjust this. ... not a show stopper but thought I mentioned it. BTW once I added those the sample did run. Pete Robbins wrote: I am going to refresh the distro zips in about 1 hrs time to include the fix that Sebastien found. Also some script errors. Cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk
On Jul 17, 2006, at 11:12 PM, Raymond Feng wrote: Hi, I can run the all the test cases successfully using mvn clean install. Can you post me the stacktrace? I commented out the test bodies. If I uncomment them I get: Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.061 sec FAILURE! testTransform1 (org.apache.tuscany.databinding.impl.MediatorImplTestCase) Time elapsed: 0.033 sec ERROR! org.apache.tuscany.databinding.TransformationException: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at org.apache.tuscany.databinding.trax.String2SAX.transform (String2SAX.java:47) at org.apache.tuscany.databinding.trax.String2SAX.transform (String2SAX.java:36) at org.apache.tuscany.databinding.impl.MediatorImpl.mediate (MediatorImpl.java:62) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.testTransform1( MediatorImplTestCase.java:70) testTransform2 (org.apache.tuscany.databinding.impl.MediatorImplTestCase) Time elapsed: 0.006 sec ERROR! org.apache.tuscany.databinding.TransformationException: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at org.apache.tuscany.databinding.trax.String2SAX.transform (String2SAX.java:47) at org.apache.tuscany.databinding.trax.String2SAX.transform (String2SAX.java:36) at org.apache.tuscany.databinding.impl.MediatorImpl.mediate (MediatorImpl.java:82) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.testTransform2( MediatorImplTestCase.java:79) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
Fairly sure the Requirements section says you must have LIBXML (and Iconv, zlib) on the PATH. I've just re-posted the distros to fix a couple of problems. I'd rather not re-build them for a doc issue at this stage. Cheers, On 18/07/06, Rick [EMAIL PROTECTED] wrote: Sorry to be a stickler but I *think* I followed the docs direction with only sdo binary windows download to get samples working. If you follow that path there is no mention I *think* of adding libxml2 and the axis2c to your path. If this is correct and you are going to refresh again maybe might want to adjust this. ... not a show stopper but thought I mentioned it. BTW once I added those the sample did run. Pete Robbins wrote: I am going to refresh the distro zips in about 1 hrs time to include the fix that Sebastien found. Also some script errors. Cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: Moving chianti to trunk
It is true that users who just want a working binary download have the M1 release to work with. However, the Tuscany community itself will benefit from being able to run end to end scenarios to exercise code that they contribute to the new trunk. So if we do make this switch now, I believe that we need to focus as a community on getting the new trunk into a state where it can run end to end scenarios with comparable functionality to what we had previously in M1. I'd feel more comfortable if I saw comments on this list agreeing that this should be the priority immediately following the switch. Simon Rick wrote: For me the vote said it all; its good to go to switch. I think I can understand your position and probably would side with you if it wasn't for two things: We have a release so users just wanting to understand SCA and the basics of Tuscany have something stable to work with. Also this is just a switch, the head of the trunk should be preserved in a branch. Just before the switch I would recommend both have tags too. Doing this doesn't stop any discussion, it doesn't stop bringing function/code from the current head back in to Chianti; it even doesn't prevent in the case community decides we prefer to switch back. Simon Nash wrote: Jeremy, Before you do this, I'd prefer to see some discussion about the functional differences between chianti and the current trunk code and how we would see these being addressed, as I said in my previous email on this subject. What do you (or others) think about this? Simon Jeremy Boynes wrote: With the vote in favour of switching, I am about to start moving chianti into trunk. I will move the current sca parts into a branch (branches/pre-chianti) and move the chianti code into trunk. I will make the version in the poms 1.0-SNAPSHOT like the SDO tree. I expect to complete this tomorrow or possibly Wed if there are build issues. If anyone has a bunch of uncommitted changes or a big patch for submission please speak up soon to avoid merge issues. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-554) Opposite properties are not implemented
Opposite properties are not implemented --- Key: TUSCANY-554 URL: http://issues.apache.org/jira/browse/TUSCANY-554 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-M1 Environment: all Reporter: Ed Slattery Priority: Minor Opposite properties are not implemented. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-555) XMLDocument is incomplete
XMLDocument is incomplete - Key: TUSCANY-555 URL: http://issues.apache.org/jira/browse/TUSCANY-555 Project: Tuscany Issue Type: Bug Components: C++ SDO Reporter: Ed Slattery Priority: Minor XMLdocument is missing APIs such as getEncoding which libxml cannot supply. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-556) Investigation of XMLBeans, XBeans etc
Investigation of XMLBeans, XBeans etc - Key: TUSCANY-556 URL: http://issues.apache.org/jira/browse/TUSCANY-556 Project: Tuscany Issue Type: Wish Reporter: Ed Slattery Priority: Minor Fix For: Cpp-M1 Find out how they interoperate and whether there is synergy to leverage or interfacing to write. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-557) SDO documentation
SDO documentation - Key: TUSCANY-557 URL: http://issues.apache.org/jira/browse/TUSCANY-557 Project: Tuscany Issue Type: Task Reporter: Ed Slattery Priority: Minor Fix For: Cpp-M1 Design doc and user guides - simpler than the spec but similar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-558) refactor for mutli-language
refactor for mutli-language --- Key: TUSCANY-558 URL: http://issues.apache.org/jira/browse/TUSCANY-558 Project: Tuscany Issue Type: Wish Components: C++ SDO Reporter: Ed Slattery Why not make the C++ library a core for others to build on? What about C and COBOL? Why not a c# wrapper? This is a placeholder for those thoughts -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-559) Axis2 integration
Axis2 integration - Key: TUSCANY-559 URL: http://issues.apache.org/jira/browse/TUSCANY-559 Project: Tuscany Issue Type: Improvement Components: C++ SDO Reporter: Ed Slattery Fix For: Cpp-M1 We provide a utility to take and SDO graph and turn it into an Axiom graph. Thats done by serialization to XML - but would be better done by having a AxiomWriter, just like we have an XMLWriter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-560) DAS: managedtx attribute can default to false
DAS: managedtx attribute can default to false - Key: TUSCANY-560 URL: http://issues.apache.org/jira/browse/TUSCANY-560 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Brent Daniel Assigned To: Brent Daniel If ConnectionInfo is specified, but the managedtx attribute is not, managedtx will default to false instead of true. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Proprietary BEA Dependency in Tuscany ?
Hi I'm trying to run java/testing/tomcat/bigbank and I found it requires the following dependency : Missing: -- 1) javax.xml:jsr173:jar:1.0 Try downloading the file manually from: http://ftpna2.bea.com/pub/downloads/jsr173.jar Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=jsr173 -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file Looking at the jar file, looks like it has some proprietary code from BEA and also some license documents inside /** * This interface declares a simple filter interface that one can * create to filter XMLEventReaders * @version 1.0 * @author Copyright (c) 2003 by BEA Systems. All Rights Reserved. */ Is this ok for us to have these kind of dependencies ? or even ask people to download proprietary jar files in order to run parts of tuscany ? -- Regards Luciano Resende
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
Hi again! RC3a binaries tested on Windows and Fedore Core1. Still happy'n'dandy. +1 from me Andy On 7/18/06, Pete Robbins [EMAIL PROTECTED] wrote: I have refreshed the distros to include a couple of bug fixes and some doc fixes. Please vote on the release candidate available here: http://people.apache.org/~robbinspg/RC-3a Cheers, On 18/07/06, Pete Robbins [EMAIL PROTECTED] wrote: I have posted a 3rd candidate for the first C++ release here: http://people.apache.org/~robbinspg/RC-3 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 -- Pete
[PATCH] Tuscany 560, DAS managedtx attribute can default to false
The attached patch adds a default of true for the managedtx attribute. Brent Index: src/main/resources/config.xsd === --- src/main/resources/config.xsd (revision 423097) +++ src/main/resources/config.xsd (working copy) @@ -35,7 +35,7 @@ xsd:complexType name=ConnectionInfo xsd:attribute name=dataSource type=xsd:string/ - xsd:attribute name=managedtx type=xsd:boolean/ + xsd:attribute name=managedtx type=xsd:boolean default=true/ /xsd:complexType xsd:complexType name=Command - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-561) SDO Sample build.cmd cannot find mspdb71.dll
SDO Sample build.cmd cannot find mspdb71.dll Key: TUSCANY-561 URL: http://issues.apache.org/jira/browse/TUSCANY-561 Project: Tuscany Issue Type: Bug Components: C++ Build, C++ SDO Affects Versions: Cpp-current, Cpp-M1 Environment: Windows Reporter: Andrew Borley Priority: Minor SDO Sample build.cmd needs to call vcvars32 to set up the build environment -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk
Hi, I ran into this issue once inside Eclipse but cannot reproduce it any more. It's probably related to some settings of the SAX/DOM features on namespace handling. I'll investigate. What JDK do you use? I tried IBM and SUN JDKs and both are fine. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 18, 2006 6:37 AM Subject: Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk On Jul 17, 2006, at 11:12 PM, Raymond Feng wrote: Hi, I can run the all the test cases successfully using mvn clean install. Can you post me the stacktrace? I commented out the test bodies. If I uncomment them I get: Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.061 sec FAILURE! testTransform1 (org.apache.tuscany.databinding.impl.MediatorImplTestCase) Time elapsed: 0.033 sec ERROR! org.apache.tuscany.databinding.TransformationException: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at org.apache.tuscany.databinding.trax.String2SAX.transform (String2SAX.java:47) at org.apache.tuscany.databinding.trax.String2SAX.transform (String2SAX.java:36) at org.apache.tuscany.databinding.impl.MediatorImpl.mediate (MediatorImpl.java:62) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.testTransform1( MediatorImplTestCase.java:70) testTransform2 (org.apache.tuscany.databinding.impl.MediatorImplTestCase) Time elapsed: 0.006 sec ERROR! org.apache.tuscany.databinding.TransformationException: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at org.apache.tuscany.databinding.trax.String2SAX.transform (String2SAX.java:47) at org.apache.tuscany.databinding.trax.String2SAX.transform (String2SAX.java:36) at org.apache.tuscany.databinding.impl.MediatorImpl.mediate (MediatorImpl.java:82) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.testTransform2( MediatorImplTestCase.java:79) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-561) SDO Sample build.cmd cannot find mspdb71.dll
[ http://issues.apache.org/jira/browse/TUSCANY-561?page=all ] Andrew Borley updated TUSCANY-561: -- Attachment: TUSCANY-561.patch Adds the vcvars32 call and makes sure the deploy/bin directories exist SDO Sample build.cmd cannot find mspdb71.dll Key: TUSCANY-561 URL: http://issues.apache.org/jira/browse/TUSCANY-561 Project: Tuscany Issue Type: Bug Components: C++ Build, C++ SDO Affects Versions: Cpp-current, Cpp-M1 Environment: Windows Reporter: Andrew Borley Priority: Minor Attachments: TUSCANY-561.patch SDO Sample build.cmd needs to call vcvars32 to set up the build environment -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk
On Jul 18, 2006, at 8:46 AM, Raymond Feng wrote: Hi, I ran into this issue once inside Eclipse but cannot reproduce it any more. It's probably related to some settings of the SAX/DOM features on namespace handling. I'll investigate. What JDK do you use? I tried IBM and SUN JDKs and both are fine. $ java -version java version 1.5.0_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) on OSX 10.4.7 -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
DOH! minor problem with the Windows src distro where a directory structure is missing from the sample :-( Re-creating distro and will update in 1hr. -- Pete
Re: Proprietary BEA Dependency in Tuscany ?
StAX is a JSR and also part of Java 6. On 7/18/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi I'm trying to run java/testing/tomcat/bigbank and I found it requires the following dependency : Missing: -- 1) javax.xml:jsr173:jar:1.0 Try downloading the file manually from: http://ftpna2.bea.com/pub/downloads/jsr173.jar Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=jsr173 -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file Looking at the jar file, looks like it has some proprietary code from BEA and also some license documents inside /** * This interface declares a simple filter interface that one can * create to filter XMLEventReaders * @version 1.0 * @author Copyright (c) 2003 by BEA Systems. All Rights Reserved. */ Is this ok for us to have these kind of dependencies ? or even ask people to download proprietary jar files in order to run parts of tuscany ? -- Regards Luciano Resende -- Yang ZHONG
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
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
[jira] Created: (TUSCANY-562) Robustness of type inheritance
Robustness of type inheritance -- Key: TUSCANY-562 URL: http://issues.apache.org/jira/browse/TUSCANY-562 Project: Tuscany Issue Type: Bug Affects Versions: Cpp-M1 Reporter: Ed Slattery Priority: Minor You can define a type as its own parent. The heirarchy from the type upwards should be checked and this should be thrown out - -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-563) robustness of addType, addPropertyToType
robustness of addType, addPropertyToType Key: TUSCANY-563 URL: http://issues.apache.org/jira/browse/TUSCANY-563 Project: Tuscany Issue Type: Bug Components: C++ SDO Reporter: Ed Slattery Priority: Minor These accept null pointers in all the parameters, but handle some of them badly. They should throw exceptions for null TypeName and null PropertyName , but suceed for null URIs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving chianti to trunk
-0 on ordaining some kind of official priority for functional equivalency with M1 -- my opinion is that at this stage in the project (ie, incubation), developer community is significantly more important than user community. I'd rather we take a more free form stance with respect to encouraging development in areas people find compelling (including of course, the porting of functionality from M1). On 7/18/06, Simon Nash [EMAIL PROTECTED] wrote: It is true that users who just want a working binary download have the M1 release to work with. However, the Tuscany community itself will benefit from being able to run end to end scenarios to exercise code that they contribute to the new trunk. So if we do make this switch now, I believe that we need to focus as a community on getting the new trunk into a state where it can run end to end scenarios with comparable functionality to what we had previously in M1. I'd feel more comfortable if I saw comments on this list agreeing that this should be the priority immediately following the switch. Simon Rick wrote: For me the vote said it all; its good to go to switch. I think I can understand your position and probably would side with you if it wasn't for two things: We have a release so users just wanting to understand SCA and the basics of Tuscany have something stable to work with. Also this is just a switch, the head of the trunk should be preserved in a branch. Just before the switch I would recommend both have tags too. Doing this doesn't stop any discussion, it doesn't stop bringing function/code from the current head back in to Chianti; it even doesn't prevent in the case community decides we prefer to switch back. Simon Nash wrote: Jeremy, Before you do this, I'd prefer to see some discussion about the functional differences between chianti and the current trunk code and how we would see these being addressed, as I said in my previous email on this subject. What do you (or others) think about this? Simon Jeremy Boynes wrote: With the vote in favour of switching, I am about to start moving chianti into trunk. I will move the current sca parts into a branch (branches/pre-chianti) and move the chianti code into trunk. I will make the version in the poms 1.0-SNAPSHOT like the SDO tree. I expect to complete this tomorrow or possibly Wed if there are build issues. If anyone has a bunch of uncommitted changes or a big patch for submission please speak up soon to avoid merge issues. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Re: SDO Samples
Robbie, sorry for the slow response, some comments below ... On 7/14/06, Robbie J Minshall [EMAIL PROTECTED] wrote: These comments are with regard to comments on the AccessingDataObjectsUsingXPath sample. There are also some general questions about the roles of the end user of the DataObjects vrs DAS implementations regarding ChangeSummary logging. DATA GRAPH CREATION Yes there are three creation scenarios brought up here . . . # 1. Creation of a DataObject representing a DataGraph # 2. Creation of a DataObject # 3. Use of SDOUtil to create a DataGraph My current view is to keep this sample as close to the spec example as possible without being overly confusing. With this in mind I think it best if the sample just use a DataObject and provide comments explaining the confusion in the spec regarding #1. +1 for that Then the sample should reference a codeSnipet example which goes over #1 and #3. The alternatives seem to either vary too much from the specification example which this sample is supposed to mirror or become overly confusing. I mostly feel this way because the point of this particular sample was to demonstrate how to use xpath (though as you mention it is non standard xpath ) with SDO not the creation of DataGraphs. . . . thoughts ? ok, so as I understand it the meaning of codeSnippet example here is that you have 3 kinds of examples, 1) mirroring as close as possible the examples in the 2.0.1 spec beginning at page 123; 2) code snippets harvested from all over the spec and 3) code samples from various publications, and the #1 and #3 variant of the xpath sample would be hived off to the code snippet set, with suitable comments to indicate the tricky issues. If so, then +1 for that too. With regard to the stages at which the samples are encountered this is somewhat hard to control but I can certainly add some comments into the javadoc explaining that this sample delves into a somewhat murky area of the 2.0.1 specification. LACK OF A DAS but we don't have a DAS here I would disagree here. A DAS is simply something that is tasked with creating DataObjects and/or defining the Types of those DataObjects. This is pretty much the extent which the SDO specification defines what a DAS is, or the state which a DataObject will be in upon creation. In this sample the XMLHelper is in fact providing a DAS implementation. WHETHER OR NOT TO ENABLE LOGGING IN THE SAMPLE It is not a big deal to enable logging though I think that there is some confusion here about what roles should invoke the begin/endLogging methods on ChangeSummary. If we put it in this sample users will think that they are responsible for setting the state of logging where at least the RDB DAS feels like it is their responsibility not the users. Are the users responsible for enabling and disabling ChangeSummary logging or is that to be up to the specific DAS implementations in use ? Perhaps the SDO specification should define what state it expects the ChangeSummary logging to be in for created DataObjects in order to avoid inconsistencies between DAS implementations. ok, if you consider the XML helper to be a DAS, as you say there are no guidelines on behaviour for DASs, and I would guess a DAS designer would want to turn change logging on or off by default according to whether the data source lends itself to selective updating, so I think that this makes it natural for the XMLHelper to return graphs with Change Logging switched off In general the end user of DataObjects should not have to be aware of what DAS created, or what DAS is going to persist the DataObject in order to determine the APIs to be used. My guess is that sometimes a user will be aware of the DAS and sometimes not. Whatever the case the user can have expectations set by the specific environment they are working in; so if its close to the DAS, then the DAS sets the policy, if the DAS is abstracted away, then the abstracted environment sets the policy (which maywell be that change logging is always on), but I don't think we can envisage enough commanality between all DASs, exisiting or future, to take a stab at specifying the logging state for every DAS. Robbie -- Best Regards Kelvin
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
I just got looking at 3a on XP only. Here are some things I noticed: On the SDO example I think is now runclient ... the usage if you just enter says Calc For building the source I needed to set ICONV_HOME This maybe be a requirement of LIBXML2 but it would be nice if it was out front. SAX2Namespaces.cpp cl.exe /nologo /MD /W3 /GX /O2 /I ..\..\..\runtime\core\src /I E:\env\tuscanycpp\libxml2-2.6.20.win32\include /I \include /I \include /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D SDO_EXPORTS /Fo.\Release\\ /Fd.\Release\\ /FD /c ..\..\..\runtime\core\src\commonj\sdo\SAX2Parser.cpp cl : Command line warning D9035 : option 'GX' has been deprecated and will be removed in a future release cl : Command line warning D9036 : use 'EHsc' instead of 'GX' SAX2Parser.cpp E:\env\tuscanycpp\libxml2-2.6.20.win32\include\libxml/encoding.h(28) : fatal error C1083: Cannot open include file: 'iconv.h': No such file or directory NMAKE : fatal error U1077: 'e:\bin\Microsoft Visual Studio 8\VC\BIN\cl.exe' : return code '0x2' Stop. -- I trust someone else has looked at linux distro Over all there has been a huge improvement since the first release candidate. +1 for release from me. Pete Robbins 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, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk
Hi, Jeremy.
Can you try this patch? It seems that in your environment the SAX XMLReader
may have a different feature settings on namespaces or
namespace-prefixes. With the patch, I enforce them by:
reader.setFeature(http://xml.org/sax/features/namespaces;, true); //
Default to true
reader.setFeature(http://xml.org/sax/features/namespace-prefixes;, false);
// Default to false
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, July 18, 2006 8:59 AM
Subject: Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk
On Jul 18, 2006, at 8:46 AM, Raymond Feng wrote:
Hi,
I ran into this issue once inside Eclipse but cannot reproduce it any
more. It's probably related to some settings of the SAX/DOM features on
namespace handling. I'll investigate.
What JDK do you use? I tried IBM and SUN JDKs and both are fine.
$ java -version
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)
on OSX 10.4.7
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index:
databinding-framework/src/main/java/org/apache/tuscany/databinding/PushStyleTransformer.java
===
---
databinding-framework/src/main/java/org/apache/tuscany/databinding/PushStyleTransformer.java
(revision 422978)
+++
databinding-framework/src/main/java/org/apache/tuscany/databinding/PushStyleTransformer.java
(working copy)
@@ -1,47 +0,0 @@
-/**
- *
- * Copyright 2006 The Apache Software Foundation or its licensors as applicable
- *
- * Licensed under the Apache License, Version 2.0 (the License);
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an AS IS BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.tuscany.databinding;
-
-
-/**
- * A data pumper pushes data from its source into the sink
- * @param S
- * @param R
- */
-public interface PushStyleTransformerS, R {
-/**
- * @param source
- * @param sink
- * @param context
- */
-public void transform(S source, R sink, TransformationContext context);
-
-/**
- * @return
- */
-public ClassS getSourceType();
-
-/**
- * @return
- */
-public ClassR getSinkType();
-
-/**
- * @return
- */
-public int getWeight();
-}
Index:
databinding-framework/src/main/java/org/apache/tuscany/databinding/trax/InputSource2SAX.java
===
---
databinding-framework/src/main/java/org/apache/tuscany/databinding/trax/InputSource2SAX.java
(revision 422978)
+++
databinding-framework/src/main/java/org/apache/tuscany/databinding/trax/InputSource2SAX.java
(working copy)
@@ -32,6 +32,8 @@
public void transform(InputSource source, ContentHandler target,
TransformationContext context) {
try {
XMLReader reader = XMLReaderFactory.createXMLReader();
+reader.setFeature(http://xml.org/sax/features/namespaces;, true);
+
reader.setFeature(http://xml.org/sax/features/namespace-prefixes;, false);
reader.setContentHandler(target);
reader.parse(source);
} catch (Exception e) {
Index:
databinding-framework/src/main/java/org/apache/tuscany/databinding/trax/Reader2SAX.java
===
---
databinding-framework/src/main/java/org/apache/tuscany/databinding/trax/Reader2SAX.java
(revision 422978)
+++
databinding-framework/src/main/java/org/apache/tuscany/databinding/trax/Reader2SAX.java
(working copy)
@@ -23,8 +23,6 @@
import org.apache.tuscany.databinding.TransformationException;
import org.xml.sax.ContentHandler;
import org.xml.sax.InputSource;
-import org.xml.sax.XMLReader;
-import org.xml.sax.helpers.XMLReaderFactory;
/**
* Transform XML string to SAX
@@ -33,9 +31,7 @@
public class Reader2SAX implements PushTransformerReader, ContentHandler {
public void transform(Reader source, ContentHandler target,
TransformationContext context) {
try {
-XMLReader reader = XMLReaderFactory.createXMLReader();
-reader.setContentHandler(target);
-reader.parse(new InputSource(source));
+new InputSource2SAX().transform(new InputSource(source), target,
context);
} catch (Exception e) {
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
Rick wrote: I just got looking at 3a on XP only. Here are some things I noticed: On the SDO example I think is now runclient ... the usage if you just enter says Calc For building the source I needed to set ICONV_HOME This maybe be a requirement of LIBXML2 but it would be nice if it was out front. SAX2Namespaces.cpp cl.exe /nologo /MD /W3 /GX /O2 /I ..\..\..\runtime\core\src /I E:\env\tuscanycpp\libxml2-2.6.20.win32\include /I \include /I \include /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D SDO_EXPORTS /Fo.\Release\\ /Fd.\Release\\ /FD /c ..\..\..\runtime\core\src\commonj\sdo\SAX2Parser.cpp cl : Command line warning D9035 : option 'GX' has been deprecated and will be removed in a future release cl : Command line warning D9036 : use 'EHsc' instead of 'GX' SAX2Parser.cpp E:\env\tuscanycpp\libxml2-2.6.20.win32\include\libxml/encoding.h(28) : fatal error C1083: Cannot open include file: 'iconv.h': No such file or directory NMAKE : fatal error U1077: 'e:\bin\Microsoft Visual Studio 8\VC\BIN\cl.exe' : return code '0x2' Stop. -- I trust someone else has looked at linux distro Over all there has been a huge improvement since the first release candidate. +1 for release from me. Pete Robbins 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, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I just tested RC-3b on Redhat Enterprise Linux 4. The docs look good and the samples work great, both with the source and binary distributions. In the future we may want to remove from the binary distribution some of the test programs under bin/test, but this is not really a problem. With all the improvements since the first release candidate and the new SDO sample, the distributions look really good now. +1 to release from me! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Patch for databinding was: Re: Moving chianti to trunk
On Jul 18, 2006, at 10:18 AM, Raymond Feng wrote: Hi, Jeremy. Can you try this patch? It seems that in your environment the SAX XMLReader may have a different feature settings on namespaces or namespace-prefixes. With the patch, I enforce them by: reader.setFeature(http://xml.org/sax/features/namespaces;, true); // Default to true reader.setFeature(http://xml.org/sax/features/namespace-prefixes;, false); // Default to false Thanks, Thanks - it works now Patch applied. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proprietary BEA Dependency in Tuscany ?
But the dependency we are currently using is not opensource, is this right ? - Luciano On 7/18/06, Yang ZHONG [EMAIL PROTECTED] wrote: StAX is a JSR and also part of Java 6. On 7/18/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi I'm trying to run java/testing/tomcat/bigbank and I found it requires the following dependency : Missing: -- 1) javax.xml:jsr173:jar:1.0 Try downloading the file manually from: http://ftpna2.bea.com/pub/downloads/jsr173.jar Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=jsr173 -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file Looking at the jar file, looks like it has some proprietary code from BEA and also some license documents inside /** * This interface declares a simple filter interface that one can * create to filter XMLEventReaders * @version 1.0 * @author Copyright (c) 2003 by BEA Systems. All Rights Reserved. */ Is this ok for us to have these kind of dependencies ? or even ask people to download proprietary jar files in order to run parts of tuscany ? -- Regards Luciano Resende -- Yang ZHONG -- Regards Luciano Resende
Re: Proprietary BEA Dependency in Tuscany ?
On Jul 18, 2006, at 10:27 AM, Luciano Resende wrote: But the dependency we are currently using is not opensource, is this right ? In general we use the stax-api JAR from Codehaus for this; that claims to be the RI and is open source. I don't know where this dependency in bigbank is coming from. If we are redistributing this jar we need to investigate the terms associated with it to make sure we are complying. It may be easier just to exclude it and replace it with stax-api. Note these are also just the APIs - the StAX implementation we are using is Woodstox (again from Codehaus) which is open source. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-561) SDO Sample build.cmd cannot find mspdb71.dll
[ http://issues.apache.org/jira/browse/TUSCANY-561?page=all ] Pete Robbins resolved TUSCANY-561. -- Fix Version/s: Cpp-current Resolution: Fixed patch applied SDO Sample build.cmd cannot find mspdb71.dll Key: TUSCANY-561 URL: http://issues.apache.org/jira/browse/TUSCANY-561 Project: Tuscany Issue Type: Bug Components: C++ Build, C++ SDO Affects Versions: Cpp-current, Cpp-M1 Environment: Windows Reporter: Andrew Borley Priority: Minor Fix For: Cpp-current Attachments: TUSCANY-561.patch SDO Sample build.cmd needs to call vcvars32 to set up the build environment -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-524) ant for building scagen not run on windows
[ http://issues.apache.org/jira/browse/TUSCANY-524?page=all ] Pete Robbins closed TUSCANY-524. Fix Version/s: Cpp-current Resolution: Fixed ant for building scagen not run on windows -- Key: TUSCANY-524 URL: http://issues.apache.org/jira/browse/TUSCANY-524 Project: Tuscany Issue Type: Bug Components: C++ Build Affects Versions: Cpp-current Reporter: Ed Slattery Assigned To: Pete Robbins Priority: Minor Fix For: Cpp-current The windows build script does not run the ant task to build scagen - this would do it... cd ..\..\tools\scagen ant cd ..\..\projects\tuscany_sca cd tuscany_sca_test nmake -f tuscany_sca_test.mak ALL cd .. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proprietary BEA Dependency in Tuscany ?
It may be easier just to replace it but if people prefer to have license clarification, let me know and I will get it fixed. The intent with the jar was not to have a proprietary license and was probably an oversight in the Codehaus distro. Jim On Jul 18, 2006, at 10:46 AM, Jeremy Boynes wrote: On Jul 18, 2006, at 10:27 AM, Luciano Resende wrote: But the dependency we are currently using is not opensource, is this right ? In general we use the stax-api JAR from Codehaus for this; that claims to be the RI and is open source. I don't know where this dependency in bigbank is coming from. If we are redistributing this jar we need to investigate the terms associated with it to make sure we are complying. It may be easier just to exclude it and replace it with stax-api. Note these are also just the APIs - the StAX implementation we are using is Woodstox (again from Codehaus) which is open source. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test coverage tool
I've been using Clover as a test coverage tool and have found it quite useful (http://www.cenqua.com/clover/) Licensing is free for open source projects and it has plugins for popular IDEs so it can be run as part of a standard code-test cycle (it can be toggled on and off). Although it is a bit indiscriminate (e.g. it flags getters and setters), I find it particularly helpful when writing test cases since it highlights untested code in the IDE. I have attached a sample report I just ran that shows the high level statistics from a run. When we get around to creating integration build infrastructure I would like us to examine using this and generating reports that are posted to a project status page since it is a good indication of areas that need work. It would also been nice to run a dependency analyzer periodically over the codebase to avoid cycles in our package structures. I've seen people use JDepend or SonarJ. Does anyone have experience with either of these two or an alternative? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test coverage tool
Hi Jim, I don't see the attached report. --Kevin Jim Marino wrote: I've been using Clover as a test coverage tool and have found it quite useful (http://www.cenqua.com/clover/) Licensing is free for open source projects and it has plugins for popular IDEs so it can be run as part of a standard code-test cycle (it can be toggled on and off). Although it is a bit indiscriminate (e.g. it flags getters and setters), I find it particularly helpful when writing test cases since it highlights untested code in the IDE. I have attached a sample report I just ran that shows the high level statistics from a run. When we get around to creating integration build infrastructure I would like us to examine using this and generating reports that are posted to a project status page since it is a good indication of areas that need work. It would also been nice to run a dependency analyzer periodically over the codebase to avoid cycles in our package structures. I've seen people use JDepend or SonarJ. Does anyone have experience with either of these two or an alternative? Jim - 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: Proprietary BEA Dependency in Tuscany ?
Looks like the /java/testing/tomcat/readme.htm describes how to get the dependencies from XML Bean Distribution, and what we need is just to make sure the message from running mvn does not point to bea website. If I download the file from the place on the documentation, and install it with the command below, things still work. mvn install:install-file -Dfile=jsr173_1.0_api.jar -DgroupId=javax.xml-DartifactId=jsr173 -Dversion= 1.0 -Dpackaging=jar So, looks like the only changes we need is on the pom.xml ? to direct people to right place when the build fails ? if that's the case I'll create JIRA and try to take care of this. - Luciano On 7/18/06, Jim Marino [EMAIL PROTECTED] wrote: It may be easier just to replace it but if people prefer to have license clarification, let me know and I will get it fixed. The intent with the jar was not to have a proprietary license and was probably an oversight in the Codehaus distro. Jim On Jul 18, 2006, at 10:46 AM, Jeremy Boynes wrote: On Jul 18, 2006, at 10:27 AM, Luciano Resende wrote: But the dependency we are currently using is not opensource, is this right ? In general we use the stax-api JAR from Codehaus for this; that claims to be the RI and is open source. I don't know where this dependency in bigbank is coming from. If we are redistributing this jar we need to investigate the terms associated with it to make sure we are complying. It may be easier just to exclude it and replace it with stax-api. Note these are also just the APIs - the StAX implementation we are using is Woodstox (again from Codehaus) which is open source. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards Luciano Resende
[jira] Closed: (TUSCANY-552) CompanyWeb sample problem
[ http://issues.apache.org/jira/browse/TUSCANY-552?page=all ] Kevin Williams closed TUSCANY-552. -- Fix Version/s: Java-Mx Resolution: Fixed Verified with revision: 420213 CompanyWeb sample problem - Key: TUSCANY-552 URL: http://issues.apache.org/jira/browse/TUSCANY-552 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Brent Daniel Assigned To: Brent Daniel Fix For: Java-Mx The companyWeb sample is not working. It looks like its config file was not updated in response to DAS changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-560) DAS: managedtx attribute can default to false
[ http://issues.apache.org/jira/browse/TUSCANY-560?page=all ] Kevin Williams closed TUSCANY-560. -- Fix Version/s: Java-Mx Resolution: Fixed Verified with revision: 420213 DAS: managedtx attribute can default to false - Key: TUSCANY-560 URL: http://issues.apache.org/jira/browse/TUSCANY-560 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Brent Daniel Assigned To: Brent Daniel Fix For: Java-Mx If ConnectionInfo is specified, but the managedtx attribute is not, managedtx will default to false instead of true. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test coverage tool
Hi, I tried Clover with Tuscany M1 before and the report is nice. I thought it requires a license. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 18, 2006 11:27 AM Subject: Test coverage tool I've been using Clover as a test coverage tool and have found it quite useful (http://www.cenqua.com/clover/) Licensing is free for open source projects and it has plugins for popular IDEs so it can be run as part of a standard code-test cycle (it can be toggled on and off). Although it is a bit indiscriminate (e.g. it flags getters and setters), I find it particularly helpful when writing test cases since it highlights untested code in the IDE. I have attached a sample report I just ran that shows the high level statistics from a run. When we get around to creating integration build infrastructure I would like us to examine using this and generating reports that are posted to a project status page since it is a good indication of areas that need work. It would also been nice to run a dependency analyzer periodically over the codebase to avoid cycles in our package structures. I've seen people use JDepend or SonarJ. Does anyone have experience with either of these two or an alternative? Jim - 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: Proprietary BEA Dependency in Tuscany ?
On Jul 18, 2006, at 11:41 AM, Luciano Resende wrote: Looks like the /java/testing/tomcat/readme.htm describes how to get the dependencies from XML Bean Distribution, and what we need is just to make sure the message from running mvn does not point to bea website. If I download the file from the place on the documentation, and install it with the command below, things still work. mvn install:install-file -Dfile=jsr173_1.0_api.jar -DgroupId=javax.xml-DartifactId=jsr173 -Dversion= 1.0 -Dpackaging=jar So, looks like the only changes we need is on the pom.xml ? to direct people to right place when the build fails ? if that's the case I'll create JIRA and try to take care of this. Rather than add a separate dependency, please can we just exclude this one and use stax-api. That should just be pom changes as well. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test coverage tool
They have a free license for open source projects. I just got mine. Jim On Jul 18, 2006, at 11:59 AM, Raymond Feng wrote: Hi, I tried Clover with Tuscany M1 before and the report is nice. I thought it requires a license. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 18, 2006 11:27 AM Subject: Test coverage tool I've been using Clover as a test coverage tool and have found it quite useful (http://www.cenqua.com/clover/) Licensing is free for open source projects and it has plugins for popular IDEs so it can be run as part of a standard code-test cycle (it can be toggled on and off). Although it is a bit indiscriminate (e.g. it flags getters and setters), I find it particularly helpful when writing test cases since it highlights untested code in the IDE. I have attached a sample report I just ran that shows the high level statistics from a run. When we get around to creating integration build infrastructure I would like us to examine using this and generating reports that are posted to a project status page since it is a good indication of areas that need work. It would also been nice to run a dependency analyzer periodically over the codebase to avoid cycles in our package structures. I've seen people use JDepend or SonarJ. Does anyone have experience with either of these two or an alternative? Jim -- -- - 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]
[jira] Updated: (TUSCANY-433) User provided CUD with partial update results in NPE
[ http://issues.apache.org/jira/browse/TUSCANY-433?page=all ] Darius S. DeJesus updated TUSCANY-433: -- Attachment: Tuscany-433 Tuscany-433 was solved by recent changes to the code base. This is a refractored version of the original tests, moved to CorrectedDefects.java, and with all the associated XML files updated properly. User provided CUD with partial update results in NPE Key: TUSCANY-433 URL: http://issues.apache.org/jira/browse/TUSCANY-433 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-Mx Reporter: Kevin Williams Assigned To: Kevin Williams Attachments: Tuscany-433, Tuscany-433 ApplyChanges with partil userprovided update statement fails with NPE. Test case DefectTests.readModifyAply and readModifyApply1() demonstrate this bug -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jMock vs. EasyMock
In chianti we had started to play with jMock as a mock object test framework but after living with it for a while I started to get frustrated with it. I saw that Raymond's databinding framework was using EasyMock and tried converting over one of the jMock testcases. It was fairly simple to do and easymock lived up to its name. I think we should pick just one framework and would suggest we that it's easymock - does anyone have any other preference or comments? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jMock vs. EasyMock
On Jul 18, 2006, at 1:32 PM, Jeremy Boynes wrote: In chianti we had started to play with jMock as a mock object test framework but after living with it for a while I started to get frustrated with it. I saw that Raymond's databinding framework was using EasyMock and tried converting over one of the jMock testcases. It was fairly simple to do and easymock lived up to its name. I think we should pick just one framework and would suggest we that it's easymock - does anyone have any other preference or comments? The Celtix binding also used EasyMock. I don't have any preference other than we should pick one. I'm happy to go with EasyMock as long as people are willing to help out converting the existing unit tests. Jim -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test coverage tool
Looks like the mailing list strips attachments. Is there a way to send this and not have it removed? Jim On Jul 18, 2006, at 11:36 AM, Kevin Williams wrote: Hi Jim, I don't see the attached report. --Kevin Jim Marino wrote: I've been using Clover as a test coverage tool and have found it quite useful (http://www.cenqua.com/clover/) Licensing is free for open source projects and it has plugins for popular IDEs so it can be run as part of a standard code-test cycle (it can be toggled on and off). Although it is a bit indiscriminate (e.g. it flags getters and setters), I find it particularly helpful when writing test cases since it highlights untested code in the IDE. I have attached a sample report I just ran that shows the high level statistics from a run. When we get around to creating integration build infrastructure I would like us to examine using this and generating reports that are posted to a project status page since it is a good indication of areas that need work. It would also been nice to run a dependency analyzer periodically over the codebase to avoid cycles in our package structures. I've seen people use JDepend or SonarJ. Does anyone have experience with either of these two or an alternative? Jim - --- - 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]
Dependency on Woodstox
The following classes have a dependency on classes from com.ctc: ./databinding-framework/src/main/java/org/apache/tuscany/databinding/ xml/Node2XMLStreamReader.java ./databinding-framework/src/main/java/org/apache/tuscany/databinding/ xml/XMLStreamReader2Node.java This couples us to the Woodstox implementation of StAX rather than just using the StAX APIs. Is there a way this can be avoided? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Data binding extensions and changes to the SCA spec
I would like to get started on support for for XPath in SCDL as it is part of the recent SCA spec changes. This will likely require changes to the loader infrastructure and in particular StringParserPropertyFactory. Instead of having a PropertyFactory create an ObjectFactory responsible for returning a value that is injected into a component implementation instance, we will need to have a more flexible approach as property values may now be based off of XPath expressions to composite properties. What I would like to propose is that we have creation of the ObjectFactory for the property handled by the builder in much the same way as it handles wires. I think we can leverage the data transformation service for this. In this case, the builder will be given a representation of the parsed XML, probably DOM. If the property value was an XPath expression, the builder will have to use an XPath engine to evaluate and retrieve this actual value (Jaxen?) represented as a Node. The builder will then in turn use the transformation service to create a bound type. The builder will subsequently create an ObjectFactory for the bound type responsible for injecting on the target component implementation instance. The specific kind of ObjectFactory will depend on the kind of property it is: - If it is immutable, the builder will use a SingletonObjectFactory - If it is mutable, but the property is configured as safe (i.e. the component does not mutate it), the builder will use a SingletonObjectFactory). We can also assume by default values are safe unless explicitly marked. - If it is mutable, marked not safe, and Cloneable, a CloningObjectFactory is used which clones on getInstance() -If it is mutable, marked not safe and is not Cloneable, the builder avoids the call to the transformation service and instead uses an ObjectFactory which calls out the to transformation service on every getInstance() invoke. For some implementation types, a builder may not want to use ObjectFactory (perhaps the implementation just takes a DOM or some other format). In that case, the builder would be free to use the transformation service or not. Raymond, does this sound like it would fit with the transformation service? If so, I think we need to look at incorporating the base data transformation framework into SPI and core. I'd also be willing to work on an XStream binding extension which would enable handling of basic POJO binding. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jMock vs. EasyMock
Hi, It seems that EasyMock is easier to understand and use. It takes a record and play approach on the real methods. That's why I decided to get it a try. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 18, 2006 1:32 PM Subject: jMock vs. EasyMock In chianti we had started to play with jMock as a mock object test framework but after living with it for a while I started to get frustrated with it. I saw that Raymond's databinding framework was using EasyMock and tried converting over one of the jMock testcases. It was fairly simple to do and easymock lived up to its name. I think we should pick just one framework and would suggest we that it's easymock - does anyone have any other preference or comments? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency on Woodstox
Hi, The dependencies to woodstox impl is for the Proof-of-Concept. We can write our own implementations or leverage some indepenedent ulitilies such as StaxUtils. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 18, 2006 1:56 PM Subject: Dependency on Woodstox The following classes have a dependency on classes from com.ctc: ./databinding-framework/src/main/java/org/apache/tuscany/databinding/ xml/Node2XMLStreamReader.java ./databinding-framework/src/main/java/org/apache/tuscany/databinding/ xml/XMLStreamReader2Node.java This couples us to the Woodstox implementation of StAX rather than just using the StAX APIs. Is there a way this can be avoided? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
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
[C++] Fwd: xmlbeanscxx proposal
It appears that a C++ version of XMLBeans is much closer to being reality at Apache -- see the post below forwarded from [EMAIL PROTECTED] Tuscany C++ folks, has there been consideration of leveraging an XML mapping technology like this? I know the support for multiple databinding frameworks tends to be important in Java-land, so it seemed at least worth asking. This could also be used in the SCA model loading code, though perhaps everyone is happy with the current use of SDO there. If there is interest, please cross-post back to [EMAIL PROTECTED] It'd be great to see more leverage between C++ projects @ Apache. -- Forwarded message -- From: Allen Brookes [EMAIL PROTECTED] Date: Jul 18, 2006 4:50 PM Subject: RE: xmlbeanscxx proposal (resubmitted) To: Cliff Schmidt [EMAIL PROTECTED] Cc: dev@xmlbeans.apache.org, [EMAIL PROTECTED], Martin Sebor [EMAIL PROTECTED] I've included the proposal below. It hasn't changed but I have confirmed with people at Touk that the initial committers are correct. Allen -Original Message- From: Cliff Schmidt [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 2:53 PM To: Allen Brookes Cc: dev@xmlbeans.apache.org; [EMAIL PROTECTED]; Martin Sebor Subject: Re: xmlbeanscxx proposal (resubmitted) Allen, Since we've gotten confirmation from David that he's still interested, can you just copy the latest version of the proposal into a plain text email and send to this list when you're ready. Also, let us know what sort of changes you've made (if any) since your March 29th proposal. Even if there are no changes, it would be good to get a fresh copy in everyone's inbox just before voting. Thanks, Cliff -- This is a proposal for an xmlbeans subproject which should be discussed here and voted on at the xmlbeans PMC. This is a modification of an earlier proposal (May 15, 2005). This proposal is being resubmitted on the advice of Cliff Schmidt. The nature of the proposal changed when the company Touk offered to submit their xmlbeansxx code base as the initial code. In order to move the project along as quickly as possible, we have elected to take full advantage of the Touk existing code and resources. One result of these changes is the need for developers at Touk to act as committers. Because adding committers is done on the basis of merit, and because there is no basis yet for judging merit on this project, Cliff has advised us to start over with a new proposal. Proposal to create a C++ version of the Apache XMLBeans project Submission date: ?? March 2006, Allen Brookes, (abrookes @ RogueWave dot-com) (0) rationale Apache currently maintains the XMLBeans/Java project, a tool that uses XML Schema as a basis for generating Java classes used to easily access XML instance data. The goal of the XMLBeans/C++ project is to provide a very similar user experience for C++ developers as that provided by the XMLBeans/Java version. This includes generating strongly-typed C++ classes for the XML binding as well as providing low-level C++ APIs enabling access to the raw, underlying XML content. Where possible, the XMLBeans/C++ project will provide a nearly identical API and parallel architecture to that provided by the Java counterpart, and will closely mimic both features and schedule. The project will be jump started with the contribution of xmlbeansxx, a partial C++ implementation of XMLBeans from Touk (http://touk.pl/web/en/index.html). Rogue Wave Software will help jump start this project by contributing considerable expertise in the area of XML data bindings in C++ and C++ expertise in general. (0.1) criteria Meritocracy: The C++ version of the project should adhere to the same open, merit-based community standards as other Apache projects. Contributions and Core Developers: Code being contributed is an open source partial implementation of XMLBeans in C++ created by Touk. The community should be able to immediately jump in and begin work, along side dedicated Touk and Rogue Wave personnel, to turn the initial contribution into a feature-compatible version of XMLBeans for C++. Community: The community around the Java version of XMLBeans is already vibrant and growing. There is every reason to believe many of those within the existing community have experience and/or general interest in a successful, compatible C++ implementation of the toolset. This should ensure an immediately active and vocal community, even if the primary interest is in ensuring a similar experience between versions. The original contribution for this project has been around for some time and has generated some interest already. Additionally, at least one member of an existing Apache project has expressed interest in a project like XMLBeans/C++ to aid in his current work. Higher-level projects such as Axis for C++ seem to be natural beneficiaries of this work. (0.2) known risks Orphaned Products: The xmlbeansxx project has been around
Re: Data binding extensions and changes to the SCA spec
Hi, It should be a good fit to use Transfomation service to present property values in a preferred way indicated by the property receiver. Here're some use cases I can imagine: 1) Parse the XML for a property value to create a DOM representation (StAX XMLStreamReader--DOM Node) 2) Inject the property to the target instance: For example, @DataBinding(type=sdo, ...) @Property private MyProperty myProperty; Then DOM Node -- SDO DataObject can be applied. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 18, 2006 2:12 PM Subject: Data binding extensions and changes to the SCA spec I would like to get started on support for for XPath in SCDL as it is part of the recent SCA spec changes. This will likely require changes to the loader infrastructure and in particular StringParserPropertyFactory. Instead of having a PropertyFactory create an ObjectFactory responsible for returning a value that is injected into a component implementation instance, we will need to have a more flexible approach as property values may now be based off of XPath expressions to composite properties. What I would like to propose is that we have creation of the ObjectFactory for the property handled by the builder in much the same way as it handles wires. I think we can leverage the data transformation service for this. In this case, the builder will be given a representation of the parsed XML, probably DOM. If the property value was an XPath expression, the builder will have to use an XPath engine to evaluate and retrieve this actual value (Jaxen?) represented as a Node. The builder will then in turn use the transformation service to create a bound type. The builder will subsequently create an ObjectFactory for the bound type responsible for injecting on the target component implementation instance. The specific kind of ObjectFactory will depend on the kind of property it is: - If it is immutable, the builder will use a SingletonObjectFactory - If it is mutable, but the property is configured as safe (i.e. the component does not mutate it), the builder will use a SingletonObjectFactory). We can also assume by default values are safe unless explicitly marked. - If it is mutable, marked not safe, and Cloneable, a CloningObjectFactory is used which clones on getInstance() -If it is mutable, marked not safe and is not Cloneable, the builder avoids the call to the transformation service and instead uses an ObjectFactory which calls out the to transformation service on every getInstance() invoke. For some implementation types, a builder may not want to use ObjectFactory (perhaps the implementation just takes a DOM or some other format). In that case, the builder would be free to use the transformation service or not. Raymond, does this sound like it would fit with the transformation service? If so, I think we need to look at incorporating the base data transformation framework into SPI and core. I'd also be willing to work on an XStream binding extension which would enable handling of basic POJO binding. Jim - 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]
CurrentCompositeContext.getContext() in chianti?
Does Tuscany, now with Chianti, take responsibility for setting up the CurrentCompositeContext? When I last understood the relevant code, at M1, Tuscany was more or less requiring the host environment to set this up (then CurrentModuleContext). This was done with Tomcat via the TuscanyValve, for example, (which I'm not counting as part of Tuscany proper). I see in chianti that org.apache.tuscany.core.launcher.CompositeContextImplis setting up CurrentCompositeContext but I'm not sure what to make of this. Is Tuscany already setting up CurrentCompositeContext or might this be an area in which to propose an improvement? Thanks Scott Kurz
Re: Data binding extensions and changes to the SCA spec
On Jul 18, 2006, at 5:28 PM, Raymond Feng wrote: Hi, It should be a good fit to use Transfomation service to present property values in a preferred way indicated by the property receiver. Here're some use cases I can imagine: 1) Parse the XML for a property value to create a DOM representation (StAX XMLStreamReader--DOM Node) 2) Inject the property to the target instance: For example, @DataBinding(type=sdo, ...) @Property private MyProperty myProperty; We could support the annotation but I was also thinking we could have a Tuscany runtime configuration set per component implementation type. I like the configuration approach with an attribute override since it allows implementation code to remain agnostic of the databinding unless it needs something specific (in which case it could use the annotation). Raymond, do you want to take a stab at separating packages into what should go into an SPI and what should go into core? Jim Then DOM Node -- SDO DataObject can be applied. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 18, 2006 2:12 PM Subject: Data binding extensions and changes to the SCA spec I would like to get started on support for for XPath in SCDL as it is part of the recent SCA spec changes. This will likely require changes to the loader infrastructure and in particular StringParserPropertyFactory. Instead of having a PropertyFactory create an ObjectFactory responsible for returning a value that is injected into a component implementation instance, we will need to have a more flexible approach as property values may now be based off of XPath expressions to composite properties. What I would like to propose is that we have creation of the ObjectFactory for the property handled by the builder in much the same way as it handles wires. I think we can leverage the data transformation service for this. In this case, the builder will be given a representation of the parsed XML, probably DOM. If the property value was an XPath expression, the builder will have to use an XPath engine to evaluate and retrieve this actual value (Jaxen?) represented as a Node. The builder will then in turn use the transformation service to create a bound type. The builder will subsequently create an ObjectFactory for the bound type responsible for injecting on the target component implementation instance. The specific kind of ObjectFactory will depend on the kind of property it is: - If it is immutable, the builder will use a SingletonObjectFactory - If it is mutable, but the property is configured as safe (i.e. the component does not mutate it), the builder will use a SingletonObjectFactory). We can also assume by default values are safe unless explicitly marked. - If it is mutable, marked not safe, and Cloneable, a CloningObjectFactory is used which clones on getInstance() -If it is mutable, marked not safe and is not Cloneable, the builder avoids the call to the transformation service and instead uses an ObjectFactory which calls out the to transformation service on every getInstance() invoke. For some implementation types, a builder may not want to use ObjectFactory (perhaps the implementation just takes a DOM or some other format). In that case, the builder would be free to use the transformation service or not. Raymond, does this sound like it would fit with the transformation service? If so, I think we need to look at incorporating the base data transformation framework into SPI and core. I'd also be willing to work on an XStream binding extension which would enable handling of basic POJO binding. Jim - 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: CurrentCompositeContext.getContext() in chianti?
Responsibility still lies with the host environment. In the launcher's case, it is the J2SE (command line) host environment so it sets up the context before calling the application code; it is kind of similar to a J2EE application client container. We do a similar thing in SCATestCase to set up the environment before calling the user's TestCase (we do it in setUp). -- Jeremy On Jul 18, 2006, at 6:52 PM, Scott Kurz wrote: Does Tuscany, now with Chianti, take responsibility for setting up the CurrentCompositeContext? When I last understood the relevant code, at M1, Tuscany was more or less requiring the host environment to set this up (then CurrentModuleContext). This was done with Tomcat via the TuscanyValve, for example, (which I'm not counting as part of Tuscany proper). I see in chianti that org.apache.tuscany.core.launcher.CompositeContextImplis setting up CurrentCompositeContext but I'm not sure what to make of this. Is Tuscany already setting up CurrentCompositeContext or might this be an area in which to propose an improvement? Thanks Scott Kurz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-564) BigBank tomcat test integration POM points to BEA jar file download
BigBank tomcat test integration POM points to BEA jar file download --- Key: TUSCANY-564 URL: http://issues.apache.org/jira/browse/TUSCANY-564 Project: Tuscany Issue Type: Bug Components: Java BigBank Scenario Affects Versions: Java-M1, Java-M2 Reporter: Luciano Resende I was trying to run java/testing/tomcat/bigbank When you don't have jsr173 dependency available, you will get the following from the mvn command line Missing: -- 1) javax.xml:jsr173:jar:1.0 Try downloading the file manually from: http://ftpna2.bea.com/pub/downloads/jsr173.jar Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=jsr173 -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file After some investigation, I found out that the /java/testing/tomcat/readme.htm file have instructions on how to download this dependency from XML Bean Distribution. Jeremy also pointed that we could exclude this one and use stax-api dependency already available for other parts of the project. http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05206.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test coverage tool
Try zipping it and then attaching the zip. It worked this way for me when I tried to attach a gif for our website. Venkat On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Looks like the mailing list strips attachments. Is there a way to send this and not have it removed? Jim On Jul 18, 2006, at 11:36 AM, Kevin Williams wrote: Hi Jim, I don't see the attached report. --Kevin Jim Marino wrote: I've been using Clover as a test coverage tool and have found it quite useful (http://www.cenqua.com/clover/) Licensing is free for open source projects and it has plugins for popular IDEs so it can be run as part of a standard code-test cycle (it can be toggled on and off). Although it is a bit indiscriminate (e.g. it flags getters and setters), I find it particularly helpful when writing test cases since it highlights untested code in the IDE. I have attached a sample report I just ran that shows the high level statistics from a run. When we get around to creating integration build infrastructure I would like us to examine using this and generating reports that are posted to a project status page since it is a good indication of areas that need work. It would also been nice to run a dependency analyzer periodically over the codebase to avoid cycles in our package structures. I've seen people use JDepend or SonarJ. Does anyone have experience with either of these two or an alternative? Jim - --- - 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++] Fwd: xmlbeanscxx proposal
Thanks for bringing this to our attention. I'll certainly look into seeing how we can use this in Tuscany. Cheers, -- Pete
