Re: Graduation

[Simon Laws]

On Thu, May 22, 2008 at 7:57 AM, Robert Burrell Donkin <
[EMAIL PROTECTED]> wrote:

> On 5/22/08, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> > Congratulations everyone!
>
> +1
> Robert
>
> >
> > Paul
> >
> > On Thu, May 22, 2008 at 3:43 AM, Vamsavardhana Reddy
> > <[EMAIL PROTECTED]> wrote:
> >> That's great news.
> >>
> >> ++Vamsi
> >>
> >> On Thu, May 22, 2008 at 2:44 AM, Matthieu Riou <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> "Special order 7B, Establish the Apache Tuscany Project, was approved
> by
> >>> Unanimous Vote of the directors present."
> >>>
> >>> Congratulations guys!
> >>>
> >>> Matthieu
> >>>
> >>
> >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and CTO, WSO2
> > Apache Synapse PMC Chair
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > [EMAIL PROTECTED]
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
>
Great news indeed! Thanks to everyone in the Apache incubator and especially
to our mentors past and present.

Simon

Re: Build failure in itest/contribution-classloader (monitor problem)

[Simon Laws]

On Thu, May 22, 2008 at 8:35 AM, Rajini Sivaram <
[EMAIL PROTECTED]> wrote:

> Simon,
>
> Do we actually expect to always find a monitor implementation on the
> classpath? If so, I think we should throw an exception earlier on if no
> monitor implementation was found, rather than a NullPointerException
> masking
> the original exception when something does go wrong. But shouldn't we
> actually tolerate the absence of a monitor implementation, and use monitors
> with checks for null?


It was the intention that it should run quite happily without a monitor.
What is happening is that this code path is not covered by code that fluffs
up a default monitor in the absence of one being found on the classpath.


>
> monitor-logging is not a dependency on host-embedded at the moment.
> itest/contribution-classloader is the only test that fails because it is
> the
> only one which uses the exception code path.
>

My mistake. For some reason I had it in my mind that I had added a
dependency at some point. Maybe it was just something I did locally at some
point.


>
> On 5/22/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, May 21, 2008 at 9:33 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> > > I just did a clean checkout and full build.  It failed in
> > > itest/contribution-classloader with the following stack trace.
> > >
> > > The problem is caused by a null value in the "monitor" variable
> > > on line 124 of JavaInterfaceProcessor.  This does not seem to
> > > happen for other tests.  Any ideas?
> > >
> > >  Simon
> > >
> > > Running org.apache.tuscany.sca.test.contribution.ContributionTestCase
> > > Created supplychain.customer.JavaCustomerComponentImpl using: SCA
> > > contribution c
> > > lassloader for :
> > > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut
> > > ion-test/target/contributions/Customer.jar
> > > Created supplychain.retailer.JavaRetailerComponentImpl using: SCA
> > > contribution c
> > > lassloader for :
> > > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut
> > > ion-test/target/contributions/Retailer.jar
> > > Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA
> > > contribution
> > >  classloader for :
> > > file:/F:/tuscany70/sca/itest/contribution-classloader/contrib
> > > ution-test/target/contributions/Warehouse.jar
> > > Created supplychain.shipper.JavaShipperComponentImpl using: SCA
> > > contribution cla
> > > ssloader for :
> > > file:/F:/tuscany70/sca/itest/contribution-classloader/contributio
> > > n-test/target/contributions/Shipper.jar
> > > Work thread Thread[Thread-2,5,main] - Order, submitted, fulfilled,
> > shipped
> > > Created supplychain.customer.JavaCustomerComponentImpl using:
> > > java.net.URLClassL
> > > [EMAIL PROTECTED]
> > > Created supplychain.retailer.JavaRetailerComponentImpl using:
> > > java.net.URLClassL
> > > [EMAIL PROTECTED]
> > > Created supplychain.warehouse.JavaWarehouseComponentImpl using:
> > > java.net.URLClas
> > > [EMAIL PROTECTED]
> > > Created supplychain.shipper.JavaShipperComponentImpl using:
> > > java.net.URLClassLoa
> > > [EMAIL PROTECTED]
> > > Work thread Thread[Thread-4,5,main] - Order, submitted, fulfilled,
> > shipped
> > > Created supplychain.illegal.JavaCustomerComponentImpl using: SCA
> > > contribution cl
> > > assloader for :
> > > file:/F:/tuscany70/sca/itest/contribution-classloader/contributi
> > > on-test/target/contributions/IllegalCustomer.jar
> > > Created supplychain.retailer.JavaRetailerComponentImpl using: SCA
> > > contribution c
> > > lassloader for :
> > > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut
> > > ion-test/target/contributions/Retailer.jar
> > > Created a retailer from Customer
> > > supplychain.retailer.JavaRetailerComponentImpl@
> > > 3fac1e22
> > > Created supplychain.customer.JavaCustomerComponentImpl using: SCA
> > > contribution c
> > > lassloader for :
> > > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut
> > > ion-test/target/contributions/CompleteSupplyChain.jar
> > > Created supplychain.retailer.JavaRetailerComponentImpl using: SCA
> > > contribution c
> > > lassloader for :
> > > file:/F:/tuscany70/sca/itest/contribution-classloader/contribut
> > > ion-test/target/contributions/CompleteSupplyChain.jar

Re: Build failure in itest/contribution-classloader (monitor problem)

[Simon Laws]

The intention is that there is always a default monitor. It's not happening
in this case though and needs fixing.

Simon

On Thu, May 22, 2008 at 9:15 AM, Simon Nash <[EMAIL PROTECTED]> wrote:

> Rajini Sivaram wrote:
>
>> Simon,
>>
>> Do we actually expect to always find a monitor implementation on the
>> classpath? If so, I think we should throw an exception earlier on if no
>> monitor implementation was found, rather than a NullPointerException
>> masking
>> the original exception when something does go wrong. But shouldn't we
>> actually tolerate the absence of a monitor implementation, and use
>> monitors
>> with checks for null?
>>
>> monitor-logging is not a dependency on host-embedded at the moment.
>> itest/contribution-classloader is the only test that fails because it is
>> the
>> only one which uses the exception code path.
>>
>>  If we are going to write unguarded monitor calls then we need
> to be 100% certain that a monitor will always be present.  It should
> be possible to ensure this by having a default "do nothing" monitor
> that is created at startup and can be overridden with a user-written
> implementation if one is found.
>
> I think that enforcing the 100% guarantee is better than writing
> null tests before every monitor call.
>
>  Simon
>
>
>
>> On 5/22/08, Simon Laws <[EMAIL PROTECTED]> wrote:
>>
>>> On Wed, May 21, 2008 at 9:33 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
>>>
>>>  I just did a clean checkout and full build.  It failed in
>>>> itest/contribution-classloader with the following stack trace.
>>>>
>>>> The problem is caused by a null value in the "monitor" variable
>>>> on line 124 of JavaInterfaceProcessor.  This does not seem to
>>>> happen for other tests.  Any ideas?
>>>>
>>>>  Simon
>>>>
>>>> Running org.apache.tuscany.sca.test.contribution.ContributionTestCase
>>>> Created supplychain.customer.JavaCustomerComponentImpl using: SCA
>>>> contribution c
>>>> lassloader for :
>>>> file:/F:/tuscany70/sca/itest/contribution-classloader/contribut
>>>> ion-test/target/contributions/Customer.jar
>>>> Created supplychain.retailer.JavaRetailerComponentImpl using: SCA
>>>> contribution c
>>>> lassloader for :
>>>> file:/F:/tuscany70/sca/itest/contribution-classloader/contribut
>>>> ion-test/target/contributions/Retailer.jar
>>>> Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA
>>>> contribution
>>>>  classloader for :
>>>> file:/F:/tuscany70/sca/itest/contribution-classloader/contrib
>>>> ution-test/target/contributions/Warehouse.jar
>>>> Created supplychain.shipper.JavaShipperComponentImpl using: SCA
>>>> contribution cla
>>>> ssloader for :
>>>> file:/F:/tuscany70/sca/itest/contribution-classloader/contributio
>>>> n-test/target/contributions/Shipper.jar
>>>> Work thread Thread[Thread-2,5,main] - Order, submitted, fulfilled,
>>>>
>>> shipped
>>>
>>>> Created supplychain.customer.JavaCustomerComponentImpl using:
>>>> java.net.URLClassL
>>>> [EMAIL PROTECTED]
>>>> Created supplychain.retailer.JavaRetailerComponentImpl using:
>>>> java.net.URLClassL
>>>> [EMAIL PROTECTED]
>>>> Created supplychain.warehouse.JavaWarehouseComponentImpl using:
>>>> java.net.URLClas
>>>> [EMAIL PROTECTED]
>>>> Created supplychain.shipper.JavaShipperComponentImpl using:
>>>> java.net.URLClassLoa
>>>> [EMAIL PROTECTED]
>>>> Work thread Thread[Thread-4,5,main] - Order, submitted, fulfilled,
>>>>
>>> shipped
>>>
>>>> Created supplychain.illegal.JavaCustomerComponentImpl using: SCA
>>>> contribution cl
>>>> assloader for :
>>>> file:/F:/tuscany70/sca/itest/contribution-classloader/contributi
>>>> on-test/target/contributions/IllegalCustomer.jar
>>>> Created supplychain.retailer.JavaRetailerComponentImpl using: SCA
>>>> contribution c
>>>> lassloader for :
>>>> file:/F:/tuscany70/sca/itest/contribution-classloader/contribut
>>>> ion-test/target/contributions/Retailer.jar
>>>> Created a retailer from Customer
>>>> supplychain.retailer.JavaRetailerComponentImpl@
>>>> 3fac1e22
>>>> Created supplychain.customer.JavaCustomerCo

Re: [jira] Commented: (TUSCANY-2296) SCADomain.newInstance() processes all composites in the contribution irrespective of the parameter passed

[Simon Laws]

On Thu, May 22, 2008 at 5:21 PM, tomas darbois (JIRA) <
tuscany-dev@ws.apache.org> wrote:

>
>[
> https://issues.apache.org/jira/browse/TUSCANY-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599068#action_12599068]
>
> tomas darbois commented on TUSCANY-2296:
> 
>
> I'm facing the same problem, and I was hoping to see a solution or
> workaround , instead of reply with Work  as Designed :p
>
> I ve several composite files that are used depending on the deployement
> (used by several applications, and in various servers that aren't identical)
> and I was starting to see a good way to design it in my application,
> grouping the composites in the same place so that I was having a quicker
> control on them.
>
> I will use some tricks to workaround that problem, but it's considered for
> me as a really bad point for future enhancements of my application.
>
> > SCADomain.newInstance() processes all composites in the contribution
> irrespective of the parameter passed
> >
> -
> >
> > Key: TUSCANY-2296
> > URL: https://issues.apache.org/jira/browse/TUSCANY-2296
> > Project: Tuscany
> >  Issue Type: Bug
> >  Components: Java SCA Embedded Runtime
> >Affects Versions: Java-SCA-1.2
> >Reporter: Vamsavardhana Reddy
> > Fix For: Java-SCA-Next
> >
> > Attachments: TUSCANY-2296-recreate.patch
> >
> >
> > I have two composites, namely "proper.composite" and "error.composite",
> in my test project.  "proper.composite" is used to test proper contribution
> without any errors whereas "error.composite" is used to test a problematic
> contribution.  But when I initialize a domain using SCADomain.
> newInstance("proper.composite"), I am getting an exception due to
> "error.composite".  Though it looks as if the call SCADomain.
> newInstance("proper.composite") processes only "proper.composite", in
> reality it is processing all the .composite files present in the project
> irrespective of the parameter passed to SCADomain.newInstance().
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
I don't like the behaviour either. We have a new Node implementation [1]
that does a very similar thing to the SCADomain class but allows us to
separate the Domain configuration from the actual runtime (the Node). The
node interface is a little complicated in this particular scenario at the
moment but you can direct it toward a specific directory to read as a
contribution and read a named composite. This is useful as it removes this
behaviour where SCADomain just uses the composite name to locate a
contribution and then loads all composites there. I used this in some of our
validation tests [2]

node = nodeFactory.createSCANode(new
File("src/main/resources/ComponentReferenceTargetNotFound/Calculator.composite").toURL().toString(),
 new SCAContribution("TestContribution",
 new
File("src/main/resources/ComponentReferenceTargetNotFound").toURL().toString()));


We have talked about adding a helper method (from an old Node implementation
we have) that allows a simpler API

 node =
SCANode2Factory.createSCANodeWithComposite("DuplicateComponentName/Calculator.composite");

We haven't got round to this yet but I think we would make this use the
directory where Calculator.composite is as the contribution and have it load
just Calculator.composite.

Thoughts?

Simon

[1]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/node2-api/
[2]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/validation/src/test/java/calculator/warning/DuplicateComponentNameTestCase.java

Re: [jira] Created: (TUSCANY-2336) Option to turn Validation on/off

[Simon Laws]

On Thu, May 22, 2008 at 5:05 PM, Hasan Muhammad (JIRA) <
tuscany-dev@ws.apache.org> wrote:

> Option to turn Validation on/off
> 
>
> Key: TUSCANY-2336
> URL: https://issues.apache.org/jira/browse/TUSCANY-2336
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Problem Determination
> Environment: All
>Reporter: Hasan Muhammad
>Priority: Critical
>
>
> Tuscany should provide a flag or mechanism to turn validation on/off. Tools
> developed on top of tuscany may perform validation using tuscany's
> validation framework. In that case, any user may not want validation being
> done during runtime as it was already done using external tools.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
> Hi Hasan

Do you mean here that you want to turn validation off completely or that you
just want to turn off the messages that result from validation?

If the latter we could instigate a monitor that doesn't do anything.

If the latter it's more tricky and depends on which part of validation you
are concerned about. Validation happens in many different places in the
runtime, e.g. schema validation during the model read, model validation
during the build etc. In most cases (schema validation being the exception
probably) we don't have validation logic that is separate from the act of
building or resolving the model.

Regards

Simon

Re: [jira] Commented: (TUSCANY-2296) SCADomain.newInstance() processes all composites in the contribution irrespective of the parameter passed

[Simon Laws]

On Thu, May 22, 2008 at 5:56 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Thu, May 22, 2008 at 5:47 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> 
>
> We have talked about adding a helper method (from an old Node
> implementation
> > we have) that allows a simpler API
> >
> > node =
> >
> >
> SCANode2Factory.createSCANodeWithComposite("DuplicateComponentName/Calculator.composite");
> >
> > We haven't got round to this yet but I think we would make this use the
> > directory where Calculator.composite is as the contribution and have it
> > load
> > just Calculator.composite.
> >
> >
> This is what the o.a.t.s.host.embedded.SCADomain.newInstance(String
> domainURI, String contributionLocation, String... composites) is trying to
> do isn't it? Just that there's a bug and the contributionLocation gets
> ignored and it still just finds everything in the classpath.
>
>   ...ant
>

Maybe you're right. I haven't used SCADomain for a while so I'm a little
rusty.

Simon

Re: How do I get my Continuum build server account unlocked?

[Simon Laws]

On Fri, May 23, 2008 at 10:55 AM, Mark Combellack <[EMAIL PROTECTED]>
wrote:

> Hi,
>
>
>
> I've just tried accessing the Continuum build server [1] and have
> discovered
> that my account is locked. How do I go about getting my account unlocked?
> Can anyone do this for me? My account id is mcombellack.
>
>
>
> Thanks,
>
>
>
> Mark
>
>
>
> [1] http://vmbuild.apache.org/continuum/
>
>
>
>
>
>
>
>
And an additional question. How did you get the account in the first place.
I'd like to be able to kick off builds etc and I'm assuming I need an
account to be able to do that. How does one go about getting one?

Simon

Re: How do I get my Continuum build server account unlocked?

[Simon Laws]

On Fri, May 23, 2008 at 11:05 AM, Mark Combellack <[EMAIL PROTECTED]>
wrote:

> > -Original Message-
> > From: Simon Laws [mailto:[EMAIL PROTECTED]
> > Sent: 23 May 2008 11:01
> > To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]
> > Subject: Re: How do I get my Continuum build server account unlocked?
> >
> > On Fri, May 23, 2008 at 10:55 AM, Mark Combellack <
> [EMAIL PROTECTED]>
> > wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > I've just tried accessing the Continuum build server [1] and have
> > > discovered
> > > that my account is locked. How do I go about getting my account
> > unlocked?
> > > Can anyone do this for me? My account id is mcombellack.
> > >
> > >
> > >
> > > Thanks,
> > >
> > >
> > >
> > > Mark
> > >
> > >
> > >
> > > [1] http://vmbuild.apache.org/continuum/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > And an additional question. How did you get the account in the first
> > place.
> > I'd like to be able to kick off builds etc and I'm assuming I need an
> > account to be able to do that. How does one go about getting one?
> >
> > Simon
>
> I did this many months ago so I am a bit vague on the exact detail.
>
> To get my account, I clicked the register link on the page and created an
> account. I then posted a request to the Tuscany dev list to be added to the
> Tuscany build group. Someone then did something and some time later I could
> then see and start Tuscany builds.
>
> Mark
>
>
OK, thanks for that Mark.

When I go to http://vmbuild.apache.org:8080/continuum I don't see any
projects at all. Either that's now the wrong link or something more serious
is up.

Simon

Policy conundrum

[Simon Laws]

I've been playing with the Node2 impl a bit with a composite that has
policies in it and getting really confused. I've had a fun(?) day scratching
my head but I now realize that Node2 doesn't seem to run the piece of code
that executes the policy set "appliesTo" XPath expressions so that policy
sets get attached to the model in the correct way. I was going to look at
fixing it but then also realized that I don't quite understand how this
process can really work. I seems that it's set up so that...

1. CompositeDocumentProcessor.read()
  Apply all policy sets to the XML model using the "appliesTo" XPATH
2. XYZ.read()
  read "requires" intents
  read "policSets" policy sets
3. CompositeProcesor.resolve()
  Inherit specified intents from composite to component
  Inherit specificed policy sets from composite to component
  Inhetit applicable policy sets from composite to component
  Resolve the polcy sets between the implementation and component
4. Build
  Shuffle all the intents/policy sets around to complete the set for each
implementation and binding

The fly in this particular ointment is that it's not until stage 4 that some
of the model artifacts are constructed, for example, binding.sca when it's
not specified. This is far too late (or stage 1 is far too early) to pick up
any of the "appliesTo" policy sets so you just end up with parts of the
model without the correct policy configuration.

It's quite likely that I'm missing something in this process. Can someone
put me straight?

Simon

Re: SCA 1.2.1 release

[Simon Laws]

On Tue, May 27, 2008 at 6:26 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

> Dave Sowerby wrote:
>
>> Hi Simon,
>>
>> With regards to the 1.2.1 release you are correct that we have a
>> patched version of tuscany-sca-all which would work, but this however
>> leaves us in an awkward configuration position.
>>
>> We're currently preparing a software release based around Tuscany
>> which is completely open to customers of our use of Tuscany, such that
>> we document fully how to construct services independent of our
>> software.  As such, we do not ship any Tuscany artifacts and instead
>> encourage our customers to utilise the published maven repository.
>> Whilst requiring a patch version of one of the jars is possible; I
>> don't feel that this is a good representation of Tuscany - either
>> documenting a variant version or expecting a non-standard version of
>> 1.2-incubating.  These potential solutions are more likely to cause
>> issues for customers that would undermine the image of Tuscany that we
>> try to project.
>>
>> Is anyone adamantly opposed to this release?  Do you feel Tuscany
>> 1.2.1 is still an option?  I'd hope that given the potential to damage
>> our customer's perception of Tuscany would be enough to justify this
>> minor release.
>>
>>  Thanks for the clarifaction and explanation.  It seems to me that
> because we distribute Tuscany via Maven repos, which can't be patched,
> this kind of situation will arise whenever a serious bug is found.
> We can use patches to isolate a problem and confirm the fix, but we
> generally won't be able to use them as an alternative to a release.
>
> In a situation like this, unless a new release is imminent, the best
> solution seems to be to produce a quick "bug fix" release without
> incurring the overhead of a full release and testing cycle.  Ant has
> suggested that we could do this by applying a small set of carefully
> controlled changes to the previous 1.2 release tag.  I think we need
> to be very strict about what changes go in, to avoid another experience
> like 1.0.1.  Specifically, I would suggest only including the fix
> for TUSCANY-2304.
>
> What do others think of this?
>
>  Simon
>
>
>  Cheers,
>>
>> Dave.
>>
>> On Tue, May 20, 2008 at 12:00 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
>>
>>> Nishant Joshi wrote:
>>>
 Hi All,
 I have raised TUSCANY-2304 which was actually blocking me to go further
 with
 SCA client. So It was given high priority to resolved and fortunately
 Ant
 has resolved it very fast, i appreciate his effortt, thanks alot Ant for
 this :).
 Another one was TUSCANY-2251 that was handled by Simon Nash and he has
 also
 done good progress on it (found from this list ). This problem came in
 eclipse generated web service client (please refer it for more detail)
 so
 this is also in high priority to get in next release. So i request to
 add
 TUSCANY-2304 in 1.2.1 and if possible TUSCANY-2251 also.

 One more thing, its very critical for us to get the next release 1.2.1
 ASAP
 (with 2304 and if possbile 2251 also :) ).

 So I hope you can understand the effect of the TUSCANY-2304 for any
 tuscany
 SCA client user .

>>> Hi Nishant,
>>> The work to fix TUSCANY-2251 has turned out bigger than expected.
>>> It's one of those cases where the first 80%-90% can be done quite
>>> quickly but supporting the final 10%-20% of cases turns up many
>>> issues, some of which require changes in other parts of the code.
>>>
>>> I'm preparing a (large) checkin to update the new generator code
>>> so that it handles most of the cases (perhaps 95%).  This should be
>>> enough to get the full build to run with the new code.  However, I
>>> wouldn't consider the new code to be ready to release at that point.
>>> It will need quite a bit of further testing and a few more updates
>>> to take care of the remaining 5% of cases.  Some of these cases will
>>> require discussion on the list to agree how they should be handled.
>>> Also, the new code will need testing by people other than myself
>>> with their scenarios to make sure that it does not break cases that
>>> worked with the previous Java2WSDL generator.
>>>
>>> For all these reasons, I think it will take about another 3 weeks
>>> to get the new generator code to the state that I would be happy
>>> to see it enabled in a release.
>>>
>>> Regarding TUSCANY-2304, from other emails I see that Ant has sent
>>> you a patched version of tuscany-sca-all-1.2-incubating.jar that
>>> contains the fix for your problem.  Can you explain why you need a
>>> new release in addition to this patch?
>>>
>>>  Simon
>>>
>>>
>>>
>>
>>
>>
>
+1 to Simon's comment. Any kind of "fix creep" over what is really required
is going to make this more than a quick bug fix release.

Simon

Re: [jira] Updated: (TUSCANY-2332) reconsider non-support for Holders

[Simon Laws]

On Wed, May 21, 2008 at 7:19 PM, Scott Kurz (JIRA) <
tuscany-dev@ws.apache.org> wrote:

>
> [
> https://issues.apache.org/jira/browse/TUSCANY-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Scott Kurz updated TUSCANY-2332:
> 
>
>Attachment: guessAndGreet.wsdl
>
> > reconsider non-support for Holders
> > --
> >
> > Key: TUSCANY-2332
> > URL: https://issues.apache.org/jira/browse/TUSCANY-2332
> > Project: Tuscany
> >  Issue Type: Improvement
> >  Components: Java SCA Data Binding Runtime
> >Reporter: Scott Kurz
> > Attachments: guessAndGreet.wsdl
> >
> >
> > Though the Java annotations/API spec specifically says wrt WSDL-> Java
> mapping:
> > The JAX-WS mappings are applied with the following restrictions:
> > • No support for holders
> > I'd like to suggest that we look into enabling such support anyway, as
> this seems overly restrictive and prevents us from supporting existing WSDLs
> with inout data.
> > At least I don't see how we'd map these WSDLs to Java and would think
> we'd be way better off relying on the mapping defined by JAX-WS which does
> use Holders.
> > (Not sure what this statement in the spec was trying to accomplish.)
> > I attached an example WSDL with two operations which we'd want to use
> Holders in the corresponding Java methods.   One has a common child element
> of both input/output wrapper elem and the other has a common part of
> input/output message.
> > (Maybe it would be better to bring this up before opening a JIRA, but I
> wanted to attach the WSDL.)
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Hi Scott

I have a couple of questions/comments related to this.

I don't know why the spec specifically stated that we won't support this
either but I can make a guess.

On a philosophical note if you are in the business of writing coarse grained
service interfaces with the intention of being protocol independent then
relying on in/out or out parameters in you interface is unlikely to make
your interfaces clear and easy to use. Like everything, as a purely
technical challenge, I'm sure it could be made to work but IMHO it doesn't
add clarity or achieve anything that can't be achieved with clearly
delineated input parameters and a response value.

As we only deal with doc/lit/wrapped WSDL currently Tuscany only expects one
part per message and would always expect there to be a set of input
parameters and a response. If this WSDL has come from some other existing
system with the intention of representing in/out or out parameters then the
SOAP engine on the service end will be marshalling from request parameters
and to a responses so Tuscany would just take the WSDL at face value.

As a slight aside, looking at the WSDL attached, I had to go and check in
the WSDL spec what the hints are for in/out and out params. In WSDL 1.1 I
found some words in section 2.4.6 which don't seem to chime with the
approach you have taken. What rules are you following to indicate in/out and
out parameters.

Regards

Simon

Re: [jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi

[Simon Laws]

On Wed, May 28, 2008 at 11:16 AM, Simon Nash <[EMAIL PROTECTED]> wrote:

> Graham Charters wrote:
>
>> I've been wondering whether we should make this an itest rather than a
>> sample.  We could keep it as a sample, but it relies on
>> maven-dependency-plugin to work out the dependencies required to run
>> the sample.  Is a sample that only works with maven acceptable (I
>> believe the other samples do not) or should I change this to be an
>> itest?
>>
>>  We do try hard to make the samples work with ant as well as maven.
> There have been cases where samples started out with maven support
> only and the ant support was added later.  From your description,
> it doesn't sound lke this is likely to happen.
>
> I believe the main purpose of this "sample" is to act as a test for
> the Tuscany build rather than a sample for a user to copy and adapt.
> If this is correct, I think it should be changed to an itest.
>
>  Simon
>
>
>  Regards, Graham.
>>
>> 2008/5/23 Graham Charters (JIRA) :
>>
>>>   [
>>> https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599389#action_12599389]
>>>
>>> Graham Charters commented on TUSCANY-2330:
>>> --
>>>
>>> Hi Rajini, sorry for taking so long to respond.  Please go ahead and
>>> check the code in with your update.  Changing it to use Felix is fine by me.
>>>  I tested it with both and there was little discernible difference in
>>> performance.
>>>
>>> Thanks, Graham.
>>>
>>>  Calculator sample running in OSGi
 -

Key: TUSCANY-2330
URL: https://issues.apache.org/jira/browse/TUSCANY-2330
Project: Tuscany
 Issue Type: Wish
 Components: Java SCA Samples
   Affects Versions: Java-SCA-Next
Environment: All
   Reporter: Graham Charters
Fix For: Java-SCA-Next

Attachments: calculator-osgi-sample.patch

  Original Estimate: 2h
  Remaining Estimate: 2h

 It would help with preserving OSGi support if an OSGi sample were run as
 a matter of course, rather than only by a small number of developers.  This
 wish is to add the smallest sample possible based on existing Tuscany 
 module
 dependencies.

>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>>
>>
>
As we have a distribution that doesn't fundamentally depend on, and hence
demonstrate, how Tuscany might be deployed in an OSGi environment then I
think that a sample that shows how to do this is appropriate. If this means
that we have a sample that only runs from maven then it's inconsistent with
our other samples but I could live with that.

I guess the real answer is do you think a user could base an OSGi
installation on what they learn by looking at the sample. I haven't looked
at the sample yet myself. Does this bring host-osgi back to life? Is this
sample going to be reworked in the short term as the code is moved around?
If yes then that would be a justification for keeping it out of samples.

Regards

Simon

Re: [jira] Updated: (TUSCANY-2332) reconsider non-support for Holders

[Simon Laws]

Hi Scott, more comments...

Simon

On Wed, May 28, 2008 at 2:34 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:

> Simon,
>
> I used my own interpretation of the JAX-WS spec (in Sec 2.3 and its
> subsections)  to construct my example WSDL, and noticed that the JAXWS-RI
> wsimport tool handled it by generating Holder(s) in Java as I expected.
> Note that my example does only have a single part per message, in spite of
> the way the part wrapper elements' children map to Java (via Holders).
>
> WSDL 1.1 Sec. 2.4.6 seems to discuss parameterOrder.  This is also
> discussed
> in JAX-WS.  However I'm not sure why this is especially helpful to discuss
> in this context and I don't see what the conflict is with my approach.
>

I just looked at JAX-ws 2.3.1.2  and see the rules you are talking about. I
mentionedsection 2.4.6 of WSDL1.1 as IIUC it gives the same list of in,
in/out, out options but with different rules for determining them. In
particular it's not talking about what to do with wrapped style WSDL. As the
SCA spec points us toward JAX-WS I expect the rules you point out are the
right ones. I should have looked there first.


> 
>
> BTW, I should add an important note... I'm not at all sure what Tuscany
> does
> with this WSDL today and didn't spend any time trying to understand this.
>  I
> just made a leap and assumed we didn't support this today.
>
>

I suspect you are generally correct. As the specs expressly say that this is
not supported we haven't looked at this. To see what the actual effect is of
trying to use a WSDL like to one you provide we'll have to try it. I can
imagine these cases where you have more than one element children of the
return type will be problematic but I'd be interested to know what the error
message is.

Validation Exceptions was: Re: TUSCANY-2277 & validation messages

[Simon Laws]

On Wed, May 28, 2008 at 12:08 PM, Ramkumar R <[EMAIL PROTECTED]> wrote:

> Hi Simon,
>  After introducing the monitors in various part of the code. Now I am
> trying
> to remove the exception that are being thrown from these modules. As a
> first
> step we are removing the exceptions that are safe to remove, by leaving the
> critical exceptions like
> a) IOException
> b) XMLStreamException
> c) PriviledegedActionException
> d) and ParseConfigurationExceptions
>
> For the above said exceptions, we need some discussion as how to handle
> them.
>
> I have now raised TUSCANY-2347 to address this issue by leaving the above
> exceptions to still throw.
>
>
snip..

Hi Ram, I want to summarize the process here and make sure we are all on the
same page. From previous ML discussions we are looking at the case where a
user provides a contribution and we want the Tuscany runtime to have the
flexibility to report as many validation exceptions as it can up front
rather than just reporting the first one.

So far the validation code has been changed so that..

A - error and warning messages have been associated with a unique ID and
have been moved into resource bundles
B - the monitor has been flowed down into the various processing objects
C - validation errors or warnings are now logged to the monitor using the
unique message ID

This leaves the validation code still throwing exceptions all over the
place. These exceptions are a mixture of things.

1 - Fundamental exceptions, such as IOException, that mean that any
subsequent processing would cause problems
2 - Validation exceptions that mean that subsequent processing would cause
problems
3 - Validation exceptions that mean that subsequent processing can continue
allowing further validation exceptions to be captured. There are probably
several levels of this, e.g. stop processing the current component but other
components can be validated.
4 - Validation exceptions that are really warnings

IIUC you are disabling type 3 and 4 exceptions to allow a greater range of
validation exceptions to be reported before validation processing stops.

What happens with type 1 and 2 exceptions. I assume that validation
processing stops after one of these exceptions. Have you had any thoughts
about  how better to categorize and deal with them since your previous post?


Regards

Simon

Re: [jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi

[Simon Laws]

On Thu, May 29, 2008 at 8:48 AM, Rajini Sivaram <
[EMAIL PROTECTED]> wrote:

> On 5/28/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, May 28, 2008 at 11:16 AM, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> > > Graham Charters wrote:
> > >
> > >> I've been wondering whether we should make this an itest rather than a
> > >> sample.  We could keep it as a sample, but it relies on
> > >> maven-dependency-plugin to work out the dependencies required to run
> > >> the sample.  Is a sample that only works with maven acceptable (I
> > >> believe the other samples do not) or should I change this to be an
> > >> itest?
> > >>
> > >>  We do try hard to make the samples work with ant as well as maven.
> > > There have been cases where samples started out with maven support
> > > only and the ant support was added later.  From your description,
> > > it doesn't sound lke this is likely to happen.
> > >
> > > I believe the main purpose of this "sample" is to act as a test for
> > > the Tuscany build rather than a sample for a user to copy and adapt.
> > > If this is correct, I think it should be changed to an itest.
> > >
> > >  Simon
> > >
> > >
> > >  Regards, Graham.
> > >>
> > >> 2008/5/23 Graham Charters (JIRA) :
> > >>
> > >>>   [
> > >>>
> >
> https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599389#action_12599389
> > ]
> > >>>
> > >>> Graham Charters commented on TUSCANY-2330:
> > >>> --
> > >>>
> > >>> Hi Rajini, sorry for taking so long to respond.  Please go ahead and
> > >>> check the code in with your update.  Changing it to use Felix is fine
> > by me.
> > >>>  I tested it with both and there was little discernible difference in
> > >>> performance.
> > >>>
> > >>> Thanks, Graham.
> > >>>
> > >>>  Calculator sample running in OSGi
> > >>>> -
> > >>>>
> > >>>>Key: TUSCANY-2330
> > >>>>URL:
> > https://issues.apache.org/jira/browse/TUSCANY-2330
> > >>>>Project: Tuscany
> > >>>> Issue Type: Wish
> > >>>> Components: Java SCA Samples
> > >>>>   Affects Versions: Java-SCA-Next
> > >>>>Environment: All
> > >>>>   Reporter: Graham Charters
> > >>>>Fix For: Java-SCA-Next
> > >>>>
> > >>>>Attachments: calculator-osgi-sample.patch
> > >>>>
> > >>>>  Original Estimate: 2h
> > >>>>  Remaining Estimate: 2h
> > >>>>
> > >>>> It would help with preserving OSGi support if an OSGi sample were
> run
> > as
> > >>>> a matter of course, rather than only by a small number of
> > developers.  This
> > >>>> wish is to add the smallest sample possible based on existing
> Tuscany
> > module
> > >>>> dependencies.
> > >>>>
> > >>> --
> > >>> This message is automatically generated by JIRA.
> > >>> -
> > >>> You can reply to this email to add a comment to the issue online.
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > As we have a distribution that doesn't fundamentally depend on, and hence
> > demonstrate, how Tuscany might be deployed in an OSGi environment then I
> > think that a sample that shows how to do this is appropriate. If this
> means
> > that we have a sample that only runs from maven then it's inconsistent
> with
> > our other samples but I could live with that.
> >
> > I guess the real answer is do you think a user could base an OSGi
> > installation on what they learn by looking at the sample. I haven't
> looked
> > at the sample yet myself. Does this bring host-osgi back to life? Is this
> > sample going to be reworked in the short term as the code is moved
> around?
> > If yes then that would be a justification for keeping it out of samples.
>
>
> In its current form, the "sample" is too complicated - but it can be
> simplified quite easily to enable it to be used as both a sample and a
> test.
>
> If this is going to be an itest, I would really like it to reuse code from
> itest/osgi-tuscany rather than create a new copy of the code, requiring
> maintenance of two copies. As an itest, this subset should only add maven
> scripts to create a new set of dependencies. All the code can be used
> straight out of itest/osgi-tuscany rather than through a copy. Since this
> code is likely to change a lot as we tackle versioning etc., and since the
> calculator subset doesn't really add any new code, it would be much easier
> to maintain a single copy of the code rather than two (even though both are
> identical at the moment). IMO, it only makes sense to use a separate copy
> if
> the code is expected to diverge.
>
>
> Regards
> >
> > Simon
> >
>
>
>
> --
> Thank you...
>
> Regards,
>
> Rajini
>

Hi Rajini

Why is the code that is common to the itest and sample in each of these
rather than in a module?

Simon

Re: [jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi

[Simon Laws]

 Thanks Rajini


> There are two sets of classes that are shared across itest/osgi-tuscany and
> the calculator subset.
>
>   1. OSGi installer - I did think of converting this into a module, but at
>   the moment, this is still experimental code, and we haven't really
> decided
>   on what the final solution for a bundle-ized Tuscany will be. So
>   itest/osgi-tuscany felt like a better place for it.


I think making this a module make sense even though it's not fully baked.
It would at least remove this issue of duplicated code, i.e. we have one set
of code in development rather than two sets.


>   2. OSGi test harness - this runs samples (from the samples directory) in
>   an OSGi runtime. This is purely for testing, and doesn't really belong in
> a
>   "module". If the calculator subset is turned into a sample, it should not
>   really use the harness since it is too complicated. If it is turned into
> an
>   itest, it should be able to reuse the code directly from
> itest/osgi-tuscany.
>

Sounds fair enough  although we could make it a tool if you imagine that
more than one itest would need to use it.


> Simon
> >
>
>
>
> --
> Thank you...
>
> Regards,
>
> Rajini
>

Re: wiring to components implemented by a composite

[Simon Laws]

On Tue, May 27, 2008 at 4:45 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Tue, May 27, 2008 at 2:53 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
>> Imagine PolicyOuterComposite
>>
>> 
>> 
>> > target="OuterTargetServiceComponent">
>> 
>> 
>> 
>>
>> 
>> 
>> 
>> 
>> http://localhost:8085/OuterTargetServiceComponent"/>
>> 
>> 
>>
>> And PolicyInnerComposite
>>
>>  
>> 
>>
>> 
>> 
>> 
>>
>> With our current code this doesn't work. The runtime complains that it
>> can't match the reference targetService with OuterTargetServiceComponent. I
>> guess my first question is should this work?
>>
>> This happens as there is a specific bit code code in the EndpointBuilder
>> that does the following.
>>
>> // if the target service is a promoted service then find the
>> // service it promotes
>> if (endpoint.getTargetComponentService().getService() instanceof
>> CompositeService) {
>> CompositeService compositeService = (CompositeService)
>> endpoint.getTargetComponentService().getService();
>> // Find the promoted component service
>> ComponentService promotedComponentService =
>> ServiceConfigurationUtil.getPromotedComponentService(compositeService);
>> if (promotedComponentService != null &&
>> !promotedComponentService.isUnresolved()) {
>>
>> endpoint.setTargetComponentService(promotedComponentService);
>> }
>> }
>>
>> Hence the outer service is replaced with the promoted component service
>> and the outer service configuration isn't used. In this case the service on
>> the inner component doesn't have the right bindings on it. Looking at the
>> logs this code has been there for a long time.  Anyone know what the
>> intention is?
>>
>> Simon
>>
>
> I'm making a little bit more progress on this. It seems that, in the case
> of an automatically generated binding.sca at least, the wires are stored on
> the target component service. I don't understand why I'm seeing a difference
> in behaviour with different binding types.
>
> Simon
>

Ok, I looked at this in some detail now and I think we do have a problem
here.





http://localhost:8085/OuterTargetServiceComponent"/>



And PolicyInnerComposite

 






Doesn't work. Moving the binding down into the inner composite service
doesn't work but moving the binding down to the inner component service does
work.

I believe the model is just about correct but this code in the builder that
is converting the target service into the inner target component service is
incorrect. Indeed the failing combinations are successful if I comment out
this code. However without this code tests which use binding.sca in this
situation fail because binding.sca has an "optimization" where it uses the
component service to create a target invoker for the outbound wire. There
doesn't seem to be a wire created for the promoted target service. Needs
further investigation so I'll raise a JIRA to track it.

Simon

TUSCANY-2344 & 5 - resource & widget validation

[Simon Laws]

Hi

FYI. I've seen a couple of problems with the widget and resource validation
testing during may latest build. CouldNotResolveLocation doesn't seem to be
raise. I've @Ignored these tests for now just in case it's going to affect
others (I changed the test to JUnit4 to make this easy) .


As an aside we should probably go through these tests and convert to Junit4

Also I notice that the original tests I added don't fit into the neat
categorization scheme that has been used subsequently so I'll endeavor to
move the original tests into the new scheme to tidy things up.

Simon

Re: JAXWSJavaInterfaceProcessorTestCase fail?

[Simon Laws]

On Mon, Jun 2, 2008 at 8:32 AM, ant elder <[EMAIL PROTECTED]> wrote:

> On a fresh check out I'm getting a failure in
> JAXWSJavaInterfaceProcessorTestCase, anyone else seeing that or is it just
> me?
>
>   ...ant
>
>
> testProcessor(org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase)
> Time elapsed: 0.046 s
> ec  <<< FAILURE!
> junit.framework.AssertionFailedError: null
>at junit.framework.Assert.fail(Assert.java:47)
>at junit.framework.Assert.assertTrue(Assert.java:20)
>at junit.framework.Assert.assertTrue(Assert.java:27)
>at
>
> org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase.testProcessor(JAXWSJavaInt
> erfaceProcessorTestCase.java:80)
>

Failed for me also first time through with mvn -o. Just tried building that
module independently with mvn clean and then mvn and it appears to work.So
I'll try another build and see what happens.

Simon

Re: TUSCANY-2344 & 5 - resource & widget validation

[Simon Laws]

On Mon, Jun 2, 2008 at 8:14 AM, Ramkumar R <[EMAIL PROTECTED]> wrote:

> Hi Simon,
> After downloading the complete latest code from the repository, i noticed
> that the reason for the failure in CouldNotResolveLocation for
> implementation.resource and implementation.widget validation is due to the
> missed code while applying the patch.
>
> The changes suggested in the patch does not seem to appear in the committed
> code. For instance TUSCANY-2344 suggested a change in
> WidgetImplementationProcessor resolve method as shown below, which is
> required for the tests to be sucessfull.
>
> while (reader.hasNext()) {
> @@ -128,8 +149,11 @@
> } catch (IOException e) {
>  ContributionResolveException ce = new
> ContributionResolveException(e);
>  error("ContributionResolveException", resolver, ce);
> -   throw ce;
> +   //throw ce;
> }
> +} else {
> +error("CouldNotResolveLocation", resolver,
> implementation.getLocation());
> +//throw new ContributionResolveException("Could not resolve
> implementation.widget location: " + implementation.getLocation());
> }
> Not sure, if i should open a new JIRA OR reopen the older ones to apply the
> patch again. Please suggest.
>
> Also would be helpful if you could elobrate more about the conversion of
> tests to JUnit4. Thakns.
>
> On 5/29/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > Hi
> >
> > FYI. I've seen a couple of problems with the widget and resource
> validation
> > testing during may latest build. CouldNotResolveLocation doesn't seem to
> be
> > raise. I've @Ignored these tests for now just in case it's going to
> affect
> > others (I changed the test to JUnit4 to make this easy) .
> >
> >
> > As an aside we should probably go through these tests and convert to
> Junit4
> >
> > Also I notice that the original tests I added don't fit into the neat
> > categorization scheme that has been used subsequently so I'll endeavor to
> > move the original tests into the new scheme to tidy things up.
> >
> > Simon
> >
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>

Hi Ram

Can you identify which parts of the patch are missing and create a new patch
based on just these. As they didn't apply properly in the first place I
don't think that trying to apply the existing patch again will have the
desired effect.

Re. Junit4. Some of our tests in Tuscany use JUnit4 and some of them use
older versions of JUnit. As we are creating new tests here it would be
convenient to use the latest version of JUnit.

Regards

Simon

Re: TUSCANY-2344 & 5 - resource & widget validation

[Simon Laws]

On Mon, Jun 2, 2008 at 11:15 AM, Ramkumar R <[EMAIL PROTECTED]> wrote:

> Hi Simon,
> I have provided the fix with TUSCANY-2362 for the same.
>
> For Junit4, let me have a look and provide the changes accordingly.
>
>
> On 6/2/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Jun 2, 2008 at 8:14 AM, Ramkumar R <[EMAIL PROTECTED]>
> wrote:
> >
> > > Hi Simon,
> > > After downloading the complete latest code from the repository, i
> noticed
> > > that the reason for the failure in CouldNotResolveLocation for
> > > implementation.resource and implementation.widget validation is due to
> > the
> > > missed code while applying the patch.
> > >
> > > The changes suggested in the patch does not seem to appear in the
> > committed
> > > code. For instance TUSCANY-2344 suggested a change in
> > > WidgetImplementationProcessor resolve method as shown below, which is
> > > required for the tests to be sucessfull.
> > >
> > > while (reader.hasNext()) {
> > > @@ -128,8 +149,11 @@
> > > } catch (IOException e) {
> > >  ContributionResolveException ce = new
> > > ContributionResolveException(e);
> > >  error("ContributionResolveException", resolver, ce);
> > > -   throw ce;
> > > +   //throw ce;
> > > }
> > > +} else {
> > > +error("CouldNotResolveLocation", resolver,
> > > implementation.getLocation());
> > > +//throw new ContributionResolveException("Could not
> resolve
> > > implementation.widget location: " + implementation.getLocation());
> > > }
> > > Not sure, if i should open a new JIRA OR reopen the older ones to apply
> > the
> > > patch again. Please suggest.
> > >
> > > Also would be helpful if you could elobrate more about the conversion
> of
> > > tests to JUnit4. Thakns.
> > >
> > > On 5/29/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi
> > > >
> > > > FYI. I've seen a couple of problems with the widget and resource
> > > validation
> > > > testing during may latest build. CouldNotResolveLocation doesn't seem
> > to
> > > be
> > > > raise. I've @Ignored these tests for now just in case it's going to
> > > affect
> > > > others (I changed the test to JUnit4 to make this easy) .
> > > >
> > > >
> > > > As an aside we should probably go through these tests and convert to
> > > Junit4
> > > >
> > > > Also I notice that the original tests I added don't fit into the neat
> > > > categorization scheme that has been used subsequently so I'll
> endeavor
> > to
> > > > move the original tests into the new scheme to tidy things up.
> > > >
> > > > Simon
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks & Regards,
> > > Ramkumar Ramalingam
> > >
> >
> > Hi Ram
> >
> > Can you identify which parts of the patch are missing and create a new
> > patch
> > based on just these. As they didn't apply properly in the first place I
> > don't think that trying to apply the existing patch again will have the
> > desired effect.
> >
> > Re. Junit4. Some of our tests in Tuscany use JUnit4 and some of them use
> > older versions of JUnit. As we are creating new tests here it would be
> > convenient to use the latest version of JUnit.
> >
> > Regards
> >
> > Simon
> >
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>

Hi Ram

Thanks for that. The JUnit4 thing is not an emergency. As we create new
tests we can use JUnit4

Simon

Re: wiring to components implemented by a composite

[Simon Laws]

On Thu, May 29, 2008 at 2:59 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Tue, May 27, 2008 at 4:45 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
>>
>>
>> On Tue, May 27, 2008 at 2:53 PM, Simon Laws <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Imagine PolicyOuterComposite
>>>
>>> 
>>> 
>>> >> target="OuterTargetServiceComponent">
>>> 
>>> 
>>> 
>>>
>>> 
>>> 
>>> 
>>> 
>>> http://localhost:8085/OuterTargetServiceComponent"/>
>>> 
>>> 
>>>
>>> And PolicyInnerComposite
>>>
>>>  
>>> 
>>>
>>> 
>>> 
>>> 
>>>
>>> With our current code this doesn't work. The runtime complains that it
>>> can't match the reference targetService with OuterTargetServiceComponent. I
>>> guess my first question is should this work?
>>>
>>> This happens as there is a specific bit code code in the EndpointBuilder
>>> that does the following.
>>>
>>> // if the target service is a promoted service then find the
>>> // service it promotes
>>> if (endpoint.getTargetComponentService().getService() instanceof
>>> CompositeService) {
>>> CompositeService compositeService = (CompositeService)
>>> endpoint.getTargetComponentService().getService();
>>> // Find the promoted component service
>>> ComponentService promotedComponentService =
>>> ServiceConfigurationUtil.getPromotedComponentService(compositeService);
>>> if (promotedComponentService != null &&
>>> !promotedComponentService.isUnresolved()) {
>>>
>>> endpoint.setTargetComponentService(promotedComponentService);
>>> }
>>> }
>>>
>>> Hence the outer service is replaced with the promoted component service
>>> and the outer service configuration isn't used. In this case the service on
>>> the inner component doesn't have the right bindings on it. Looking at the
>>> logs this code has been there for a long time.  Anyone know what the
>>> intention is?
>>>
>>> Simon
>>>
>>
>> I'm making a little bit more progress on this. It seems that, in the case
>> of an automatically generated binding.sca at least, the wires are stored on
>> the target component service. I don't understand why I'm seeing a difference
>> in behaviour with different binding types.
>>
>> Simon
>>
>
> Ok, I looked at this in some detail now and I think we do have a problem
> here.
>
> 
> 
> 
> 
> http://localhost:8085/OuterTargetServiceComponent"/>
> 
> 
>
> And PolicyInnerComposite
>
>  
> 
>
> 
> 
> 
>
> Doesn't work. Moving the binding down into the inner composite service
> doesn't work but moving the binding down to the inner component service does
> work.
>
> I believe the model is just about correct but this code in the builder that
> is converting the target service into the inner target component service is
> incorrect. Indeed the failing combinations are successful if I comment out
> this code. However without this code tests which use binding.sca in this
> situation fail because binding.sca has an "optimization" where it uses the
> component service to create a target invoker for the outbound wire. There
> doesn't seem to be a wire created for the promoted target service. Needs
> further investigation so I'll raise a JIRA to track it.
>
> Simon
>
Raised as https://issues.apache.org/jira/browse/TUSCANY-2352

Simon

Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer

[Simon Laws]

On Mon, Jun 2, 2008 at 8:18 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> Congratulations! You are well deserved.
>
> Thanks,
> Raymond
>
> --
> From: "Vamsavardhana Reddy" <[EMAIL PROTECTED]>
> Sent: Monday, June 02, 2008 11:15 AM
> To: ; <[EMAIL PROTECTED]>
> Subject: Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer
>
>
>  Thank you for this great news.  And thanks to Tuscany PMC for this
>> recognition.
>>
>> ++Vamsi
>>
>> On Mon, Jun 2, 2008 at 11:32 PM, ant elder <[EMAIL PROTECTED]> wrote:
>>
>>  The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany
>>> committer.
>>>
>>> Congratulations and welcome!
>>>
>>>  ...ant
>>>
>>>
Welcome Vamsi. Very well deserved.

Simon

Re: what should happen if service and binding.ws require different soap version?

[Simon Laws]

On Mon, Jun 2, 2008 at 7:40 PM, Gilbert Kwan <[EMAIL PROTECTED]> wrote:

> Currently, Tuscany does not generate any error for both cases (marked
> as "Error").
> I will open a Jira to log this down as Mike suggested
>
> Gilbert
>
>
>
> On Mon, Jun 2, 2008 at 1:09 PM, ant elder <[EMAIL PROTECTED]> wrote:
> > I think right now our binding.ws services (or Axis2 services) will work
> with
> > either SOAP 1.1 or 1.2, and the response from the service will use the
> same
> > soap version as the request. Thats the default Axis2 behaviour, not sure
> if
> > its possible to change to restrict that. So right now the Tuscany code
> only
> > uses the soap intent for references. So those two marked as "Error" below
> > will actually just work with the current Tuscany code.
> >
> >   ...ant
> >
> > On Mon, Jun 2, 2008 at 5:01 PM, Gilbert Kwan <[EMAIL PROTECTED]>
> wrote:
> >
> >> The following table shows all combinations:
> >>
> >> Service Require vs Reference Require:
> >> 
> >> None vs None:  OK
> >> None vs soap: OK
> >> None vs soap.1_1: OK
> >> None vs soap.1_2: OK
> >> soap vs None: OK
> >> soap vs soap: OK
> >> soap vs soap.1_1: OK
> >> soap vs soap.1_2: OK
> >> soap.1_1 vs None: OK
> >> soap.1_1 vs soap: OK
> >> soap.1_1 vs soap.1_1: OK
> >> soap.1_1 vs soap.1_2: Error
> >> soap.1_2 vs None: OK
> >> soap.1_2 vs soap: OK
> >> soap.1_2 vs soap.1_1: Error
> >> soap.1_2 vs soap.1_2: OK
> >>
> >> I guess there are only 2 scenarios should generate error. Right?
> >>
> >> Thanks
> >> Gilbert
> >>
> >>
> >>
> >>
> >> On Mon, Jun 2, 2008 at 6:17 AM, Mike Edwards
> >> <[EMAIL PROTECTED]> wrote:
> >> > Gilbert Kwan wrote:
> >> >>
> >> >> I defined a service requires soap.1_2
> >> >>
> >> >> 
> >> >>  
> >> >>
> >> >>  
> >> >>  
> >> >>
> >> >> 
> >> >>
> >> >> and a reference by ws binding which requires soap.1_1
> >> >>
> >> >> 
> >> >>  
> >> >>
> >> >>  
> >> >>   >> >> uri="http://localhost:8080/BComponentSOAP12"/>
> >> >>
> >> >> 
> >> >>
> >> >> I got no warning, error message, or exception. Is it fine?
> >> >> What is the proper behaviour of this scenario?
> >> >>
> >> >> Thanks
> >> >> Gilbert
> >> >>
> >> > Gilbert,
> >> >
> >> > That looks like an error to me.  Both sides need to be using the same
> >> SOAP
> >> > level.
> >> >
> >> > Looks like a failure of the policy matching between the two ends - I
> >> suggest
> >> > raising a JIRA for this one.
> >> >
> >> >
> >> > Yours, Mike.
> >> >
> >>
> >
>

Should we really be restricting the behavior of the service side SOAP stack?
If your intent is to support 1_2 does that mean we outlaw 1_1 if the SOAP
stack happens to be able to make sense of it?

Simon

Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages

[Simon Laws]

Hi

Some comments in line

Simon

On Mon, Jun 2, 2008 at 12:30 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Folks,
>
> Thinking about this further, we should I think come up with a common and
> consistent model for the handling of problems found during model processing.
>
> Let me make a proposal or two that folk can throw rocks at if they please:
>
> - Model processor code should NEVER throw an exception that escapes the
> processor code (clearly this would exclude the common JVM nasties like
> running out of memory) - doesn't matter what type of exception (1, 2, 3, 4
> in the previous discussions...)


How do we define the processor code? Here are a couple of examples.

>From stax artifact processor.
M read(XMLStreamReader reader) throws ContributionReadException,
XMLStreamException;

>From composite builder
void build(Composite composite) throws CompositeBuilderException;

I like the idea of saying NEVER throw an exception but this has to be
restricted to well defined processing steps, e.g. those that and extension
writer would author (Read, Write, Resolve). As an alternative and in order
to maintain the current API such exceptions could be captured in the
ExtensibleStAXArtifactProcessor.



>
> - Throwing exceptions within the scope of the model processor is fine - it
> is just that they must all get caught at the boundary of the code.
>
> - Reporting monitor type messages for the problems found (or perhaps also
> for the cases of success too!) should be routine
>

+1


>
> - When problem(s) are encountered, the model processor MUST
>
> a) Return a model object


+1


>
> b) Mark that model object as "unresolved" - this should ensure that no-one
> tries to instantiate it


Without some detailed investigation I can't say if some subsequent
resolution phase will treat the unresolved flag correctly. I would hope that
the read phase creates errors where appropriate and, subsequent to the read
phase the monitor is analysed to see if any errors have been reported.
Resolution would generally be prevented if this is the case.


>
> c) If any of the code DOES try to instantiate some unresolved model object,
> we need to go fix that code
>

+1


>
>
> We need to think hard about where particular errors should get logged
> though.  Some errors will belong in the composite model object - eg a <
> binding.ws/> element turning up immediately under the 
> element.  Others belong in some specific component implementation model
> object or binding object
>

Agreed, problems should be reported in the context of the model object
within which they are being processed.


>
> Yours,  Mike.
>
> snip

Re: what should happen if service and binding.ws require different soap version?

[Simon Laws]

On Mon, Jun 2, 2008 at 9:41 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Simon Laws wrote:
>
>>
>> Should we really be restricting the behavior of the service side SOAP
>> stack?
>> If your intent is to support 1_2 does that mean we outlaw 1_1 if the SOAP
>> stack happens to be able to make sense of it?
>>
>> Simon
>>
>>  Simon,
>
> This all depends on what you think is meant when the intent "SOAP.1_2" is
> applied to either a service or to a reference.
>
> The way it was designed is that it says "This service/reference must use
> SOAP encoding at the 1.2 level of the spec".
>
> It does not mean "Use SOAP.1_2 if you can but SOAP.1_1 will do as well".
>
> So strictly, the current Tuscany implementation is in error.  It will use
> SOAP 1.1 encoding even when it has been told to use 1.2.
>
> Take an example (not a good one for SCA, it must be admitted) where the
> server messes with SOAP Headers only defined in SOAP 1.2.  It would
> naturally mark itself as requiring "SOAP.1_2".  If SOAP 1.1 were used
> instead, those extra headers would not be legal SOAP 1.1.
>
> If you want to require SOAP encoding but you don't care about the level,
> just specify "SOAP" as the intent - this permits any level of SOAP encoding.
>
>
> Yours,  Mike.
>

Hi Mike

Sticking a pin in the specs it does say what you are saying. I was thinking
"must support" as opposed to "must use" on the service side. Within an SCA
domain in Tuscany I believe that the binding matching code will fail to
match soap.1_1 and soap.1_2 intents. Crossing the domain boundary what would
be the intended action if a soap 1.1 message arrived at a service that is
marked as soap 1.2. A response indicating that the message is not
understood?

Simon

Re: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin

[Simon Laws]

On Wed, May 21, 2008 at 2:56 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Fri, May 16, 2008 at 9:26 AM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> > ...snip
> >
> > >
> > > The two sets of SPIs could co-exist for a while with BindingProviders
> > > working with bindings and ServiceProviders (I just made up that name)
> > with
> > > service endpoints.
> > > --
> > > Jean-Sebastien
> >
> >
> > At r656959 I've just enabled some changes to take a step toward using an
> > Endpoint representation in the model as an alternative to using cloned
> > bindings as the representation of valid reference targets. It's not
> > replacing the cloned binding approach just yet, to avoid breaking
> anything,
> > but is the first step on the road. This is what I have done.
> >
> > Made a new Endpoint model type
> > Created a separate factory for it (separate as I though the model may
> need
> > to be pluggable as some point)
> > Created a new EndpointProvider type and associated factory.
> > Created an Endpoint module to provide a provider implementation.
> > Created an Endpoint wire to trap attempted calls over unresolved
> endpoints
> > Separated off the Endpoint builder code into a new builder class. Same
> code
> > but easier to identify.
> > Added an endpoint collection to references
> > Used the Endpoint in the wire builder in place of the old internal target
> > structure. The logic is weaved in to the existing logic as follows.
> >  For references with no target, put the binding into reference binding as
> > before
> >  Create an Endpoint for all explicit reference targets
> >  For resolved endpoints (Endpoints where the target is resolved) put the
> > binding into reference bindings, i.e. the same as before
> >  For unresolved endpoints create an endpoint provider and a wire. We
> don't
> > have unresolved targets in tuscany (except in the sca binding test) so
> > should not happen. If you do put a target name in that can't be matched
> > with
> > a service you'll get a warning.
> >
> > If there is no Endpoint module on the classpath it will not create a
> > provider or a wire hence disabling any Endpoint based processing. The
> > Endpoint model will still be used though
> >
> > As part of this change I've updated the logic that looks for target names
> > in
> > binding uri. It's now applied to all binding types which I believe is
> what
> > the spec says, There is though an issue here. I'll raise a separate
> thread.
> >
> > There are also a couple of thoughts I had.
> >
> > Can we make the CompositeBuilderImpl have just one constructor?
> > Should builders be pluggable?
> > I've used some of the CompoisteActivator functions in the EndpointWire
> that
> > could do with moving into the activator interface.
> >
> > Simon
> >
>
> Last week i updated the runtime-tomcat module to use this Endpoint code to
> get the Tomcat deep integration with webapps talking to each other as being
> discussed in [1] and [2]. Its a complete hack at the moment but at least
> gives a start at something more real to be talking about in those threads.
>
> You can try it by building the runtime-tomcat module, and the doing a "mvn
> dependency:copy-dependencies"
>
> - in tomcat conf/catalina.properties add the runtime-tomcat jar and
> dependencies:
>  common.loader=${catalina.home}/lib,${catalina
>
> .home}/lib/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/dependency/*.jar
>
> - in tomcat conf/server.xml add the TuscanyHost class name to the localhost
> definition, eg:
>  className="org.apache.tuscany.sca.runtime.tomcat.TuscanyHost"
>unpackWARs="true" autoDeploy="true"
>xmlValidation="false" xmlNamespaceAware="false">
>
> Now you can deploy webapps to tomcat without needing to include _any_
> Tuscany stuff in the webapp - no tuscany jars or web.xml config. You can
> try
> it with the calculator-webapp and calculator-ws-webapp samples, delete all
> the jars and Tuscany web.xml config from the webapps and delete the
> subtract
> component and impl from the calculator-ws-webapp and it should all still
> work with the caclulator-ws-webapp using the subtract component in the
> calculator-webapp sample.
>
>   ...ant
>
> [1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
> [2] http://apache.markmail.org/message/l7pgz2sxuitdhmxm
>

Re: [Vote] Release Tuscany Java SCA 1.2.1 (RC1)

[Simon Laws]

On Wed, Jun 4, 2008 at 6:46 AM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> ant elder wrote:
>
>> Please review and vote on the release artifacts for the Tuscany SCA for
>> Java
>> 1.2.1 maintenance release.
>>
>> The artifacts are available for review at:
>> http://people.apache.org/~antelder/tuscany/1.2.1-RC1/
>> 
>>
>> This includes the signed binary and source distributions, Maven staging
>> repository, and eclipse update site.
>>
>> The SVN tag for the release is:
>> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2.1
>>
>> The _only_ code change in this over the 1.2 release is in r657526 [1], all
>> other changes are just version updates and doc changes for the release.
>>
>> +1 to release from me.
>>
>>   ...ant
>>
>> [1]
>>
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200805.mbox/[EMAIL
>>  PROTECTED]
>>
>>  Folks,
>
> I am at an SCA spec F2F meeting this week and I will not have the time to
> review this RC - apologies in advance.
>
> I'm in favour of doing the update release.
>
> Yours,  Mike.
>

Hi

I ran a few samples, Rat looks good, versions/dates on READMEs etc. look
good.

+1

Simon

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[Simon Laws]

On Wed, Jun 4, 2008 at 1:34 PM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:

> 2008/6/4 ant elder <[EMAIL PROTECTED]>:
> > Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need to
> > remove "incubating" at some point and as its not clear if the next
> release
> > would be 2.0 or something else so i wondered if we should also remove the
> > 2.0 giving a trunk version of simply "SNAPSHOT"? Any comments on that or
> the
> > timeframe for doing the change? I'd like to do it nowish so we have some
> > time to discover any problems before the next release.
> >
> >   ...ant
> >
>
> Hi ant,
> could you try a fresh build from svn?
> I've some problems with and I 'd go on with my work before we're
> arriving to 2.0.
>
>
> Ciao,
> Giorgio.
> ---
> "Venceremos adelante, o victoria o muerte!"
>

I agree that it doesn't feel like the next release will be 2.0
I would prefer that we keep the trunk compatible with our 1.X level APIs for
the time being as it feels like there is still a more 1.X releases to do
If people are going to start making breaking changes in a branch (we
discussed this under the 2.0 thread but it's not happening yet) then it
would be useful to me to have the trunk poms marked with 1.X SNAPSHOT so
that I know by looking on my disc what I'm working with
When (if?) the time comes down the line to break from our 1.X APIs we could
then go to SNAPSHOT  or 2.0 SNAPSHOT

Regards

Simon

Re: ExtensibleStAXArtifactProcessor should register error when unsupported implementation or binding types are found

[Simon Laws]

On Wed, Jun 4, 2008 at 3:10 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> I believe that we log a warning that an unknown element is encountered.
> Isn't it sufficient?
>
> Thanks,
> Raymond
> --
> From: "Ramkumar R" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 04, 2008 4:37 AM
> To: 
> Subject: Re: ExtensibleStAXArtifactProcessor should register error when
> unsupported implementation or binding types are found
>
>
>  Hi Hasan,
>>
>> The ideal place to catch these exceptions seems to be in the
>> ExtensibleStAXArtifactProcessor read method, i think it would not be
>> possible to categorize the exception based on implementation and binding
>> at
>> this stage.
>>
>> I believe it would be possible to throw a generic exception saying that
>> this
>> element is not supported by the runtime as it does not have a suitable
>> processor to proceed.
>>
>> Let me know your say on this. Thanks.
>> On 6/3/08, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Hi Simon,
>>>
>>> I have raised JIRA 2365 to address this issue.
>>>
>>> regards
>>> Hasan
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>>
>>
The warning also contains the name of the element that could not be found so
in your code you could look out for the "ElementCannotBeProcessed" warning
registered with the monitor and then take a look at the name parameter
provided in this case to work out what sort of extension is missing.

Regards

Simon

Re: what should happen if service and binding.ws require different soap version?

[Simon Laws]

On Tue, Jun 3, 2008 at 1:12 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Simon Laws wrote:
>
>>
>> Hi Mike
>>
>> Sticking a pin in the specs it does say what you are saying. I was
>> thinking
>> "must support" as opposed to "must use" on the service side. Within an SCA
>> domain in Tuscany I believe that the binding matching code will fail to
>> match soap.1_1 and soap.1_2 intents. Crossing the domain boundary what
>> would
>> be the intended action if a soap 1.1 message arrived at a service that is
>> marked as soap 1.2. A response indicating that the message is not
>> understood?
>>
>> Simon
>>
>>  Simon,
>
> The SOAP 1.2 spec itself deals with what happens on a version mismatch of
> this kind and it describes in detail the error response message that must be
> sent under circumstance where the versions do mismatch in exactly this way.
>
>
> Yours,  Mike.
>
> PS Maybe Axis does not follow the SOAP 1.2 spec
>

Ah, so it does. Thanks for the pointer!

Simon

Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages

[Simon Laws]

Hi

More comments in line

Simon


>
> Hi Simon,
> Initially our idea was to disable most of the exception throws from the
> processors and log the warnings/exception via the monitors. Lets say we
> might still leave some exceptions to be thrown like the type1 exceptions,
> in
> such cases me might end up only throwing IOExceptions /
> XMLStreamExceptions.
>
> From stax artifact processor.
> M read(XMLStreamReader reader) throws ContributionReadException,
> XMLStreamException;
>
> Here the processor would never throw ContributionReadException, when the
> exceptions are blocked as most of the ContributionReadException are of
> type1, 2 or 3.


Do you mean type  2, 3 & 4 here. I still expect us to throw type 1
exceptions.

>
>
> Do you believe we should maintain the current API in such cases?
>
>
>
I would leave the interface as is for the time being while we work through
the various exceptions. To see if there are any we can't deal with.

Re: [jira] Created: (TUSCANY-2372) Unable to build with 1.6 JDK due to JAXB conflict

[Simon Laws]

On Thu, Jun 5, 2008 at 2:13 PM, James Rutherford <[EMAIL PROTECTED]>
wrote:

> On Thu, Jun 05, 2008 at 12:43:07PM +, Mike Edwards wrote:
> > James Rutherford (JIRA) wrote:
> > > Unable to build with 1.6 JDK due to JAXB conflict
> > > -
> > >
> > >  Key: TUSCANY-2372
> > >  URL:
> https://issues.apache.org/jira/browse/TUSCANY-2372
> > >  Project: Tuscany
> > >   Issue Type: Bug
> > >   Components: Build System
> > > Affects Versions: Java-SCA-1.2
> > >  Environment: % java -version
> > > java version "1.6.0_03"
> > > Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
> > > Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)
> > >
> > > % mvn -version
> > > Maven version: 2.0.8
> > > Java version: 1.6.0_03
> > > OS name: "linux" version: "2.6.24-gentoo-r3" arch: "i386" Family:
> "unix"
> > > Reporter: James Rutherford
> > >
> > >
> > > Error running 'mvn' command due to conflict with JAXB API provided by
> 1.6 JDK:
> > >
> > James,
> >
> > I think that this should be closed "no action" since the fix is to
> > move up to 1.6.0_05 of the JDK.
>
> OK, I'll upgrade my JDK and verify the fix. Where is this fix
> documented? I searched for a while, but couldn't find anything.
>
> cheers,
>
> Jim
>
> --
> James Rutherford  |  Hewlett-Packard Limited registered Office:
> Research Engineer |  Cain Road,
> HP Labs   |  Bracknell,
> Bristol, UK   |  Berks
> +44 117 312 7066  |  RG12 1HN.
> [EMAIL PROTECTED]   |  Registered No: 690597 England
>
> The contents of this message and any attachments to it are confidential
> and may be legally privileged. If you have received this message in
> error, you should delete it from your system immediately and advise the
> sender. To any recipient of this message within HP, unless otherwise
> stated you should consider this message and attachments as "HP
> CONFIDENTIAL".
>

Apologies Jim.

Raymond posted on this subject before [1] and suggested we put it in our
FAQ. It doesn't seem to have made it there so I'll go and update it now.

Regards

Simon

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

Re: Reference with multiplicity being initialized with references to the same component

[Simon Laws]

On Fri, Jun 6, 2008 at 8:50 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> I was trying to use a reference with multiplicity (see composite
> below), and looks like the reference is being populated with two
> references for the same component, instead of one reference for each
> component.  Any ideas why this is happening ?
>
> BTW, I'm using the Eclipse Plugin from 1.2 release to run the application.
>
> http://www.osoa.org/xmlns/sca/1.0";
>xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
>targetNamespace="http://discover";
>name="discover_enterprise">
>
>
> class="services.map.ConfigurationDiscoverFederator"/>
> target="ComputerConfigurationDiscoverServiceComponent
> NetworkConfigurationDiscoverServiceComponent">
>
>
>
>
>
> class="services.map.ComputerConfigurationDiscover"/>
>
>
>
>
>
>
> class="services.map.NetworkConfigurationDiscover"/>
>
>
>
>
> 
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>

Hi Luciano

Note sure although this code has changed a bit recently with the Endpoint
work. I'm renaming the EndpointProvider to be called EnpointResolver at the
moment so I'll take a look and see if this is still happening. Is this test
checked in?

Simon

Release 1.3?

[Simon Laws]

It's been a little while now since we did our 1.2 release. Since then there
has been lots of activity and of course we have graduated. It feels like the
right time to do a 1.3 release. Looking back at the mail list over the last
couple of months there are quite a few candidates for inclusion that I can
see;

Better BPEL support
Improvements to the domain manager app
Improved runtime Java2WSDL processing
Support for validation monitoring
Databinding improvements
Performance improvements
JSR250 annotation support
OSGi support improvements and a simple OSGi runtime test
Java 2 security enablement
Quite a few more tests for various parts of the runtime
Lots of JIRA fixes.
and of course we can remove the "incubating" assignment and drum up a bit of
publicity for our TLP graduation

I'd also like to have a bit of a tidy up for this release and remove the old
domain modules we are no longer using (I'll post on this separately)

What else has been added or changed?

I think the things I would like to get done can be closed off next week
ready to cut a branch.

Thoughts?

Simon

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[Simon Laws]

On Fri, Jun 6, 2008 at 9:17 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> How about 1.5-SNAPSHOT ? This would probably give us some room to have
> couple releases without the necessity to keep updating the trunk pom
> version. And this would probably make everybody happy :)
>
> On Fri, Jun 6, 2008 at 1:14 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende <[EMAIL PROTECTED]>
> > wrote:
> >
> >> I guess part of problem here is because a lot of people assume that
> >> the maven artifact version represents what is going to be our next
> >> release and then, if it's set as 2.0-SNAPSHOT, it means our next
> >> release would be 2.0.
> >
> >
> > I agree, this is exactly the issue. But I'm not sure its that much of an
> > unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as
> the
> > trunk version before there has been any decision to start working on a
> 2.0
> > in trunk.
> >
> >   ...ant
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>

My feeling about this have been galvanized by our previous conversations
about doing some development work at some point in the future to improve the
APIs/SPIs in backwardly incompatible ways. We previously discussed this
under the banner of a 2.0 code base which still sounds sensible. If we do
that at some point in the future then we will have a 1.X code based which
our existing users will rely on and a 2.X code base which our users may move
to over time. I'd like it to be clear when working on a code base, making
releases from a code base or just providing snapshots what flavour of
Tuscany is involved. Releases take care of themselves but this is why I'd
like to see some reference to version 1 in Trunk be maintained. We don't
commit to a particular release number until the start discussing each
release and cut the branch. Hence that's why I was happy with using 1.X.

Regards

Simon

Re: Red Hat/JBoss involvement with Tuscany

[Simon Laws]

On Fri, Jun 6, 2008 at 10:57 AM, Mark Little <[EMAIL PROTECTED]> wrote:

> Hi, I just wanted to let people know officially that people from Red
> Hat/JBoss will be getting involved with Tuscany over the coming months as we
> look at the best way in which to provide SCA support for our SOA Platform
> users. We're very excited about helping on Tuscany and complimenting the
> work we're doing at OASIS.
>
> Mark.
>
> 
> Mark Little
> [EMAIL PROTECTED]
>
> JBoss, a Division of Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street,
> Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> (USA) and Brendan Lane (Ireland).
>
>
Hi Mark

That's exciting news indeed. Welcome to you all!

Regards

SimonL

Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages

[Simon Laws]

On Fri, Jun 6, 2008 at 1:35 PM, Ramkumar R <[EMAIL PROTECTED]> wrote:

> Hi Simon,
> After disabling most of the exceptions, now i face a problem in the itest
> validations as we generally check for the last reported problem to verify
> the results. Now due to disabled exception the processing continues furthur
> and more problems are reported even after the one we are expecting.
>
> Hence the getLastLoggedProblem method in the monitor does not help us
> anymore.
>
> I have now introduced a HashMap in the monitor to cache all the problem
> reported, so that we could analyze them and see if the expected errors are
> reported. Here is the piece of code that is being added in the monitor now.
>
> // Cache all the problem reported to monitor for furthur analysis
> private Map problemCache = new HashMap();
>
> public boolean isMessageLogged(String messageId) {
>   if (problemCache.containsKey(messageId)) return true;
>   else return false;
> }
>
> Like to know your thoughts on it. Thanks.
> On 6/6/08, Ramkumar R <[EMAIL PROTECTED]> wrote:
> >
> > On 6/5/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> >>
> >> >
> >> > Here the processor would never throw ContributionReadException, when
> the
> >> > exceptions are blocked as most of the ContributionReadException are of
> >> > type1, 2 or 3.
> >>
> >>
> >> Do you mean type  2, 3 & 4 here. I still expect us to throw type 1
> >> exceptions.
> >>
> > Hi Simon,
> > You are right, i meant it to be type 2, 3 & 4 exceptions here. Sorry for
> > the typo error.
> >
> > --
> > Thanks & Regards,
> > Ramkumar Ramalingam
> >
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam


Hi Ram

Sounds like a good idea. Was this added to DefaultMonitorImpl or
DefaultLoggingMonitorImpl?

Now that we have a default monitor that logs messages and is used if no
extension monitor is provided the name of the monitor-logging module looks
out of place. I'd like to rename that to be something like monitor-caching
or something similar so that your new map can go there. If people don't want
to store up monitor messages they can just drop out  that module and either
fall back to the default implementation or provide their own. Does that
sound sensible?

If so feel free to go ahead and make the code changes. If you create a new
monitor module with a suitable name I'll add the new one and delete the old
one. Don't worry about doing a patch for the rename as I imagine that could
get tricky.

Simon

Re: Build failure in helloworld-bpel sample

[Simon Laws]

On Fri, Jun 6, 2008 at 3:33 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Fri, Jun 6, 2008 at 2:49 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> > Simon Nash wrote:
> >
> >> I did a recent svn update and rebuild and I'm seeing the following test
> >> error from the helloworld-bpel sample.  Are other people seeing this?
> >> Any ideas?
> >>
> >>  Simon
> >>
> >>  I have committed a fix (or at least a workaround) for this build
> > break problem.  The revision number is r663938.
> >
> >
> Just to confirm, this has fixed the problem for me and the sample now
> builds
> ok.
>
>   ...ant
>

It fixed the problem for me but now itest/bpel fails. It didn't before this
latest patch so it seems that it is expecting the extra layer of data
wrapping for some reason.

Simon

Re: [C++] ODBC and accessing Generated Keys

[Simon Laws]

On 1/2/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:


We are trying to get the auto-gererated keys after the invocation of the
SQLPrepare function of ODBC API. For example, the SQLPrepare is called
with
an insertion statement "INSERT INTO table1 values(?, ?, ?)". The odbc must

send this statement to the DBMS, the DBMS compile it and waits for the
parameters and its execution.

However there are some DBMSs that auto-generates the primary keys and is
capable to retrieve the auto-generated PKs right after the statement
compilation and before its execution. It's exactly what we're trying to
do,
to retrieve the auto-generated PKs before the statement execution.

I wonder if it has something to do with the IPD(Implementation Parameter
Descriptor) that I found in ODBC API: SQL_ATTR_AUTO_IPD.

Adriano Crestani

On 1/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Luciano Resende wrote:
> > Hi
> >
> >   I'm trying to work with Adriano Crestani in a C++ version of DAS and
> we
> > are trying to figure out how to get access to the generated keys after
> > the
> > execution of a prepared statement. Would you guys, the C++ experts, be
> > able
> > to give us some pointers/references or examples ?
> >
>
> Luciano,
>
> I'll be happy to help but I'll need a little more context :) generated
> keys? a prepared statement? hmm what about starting with an overview of
> what you're trying to do? which database? version? operating system?
> what kind of examples are you looking for?
>
> Thanks
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Hi Adriano


I have to admit that I'm not an ODBC expert but there are a couple of things
that I don't understand in your question.


We are trying to get the auto-generated keys after the invocation of the

SQLPrepare function of ODBC API.

1/ By "auto-gererated keys" do you mean
 a) Manually defined columns which auto increment or otherwise generate an
automatic key
 b) Magic DBMS columns that uniquely identify a row (and are likely to be
specific to the DBMS)

I'm assuming you are doing 1a)

2/ By "trying to get the auto-gererated keys after the invocation of the
SQLPrepare" do you mean
 a) You are trying to get at the column meta data
 b) You are trying to get at the key values

I assuming 2a) here as I don't understand why you would be trying to get the
key value before the execute. Maybe you can provide some more detail.

Given 1a) then retrieving the meta data for the column (2a) should not be
any different than with any other column. I took a quick look at ODBC API:
SQL_ATTR_AUTO_IPD and, despite the usual paucity of ODBC documentation, this
does seem to be to do with populating the IPD with column meta data
automatically. It is optional though so your driver might not support it. If
you can't get the meta data through the prepared statement then you would
have to use another approach, for example, you might have to resort to the
catalog.  Anyhow, the best I can suggest at the moment it that you try it
and see what happens.

As Jean-Sebastien suggested if you provide us with a little more info, for
example, a sample table description and some details about what you are
trying to achieve we may be able to help a little more.

Regards

Simon

Re: [SDO] Literal value support, especially for anyType/anySimpleType

[Simon Laws]

On 1/2/07, Yang ZHONG <[EMAIL PROTECTED]> wrote:


451 has illustrated the element content isn't stored.

On 1/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Yang ZHONG wrote:
> > I'm working on http://issues.apache.org/jira/browse/TUSCANY-451,
> > which may need us to support literal value.
> > What's your opinion?
> >
> > Although the issue was opened against C++,
> > it also applies to other programming languages including Java since
> > it's a
> > issue of XML and its memory representation.
> >
> > Given XSD:
> >
> > and XML:
> >anyType literal value
> >
> > Since no concrete type info such as int/string and so on to parse out
a
> > memory representation, literal value may need to be stored.
> > Do you have alternative(s) to keep fidelity?
> >
> > Literal value support can benefit performance too. Parsing literal
> > value for
> > the memory representation can be deferred until a user accesses the
> > value.
> > On the other hand, (weakly) referencing literal value after parsing
> > can make
> > saving as XML instant.
> > Do you agree with the 2-way performance gain?
> >
> >
> > Happy New Year.
> >
> Yang,
>
> What do you mean by storing the literal value?
>
> In the absence of any type info shouldn't the element content just be
> stored as a string?
>
> Thanks,
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--

Yang ZHONG

Hi Yang


451 was logged as a result of running the interop schema (
https://svn.apache.org/repos/asf/incubator/tuscany/interop/src/main/resources/interop50-in.xml).
AFAIK this is still an issue but I can't check because my laptop is messed
up (I'm trying to fix it now:-). When I ran the test as described the result
was that whatever data appeared on the input was not reflected on the
output. I don't know if this is because it's not actually stored internally
in SDO or because it's not written out when the time comes to recreate the
XML from the SDO.

I don't know off the top of my head how SDO deals with anyType. Looking at
the schema parser code
(https://svn.apache.org/repos/asf/incubator/tuscany/cpp/sdo/runtime/core/src/commonj/sdo/SDOSchemaSAX2Parser.cpp
) it doesn't seem to take any special notice of "anyType". I may of course
be looking in the wrong place. I would assume it would have to do something
similar to the way that it handles "any" elements, i.e.open content. The
difference is that you already have a property name in the element that is
defined as being of "anyType". So you would have to generate a type for this
property with open content and assume that it is also mixed  to handle the
case that  either  simple type, complex type or  both types of data have to
be represented within this property.

To move this along a bit can you could take a look and see if there is any
of this kind of function in the implementation as it stands.

Regards

Simon

Re: [C++] ODBC and accessing Generated Keys

[Simon Laws]

On 1/3/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:


Sorry Simon, yes, it's really what you are assuming. We are trying to get
the key values.

I was checking again how the DAS Java get the auto-generated PKs and it
tries to get it right after the statement execution and not before as I
was
saying on my last message.

I'd want to know a way to retrieve the auto-generated PKs whitout I read
from the database after the insertion statement. There is a way to set on
jdbc whether you want or not that the insertion statement store the
auto-generated PKs for later reading. Example using jdbc:

PrepareStatement ps = connection.prepareStatement("INSERT INTO item(descr,
units) VALUES('teste', 5);", Statement.RETURN_GENERATED_KEYS);
  ps.execute();
  ResultSet rs = ps.getGeneratedKeys();

The item table has an auto-generated PK called ID. This insertion
statement
when is executed auto-generates the item PK. I'd like to know a way to
retrieve this PK on odbc without using another statement like a "select"
statement just to read the PK.

Adriano Crestani


On 1/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 1/2/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> >
> > We are trying to get the auto-gererated keys after the invocation of
the
> > SQLPrepare function of ODBC API. For example, the SQLPrepare is called
> > with
> > an insertion statement "INSERT INTO table1 values(?, ?, ?)". The odbc
> must
> >
> > send this statement to the DBMS, the DBMS compile it and waits for the
> > parameters and its execution.
> >
> > However there are some DBMSs that auto-generates the primary keys and
is
> > capable to retrieve the auto-generated PKs right after the statement
> > compilation and before its execution. It's exactly what we're trying
to
> > do,
> > to retrieve the auto-generated PKs before the statement execution.
> >
> > I wonder if it has something to do with the IPD(Implementation
Parameter
> > Descriptor) that I found in ODBC API: SQL_ATTR_AUTO_IPD.
> >
> > Adriano Crestani
> >
> > On 1/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > >
> > > Luciano Resende wrote:
> > > > Hi
> > > >
> > > >   I'm trying to work with Adriano Crestani in a C++ version of DAS
> and
> > > we
> > > > are trying to figure out how to get access to the generated keys
> after
> > > > the
> > > > execution of a prepared statement. Would you guys, the C++
experts,
> be
> > > > able
> > > > to give us some pointers/references or examples ?
> > > >
> > >
> > > Luciano,
> > >
> > > I'll be happy to help but I'll need a little more context :)
generated
> > > keys? a prepared statement? hmm what about starting with an overview
> of
> > > what you're trying to do? which database? version? operating system?
> > > what kind of examples are you looking for?
> > >
> > > Thanks
> > >
> > > --
> > > Jean-Sebastien
> > >
> > >
> > >
-
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > Hi Adriano
>
> I have to admit that I'm not an ODBC expert but there are a couple of
> things
> that I don't understand in your question.
>
> > We are trying to get the auto-generated keys after the invocation of
the
> SQLPrepare function of ODBC API.
>
> 1/ By "auto-gererated keys" do you mean
>   a) Manually defined columns which auto increment or otherwise generate
> an
> automatic key
>   b) Magic DBMS columns that uniquely identify a row (and are likely to
be
> specific to the DBMS)
>
> I'm assuming you are doing 1a)
>
> 2/ By "trying to get the auto-gererated keys after the invocation of the
> SQLPrepare" do you mean
>   a) You are trying to get at the column meta data
>   b) You are trying to get at the key values
>
> I assuming 2a) here as I don't understand why you would be trying to get
> the
> key value before the execute. Maybe you can provide some more detail.
>
> Given 1a) then retrieving the meta data for the column (2a) should not
be
> any different than with any other column. I took a quick look at ODBC
API:
> SQL_ATTR_AUTO_IPD and, despite the usual paucity of ODBC documentation,
> this
> does seem to be to do with populating the IPD with column meta data
> automatically. It is o

[C++] PHP SCA extension for C++ SCA

[Simon Laws]

Ok, so after a rather lengthy (and relaxing) Christmas break I'm starting to
work again on building up the PHP capability in the C++ SCA implementation.
There was some work done before Christmas documented on our PHP SCA site
here [1]. There were some previous mail exchanges talking about the problem
generally [2] and talking about the slight discontinuity between the way
that composition is represented in PHP SCA annotations compared to the SCA
SCDL files in C++ SCA [3].

The first thing I'm going to do is get the existing C++ PHP Extension up and
running again and submit any changes that are required now that C++ SCA has
moved on and I'm on to a new version of PHP. I'll add some more detail to
the README about what to do. This note was just to get the ball rolling
again so I'm sure there will be lots more issues to discuss very shortly.

Regards

Simon

[1] - http://www.osoa.org/display/PHP/PHP+SCA+Extension+For+Tuscany+CPP+SCA
[2] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11572.html
[3] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11747.html

[C++] Scenarios for motivating demonstrating scripting support in Tuscany.

[Simon Laws]

In thinking about PHP support in C++ one thing that I would like is some
good scenarios that we can use as test cases and examples. Its good to
reproduce the test cases we have, e.g. Calculator, to show how the same
scenario can be reproduced across different environments. To this end I am
working up the PHP version of Calculator again. However it would be good to
have some examples that speak to those who use scripting for real.

Three things come immediately to mind.

1/ Building and deploying services behind Web2.0 applications.
Examples here would be a service that retrieves some data from a database
for the Web2.0 application or a service that ties into a wider SCA
composition for retrieving data or processing requests.

2/ Shell type applications, e.g. Composing SCA components as a analog for
composing script operations on the command line.
An example here would be a  service composition  that needs access to the
ability to copy, move, filter or format file based information. The generic
example is I supose traditional scripted batch or job control processing.

3/ As a suitable component implementation language where the script
environment is either familiar to the developer or offers some specific
feature or library that mandates it's use, for example, some application
specific data access library or processing capability. For example, we could
look into integrating with one of the popular open source applications, such
as a wiki, to see if we can create a simple example of accessing its data as
part of a wider composition.

Anyhow, just some thoughts off the top of my head. Are there any more that
spring to people's minds that allow us to show off the power of SCA to
compose scripted components into a simple useful running example?

Not sure what to do with this list. I could put it on our PHP site but then
only PHP people can edit it. Shall I put on the Tuscany wiki?

Regards

Simon

[C++] Build problem with PHP extension

[Simon Laws]

I'm trying to compile up the php extension again. This has worked previously
with Visual C++ Express but I'm getting the following

Deleting intermediate and output files for project 'tuscany_sca_php',
configuration 'Debug|Win32'
Compiling...
PHPImplementation.cpp
PHPServiceBinding.cpp
c:\simon\projects\eclipse3.2\cpp\sca\deploy\include\tuscany\sca\core\operation.h(171)
: warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data
PHPExtension.cpp
c:\simon\projects\eclipse3.2\cpp\sca\deploy\include\tuscany\sca\core\operation.h(171)
: warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data
PHPImplementationExtension.cpp
c:\simon\projects\eclipse3.2\cpp\sca\deploy\include\tuscany\sca\core\operation.h(171)
: warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data
PHPServiceWrapper.cpp
c:\simon\projects\tuscany\php\php-5.2.0\zend\zend_execute.h(143) : warning
C4311: 'type cast' : pointer truncation from 'void *' to 'ulong'
c:\simon\projects\tuscany\php\php- 5.2.0\zend\zend_execute.h(157) : warning
C4311: 'type cast' : pointer truncation from 'void *' to 'ulong'
c:\simon\apps\vcexpress2005\vc\include\xutility(191) : warning C4273:
'std::_Container_base::_Orphan_all' : inconsistent dll linkage
   c:\simon\apps\vcexpress2005\vc\include\xutility(109) : see previous
definition of '_Orphan_all'
c:\simon\apps\vcexpress2005\vc\include\xutility(203) : warning C4273:
'std::_Container_base::_Swap_all' : inconsistent dll linkage
   c:\simon\apps\vcexpress2005\vc\include\xutility(110) : see previous
definition of '_Swap_all'
c:\simon\apps\vcexpress2005\vc\include\ostream(964) : error C2491:
'std::endl' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\ostream(973) : error C2491:
'std::endl' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\ostream(982) : error C2491:
'std::ends' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\ostream(990) : error C2491:
'std::ends' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\ostream(998) : error C2491:
'std::flush' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\ostream(1006) : error C2491:
'std::flush' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\istream(1061) : error C2491:
'std::ws' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\istream(1096) : error C2491:
'std::ws' : definition of dllimport function not allowed
c:\simon\projects\eclipse3.2\cpp\sca\deploy\include\tuscany\sca\core\operation.h(171)
: warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data
Generating Code...

Ignoring the warning for a moment anyone see C2491 in any of the other
projects. it kind of rings a bell but I can't dredge it out on my mind. I
have previously successfully compiled this extension with the same versions
of VC++ and PHP as I have now. Has something changed in the solution file
that I'm inheriting from in my project but that I'm not spotting?

Regards

Simon

Re: [C++] Build problem with PHP extension

[Simon Laws]

On 1/5/07, Simon Laws <[EMAIL PROTECTED]> wrote:


I'm trying to compile up the php extension again. This has worked
previously with Visual C++ Express but I'm getting the following

Deleting intermediate and output files for project 'tuscany_sca_php',
configuration 'Debug|Win32'
Compiling...
PHPImplementation.cpp
PHPServiceBinding.cpp
c:\simon\projects\eclipse3.2\cpp\sca\deploy\include\tuscany\sca\core\operation.h(171)
: warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data
PHPExtension.cpp
c:\simon\projects\eclipse3.2\cpp\sca\deploy\include\tuscany\sca\core\operation.h(171)
: warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data
PHPImplementationExtension.cpp
c:\simon\projects\eclipse3.2\cpp\sca\deploy\include\tuscany\sca\core\operation.h(171)
: warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data
PHPServiceWrapper.cpp
c:\simon\projects\tuscany\php\php-5.2.0\zend\zend_execute.h(143) : warning
C4311: 'type cast' : pointer truncation from 'void *' to 'ulong'
c:\simon\projects\tuscany\php\php- 5.2.0\zend\zend_execute.h(157) :
warning C4311: 'type cast' : pointer truncation from 'void *' to 'ulong'
c:\simon\apps\vcexpress2005\vc\include\xutility(191) : warning C4273:
'std::_Container_base::_Orphan_all' : inconsistent dll linkage
c:\simon\apps\vcexpress2005\vc\include\xutility(109) : see
previous definition of '_Orphan_all'
c:\simon\apps\vcexpress2005\vc\include\xutility(203) : warning C4273:
'std::_Container_base::_Swap_all' : inconsistent dll linkage
c:\simon\apps\vcexpress2005\vc\include\xutility(110) : see
previous definition of '_Swap_all'
c:\simon\apps\vcexpress2005\vc\include\ostream(964) : error C2491:
'std::endl' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\ostream(973) : error C2491:
'std::endl' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\ostream(982) : error C2491:
'std::ends' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\ostream(990) : error C2491:
'std::ends' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\ostream(998) : error C2491:
'std::flush' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\ostream(1006) : error C2491:
'std::flush' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\istream(1061) : error C2491:
'std::ws' : definition of dllimport function not allowed
c:\simon\apps\vcexpress2005\vc\include\istream(1096) : error C2491:
'std::ws' : definition of dllimport function not allowed
c:\simon\projects\eclipse3.2\cpp\sca\deploy\include\tuscany\sca\core\operation.h(171)
: warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data
Generating Code...

Ignoring the warning for a moment anyone see C2491 in any of the other
projects. it kind of rings a bell but I can't dredge it out on my mind. I
have previously successfully compiled this extension with the same versions
of VC++ and PHP as I have now. Has something changed in the solution file
that I'm inheriting from in my project but that I'm not spotting?

Regards

Simon



Well I got past this but I'm at a loss as to why it happens. In ostream in
the standard library that are a number of inline functions defined, for
example,

_CRTIMP2_PURE inline basic_ostream >&
   __CLRCALL_OR_CDECL endl(basic_ostream >& _Ostr)
   {// insert newline and flush byte stream
   _Ostr.put('\n');
   _Ostr.flush();
   return (_Ostr);
   }

_CRTIMP2_PURE resolves to _CTRIMP2 which in turn resolves to

#ifndef _CRTIMP2
#if defined(_DLL) && !defined(_STATIC_CPPLIB)
#define _CRTIMP2 __declspec(dllimport)
#else   /* ndef _DLL && !STATIC_CPPLIB */
#define _CRTIMP2
#endif  /* _DLL && !STATIC_CPPLIB */
#endif  /* _CRTIMP2 */

So under some circumstances it would appear that these inline functions get
the calling convention __declspec(dllimport) which causes the compiler to
complain with a C2491. This is in the std library and has nothing to do with
me so I have no idea why this is causing me a problem now when it didn't
before Christmas. I can only think that something strange has happend with
the project or solution #defines. Although PHP must be adding to the problem
also as none of the other projects seem to suffer. Anyhow I got round the
problem for now by using

#include 

before

#include 

Hence preventing PHP form including iostream directly. The build is now
happy. Now on to testing it.

Regards

Simon

[C++] SCA failure on Axis server run

[Simon Laws]

I'm trying to run up the Axis2C server configured with C++/SCA from svn. The
server crashes on start up having reported the following debug...

C:\simon\apps\axis2c-bin-0.95-win32\bin>axis2_http_server.exe -l 4
7656:6784 >> tuscany::sca::util::ThreadLocal::~ThreadLocal
7656:6784 << tuscany::sca::util::ThreadLocal::~ThreadLocal
7656:6784 >> tuscany::sca::util::Mutex::~Mutex
7656:6784 << tuscany::sca::util::Mutex::~Mutex

I remember seeing a few threading type emails flying past. Is the current
code in svn OK. If so I'll get it in the debugger and dig further.

Thanks

Simon

Re: [C++] SCA failure on Axis server run

[Simon Laws]

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


Jean-Sebastien Delfino wrote:
> Simon Laws wrote:
>> I'm trying to run up the Axis2C server configured with C++/SCA from
>> svn. The
>> server crashes on start up having reported the following debug...
>>
>> C:\simon\apps\axis2c-bin-0.95-win32\bin>axis2_http_server.exe -l 4
>> 7656:6784 >> tuscany::sca::util::ThreadLocal::~ThreadLocal
>> 7656:6784 << tuscany::sca::util::ThreadLocal::~ThreadLocal
>> 7656:6784 >> tuscany::sca::util::Mutex::~Mutex
>> 7656:6784 << tuscany::sca::util::Mutex::~Mutex
>>
>> I remember seeing a few threading type emails flying past. Is the
>> current
>> code in svn OK. If so I'll get it in the debugger and dig further.
>>
>> Thanks
>>
>> Simon
>>
>
> Simon,
>
> I recently added some code to allow SCA runtime to be used in the
> multithreaded environment (important on Windows as on Windows Httpd
> runs multithreaded), but I have not be running into any startup
> crashes. The log  you've included here simply shows that the server is
> going down, and doing so invokes the destructors of two static objects
> (a ThreadLocal and a Mutex).
>
> Do you have any more context from your debugging session that could
> help us understand what's crashing the server?
>

Simon,

I tried Axis2c 0.94, 0.95 and 0.96 on Windows and they all work for me.
Is your environment set up like we usually set it up in our
runwsserver.bat files?

--
Jean-Sebastien


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

Jean-Sebastien


Thanks for that. At least I know it's my set up and not a more general
program. I'll investigate.

Regards

Simon

Re: [PHP] Building the PHP runtime and SCA extension, was Re: [C++] PHP SCA extension for C++ SCA

[Simon Laws]

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


Simon Laws wrote:
> Ok, so after a rather lengthy (and relaxing) Christmas break I'm
> starting to
> work again on building up the PHP capability in the C++ SCA
> implementation.
> There was some work done before Christmas documented on our PHP SCA site
> here [1]. There were some previous mail exchanges talking about the
> problem
> generally [2] and talking about the slight discontinuity between the way
> that composition is represented in PHP SCA annotations compared to the
> SCA
> SCDL files in C++ SCA [3].
>
> The first thing I'm going to do is get the existing C++ PHP Extension
> up and
> running again and submit any changes that are required now that C++
> SCA has
> moved on and I'm on to a new version of PHP. I'll add some more detail
to
> the README about what to do. This note was just to get the ball rolling
> again so I'm sure there will be lots more issues to discuss very
shortly.
>
> Regards
>
> Simon
>
> [1] -
> http://www.osoa.org/display/PHP/PHP+SCA+Extension+For+Tuscany+CPP+SCA
> [2] -
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11572.html
> [3] -
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11747.html
>

Simon,

How are you building the PHP runtime to work both with the PHP SCA_SDO
package at http://pecl.php.net/package/SCA_SDO and the Tuscany PHP
extension?

I built PHP 5.2.0 on my Linux box like this:
./configure --prefix=/home/delfinoj/Tuscany/php5/php-5.2.0-bin
--with-apxs2 --enable-embed
make
make install

--enable-embed allows linking with extension (and in particular the
Tuscany extension)
--with-apxs2 allows PHP5 to run as an Apache2 module (rather than CGI).

I then built and linked the Tuscany extension to libphp5.so, like this:
libtuscany_sca_php_la_LIBADD = -L${TUSCANY_SDOCPP}/lib -ltuscany_sdo \
-L$(top_builddir)/runtime/core/src -ltuscany_sca \
-L${PHP_LIB} -lphp5

INCLUDES = -Imodel -I$(top_builddir)/runtime/core/src \
   -I${TUSCANY_SDOCPP}/include \
   -I${PHP_INCLUDE} \
   -I${PHP_INCLUDE}/main \
   -I${PHP_INCLUDE}/Zend \
   -I${PHP_INCLUDE}/TSRM \
   -I${PHP_INCLUDE}/sapi/embed


The problem is that when I try to run Tuscany outside of Httpd (from the
command line) the PHP extension won't load, complaining about unresolved
references to Httpd symbols. Here's the log:

2555:3086005952 Library:

/home/delfinoj/Tuscany/apache-deploy/cpp/sca/extensions/php/lib/libtuscany_sca_php.so
2555:3086005952   SystemConfigurationException raised: Unable to load
library:

/home/delfinoj/Tuscany/apache-deploy/cpp/sca/extensions/php/lib/libtuscany_sca_php.so:
/home/delfinoj/Tuscany/php5/php-5.2.0-bin/lib/libphp5.so: undefined
symbol: ap_rwrite
2555:3086005952   SystemConfigurationException raised: Unable to load
library:

/home/delfinoj/Tuscany/apache-deploy/cpp/sca/extensions/php/lib/libtuscany_sca_php.so:
/home/delfinoj/Tuscany/php5/php-5.2.0-bin/lib/libphp5.so: undefined
symbol: ap_rwrite
2555:3086005952 << void tuscany::sca::util::Library::load()

The unresolved symbol, ap_rwrite is in Httpd protocol.c, part of the
core Httpd server. Did you run into this issue with PHP SCA_SDO? Are
people using two different PHP libraries, one for use inside Httpd the
other for use outside?

Thanks,

--
Jean-Sebastien


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




Hi Jean-Sebastien

The truth is I'm not yet so I may not be much helkp to you. I'm struggling
to get C++/SCA to run again due to the start up crash I'm investigating:-(
I did have this working on windows before Christmas though but I didn't
cross the bridge of running it in Apache. I ran it from the Axis standalone
server.

Having said this I have PHP compile to integrate with Apache on both of my
linux boxes. One uses --enable-fastcgi and the other --with-apxs2. In both
of these cases I can run the CLI version of PHP i.e. I can run without
Apache OK. Neither of these are compiled with embedding turned on though so
there may be some problem there.

I have only compiled for embedding on windows to date where I have my Apache
integration set to --enable-fastcgi (nothing like a bit of variety). In the
windows case though the embedding API is compiled into a separate library. I
don't believe that is relevant though.

So a couple of things to try.

Can you try running PHP from the command line to check that it works stand
alone.
 - you might need to do a make install-cli
By way of experiment can you
 - link with the Apache libraries that provide the missing function
 - build PHP with cgi Apache integration and see if that works
 - build PHP without Apache integration and see if that works.

Re: [C++] SCA failure on Axis server run

[Simon Laws]

On 1/9/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 1/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Jean-Sebastien Delfino wrote:
> > Simon Laws wrote:
> >> I'm trying to run up the Axis2C server configured with C++/SCA from
> >> svn. The
> >> server crashes on start up having reported the following debug...
> >>
> >> C:\simon\apps\axis2c-bin-0.95-win32\bin>axis2_http_server.exe -l 4
> >> 7656:6784 >> tuscany::sca::util::ThreadLocal::~ThreadLocal
> >> 7656:6784 << tuscany::sca::util::ThreadLocal::~ThreadLocal
> >> 7656:6784 >> tuscany::sca::util::Mutex::~Mutex
> >> 7656:6784 << tuscany::sca::util::Mutex::~Mutex
> >>
> >> I remember seeing a few threading type emails flying past. Is the
> >> current
> >> code in svn OK. If so I'll get it in the debugger and dig further.
> >>
> >> Thanks
> >>
> >> Simon
> >>
> >
> > Simon,
> >
> > I recently added some code to allow SCA runtime to be used in the
> > multithreaded environment (important on Windows as on Windows Httpd
> > runs multithreaded), but I have not be running into any startup
> > crashes. The log  you've included here simply shows that the server is
>
> > going down, and doing so invokes the destructors of two static objects
> > (a ThreadLocal and a Mutex).
> >
> > Do you have any more context from your debugging session that could
> > help us understand what's crashing the server?
> >
>
> Simon,
>
> I tried Axis2c 0.94, 0.95 and 0.96 on Windows and they all work for me.
> Is your environment set up like we usually set it up in our
> runwsserver.bat files?
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Jean-Sebastien

Thanks for that. At least I know it's my set up and not a more general
program. I'll investigate.

Regards

Simon


I eventually tracked this down to somwthing strange that had been added to
my path automatically at some point since I ran this before Christmas. I
have to admit that I haven't tracked it down precisely I reinstalled axis
which had no effect and then reset the PATH which did. So I'm making
progress again now.

Simon

[C++] Load library error messages

[Simon Laws]

I just spent a little time trying to get C++ SCA to load my PHP extension
dll. The error I was getting was.

820:5044   SystemConfigurationException raised: Unable to load library:
C:\simon\Projects\Eclipse3.2\cpp\sca\deploy\extensions\php\bin/tuscany_sca_php.dll

I had forgotten from the last time that I did this that SCA goes looking for
dlls to load based on the TUSCANY_SCACPP (I believe) and then tries to load
the dlls that it finds. So I spent a little time looking at this error
message wondering why it couldn;t load a dll that clearly it knew exactly
the right path for.

Of course I had missed the dll location from my path. Once I fixed this I
got the same message and eventually realized that the path needed to be
extended to include the dependencies of tuscany_sca_php.dll.

Now this is basic getting a program working stuff but I was thrown by the
message which suggests that SCA knows exactly where the dll is.

How about changing the message to either

SystemConfigurationException raised: Unable to load library:
tuscany_sca_php.dll

Or

SystemConfigurationException raised: Unable to load library:
C:\simon\Projects\Eclipse3.2\cpp\sca\deploy\extensions\php\bin/tuscany_sca_php.dll
check PATH or LD_LIBRARY_PATH.

Or

SystemConfigurationException raised: SCA has detected the library:
C:\simon\Projects\Eclipse3.2\cpp\sca\deploy\extensions\php\bin/tuscany_sca_php.dll
but is unable to load it because the SCA executable can't find it in PATH or
LD_LIBRARY_PATH

Simon

[C++] PHP Extension

[Simon Laws]

I've spent quite a lot of time just trying to get the extension back up and
running again. I've now back to where I was with the very basic functions
working. I've created new patches (
http://issues.apache.org/jira/browse/TUSCANY-974). The README's are very
thin so I will be adding more in the coming days.

Simon

Re: [PHP] Building the PHP runtime and SCA extension

[Simon Laws]

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


Simon Laws wrote:
> On 1/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Simon Laws wrote:
>> > Ok, so after a rather lengthy (and relaxing) Christmas break I'm
>> > starting to
>> > work again on building up the PHP capability in the C++ SCA
>> > implementation.
>> > There was some work done before Christmas documented on our PHP SCA
>> site
>> > here [1]. There were some previous mail exchanges talking about the
>> > problem
>> > generally [2] and talking about the slight discontinuity between
>> the way
>> > that composition is represented in PHP SCA annotations compared to
the
>> > SCA
>> > SCDL files in C++ SCA [3].
>> >
>> > The first thing I'm going to do is get the existing C++ PHP Extension
>> > up and
>> > running again and submit any changes that are required now that C++
>> > SCA has
>> > moved on and I'm on to a new version of PHP. I'll add some more
detail
>> to
>> > the README about what to do. This note was just to get the ball
>> rolling
>> > again so I'm sure there will be lots more issues to discuss very
>> shortly.
>> >
>> > Regards
>> >
>> > Simon
>> >
>> > [1] -
>> > http://www.osoa.org/display/PHP/PHP+SCA+Extension+For+Tuscany+CPP+SCA
>> > [2] -
>> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11572.html
>> > [3] -
>> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11747.html
>> >
>>
>> Simon,
>>
>> How are you building the PHP runtime to work both with the PHP SCA_SDO
>> package at http://pecl.php.net/package/SCA_SDO and the Tuscany PHP
>> extension?
>>
>> I built PHP 5.2.0 on my Linux box like this:
>> ./configure --prefix=/home/delfinoj/Tuscany/php5/php-5.2.0-bin
>> --with-apxs2 --enable-embed
>> make
>> make install
>>
>> --enable-embed allows linking with extension (and in particular the
>> Tuscany extension)
>> --with-apxs2 allows PHP5 to run as an Apache2 module (rather than CGI).
>>
>> I then built and linked the Tuscany extension to libphp5.so, like this:
>> libtuscany_sca_php_la_LIBADD = -L${TUSCANY_SDOCPP}/lib -ltuscany_sdo \
>> -L$(top_builddir)/runtime/core/src -ltuscany_sca \
>> -L${PHP_LIB} -lphp5
>>
>> INCLUDES = -Imodel -I$(top_builddir)/runtime/core/src \
>>-I${TUSCANY_SDOCPP}/include \
>>-I${PHP_INCLUDE} \
>>-I${PHP_INCLUDE}/main \
>>-I${PHP_INCLUDE}/Zend \
>>-I${PHP_INCLUDE}/TSRM \
>>-I${PHP_INCLUDE}/sapi/embed
>>
>>
>> The problem is that when I try to run Tuscany outside of Httpd (from
the
>> command line) the PHP extension won't load, complaining about
unresolved
>> references to Httpd symbols. Here's the log:
>>
>> 2555:3086005952 Library:
>>
>>
/home/delfinoj/Tuscany/apache-deploy/cpp/sca/extensions/php/lib/libtuscany_sca_php.so
>>
>> 2555:3086005952   SystemConfigurationException raised: Unable to load
>> library:
>>
>>
/home/delfinoj/Tuscany/apache-deploy/cpp/sca/extensions/php/lib/libtuscany_sca_php.so:
>>
>> /home/delfinoj/Tuscany/php5/php-5.2.0-bin/lib/libphp5.so: undefined
>> symbol: ap_rwrite
>> 2555:3086005952   SystemConfigurationException raised: Unable to load
>> library:
>>
>>
/home/delfinoj/Tuscany/apache-deploy/cpp/sca/extensions/php/lib/libtuscany_sca_php.so:
>>
>> /home/delfinoj/Tuscany/php5/php-5.2.0-bin/lib/libphp5.so: undefined
>> symbol: ap_rwrite
>> 2555:3086005952 << void tuscany::sca::util::Library::load()
>>
>> The unresolved symbol, ap_rwrite is in Httpd protocol.c, part of the
>> core Httpd server. Did you run into this issue with PHP SCA_SDO? Are
>> people using two different PHP libraries, one for use inside Httpd the
>> other for use outside?
>>
>> Thanks,
>>
>> --
>> Jean-Sebastien
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> Hi Jean-Sebastien
>
> The truth is I'm not yet so I may not be much helkp to you. I'm
> struggling
> to get C++/SCA to run again due to the start up crash I'm
> investigating:-(
> I did have this working on windows before Christmas though but I 

[C++] help setting up autoconf for PHP extension

[Simon Laws]

I realize I haven't posted on progress with the PHP extension for a while.
Having a few problems with it at the moment. I've been working on windows
and have most of the changes made to enable references. However a couple of
days ago I ran into a script dependent memory error in the embeded PHP
engine. It's a little tricky to trace this because we have the following
path to the running script

Axis2C -> CPP SCA -> PHP -> Script.

I.e. there is a lot of C/C++ to go wrong and most of it we didn't write.
Needless to say the script is fine outside of PHP. I've tried attacking the
problem in various ways but am a little stumped on windows, e.g. I can't get
purify to run the exe all the way to the point that it crashes.

I'm now moving the whole environment over to linux to see if I get the same
error and so that I can try some of the Linux based tools, e.g. valgrind. I
need a little help with the autoconf setup for CPP SCA. Specifically where
do I tell autoconf about the PHP engine include path that it needs to build
the PHP extension?

Thanks

Simon

Re: [C++] help setting up autoconf for PHP extension

[Simon Laws]

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


Simon Laws wrote:
> I realize I haven't posted on progress with the PHP extension for a
> while.
> Having a few problems with it at the moment. I've been working on
windows
> and have most of the changes made to enable references. However a
> couple of
> days ago I ran into a script dependent memory error in the embeded PHP
> engine. It's a little tricky to trace this because we have the following
> path to the running script
>
> Axis2C -> CPP SCA -> PHP -> Script.
>
> I.e. there is a lot of C/C++ to go wrong and most of it we didn't write.
> Needless to say the script is fine outside of PHP. I've tried
> attacking the
> problem in various ways but am a little stumped on windows, e.g. I
> can't get
> purify to run the exe all the way to the point that it crashes.
>
> I'm now moving the whole environment over to linux to see if I get the
> same
> error and so that I can try some of the Linux based tools, e.g.
> valgrind. I
> need a little help with the autoconf setup for CPP SCA. Specifically
> where
> do I tell autoconf about the PHP engine include path that it needs to
> build
> the PHP extension?
>
> Thanks
>
> Simon
>

Simon,

You need to configure two environment variables PHP_INCLUDE and PHP_LIB.
Here's what I have on my machine:
PHP_INCLUDE=$HOME/Tuscany/php5/php-5.2.0-bin/include/php
export PHP_INCLUDE
PHP_LIB=$HOME/Tuscany/php5/php-5.2.0-bin/lib
export PHP_LIB

Then run autogen.sh, then configure --prefix=$TUSCANY_SCACPP
--with-axis2c --enable-all-extensions as usual.

--
Jean-Sebastien


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



Thanks Jean-Sebastien, I'll give it a spin.

Simon

[C++] Axis2C - Repository Listener initialization failed

[Simon Laws]

I just got "[error] http_server_main.c(166) Server creation failed: Error
code: 34 :: Repository Listener initialization failed" when running Axis2C
for the first time on linux. Having spent some time tracking this down
(clearly no one else has found this message confusing in the past?) all it
means is that there is something wrong with the SOs provided in any modules
or services you have added. In my case I had copied the tuscany module and
service directories from their installed location in /usr/local/tuscany/
(possibly a bad habit I picked up from what I do on windows) but hadn't
noticed that the SOs in this case are symbolic links and that the links are
relative.

Regards

Simon

[C++] C++ Proxy assumes C++ Service implementation?

[Simon Laws]

The default C++ proxy currently seems to assume that its always trying to
talk to a C++ service. Line 104 of CPPServiceProxy looks like

   // If we got here we have a CPP implementation
   CPPImplementation* impl = (CPPImplementation
*)componentType;

Did I understand this correctly? If so why is this the case?

Regards

Simon

Re: [RESULT] Re: [VOTE] Simon Laws for Tuscany committer

[Simon Laws]

On 1/22/07, ant elder <[EMAIL PROTECTED]> wrote:


Passed with 15 +1s, welcome Simon.

   ...ant

On 1/17/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> I'd like to nominate Simon Laws to become a Tuscany committer. Simon has
> has done lots of different things for Tuscany - patches, interop work,
the
> website, release testing, participating in discussions etc, and he's
been
> contributing to Tuscany since April last year!
>
> Here's my +1.
>
>...ant
>
>

Thanks everyone for voting for me. I seem to remember various people

asking the "what do I do now?" question in the past so I'll go take a look
at the archive:-)

Simon

Re: [C++] C++ Proxy assumes C++ Service implementation?

[Simon Laws]

On 1/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


Simon,

this code is in the extension that handles C++ components so we expect the
implementation to be C++. This is not the "default" proxy. This code will
be
invoked because the definition of the component is an implementation.cpp.
There is similar code in e.g. the ruby RubyServiceProxy that will handle
implementation.rb.

Hope this helps.

Cheers,


On 21/01/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> The default C++ proxy currently seems to assume that its always trying
to
> talk to a C++ service. Line 104 of CPPServiceProxy looks like
>
>// If we got here we have a CPP implementation
>CPPImplementation* impl = (CPPImplementation
> *)componentType;
>
> Did I understand this correctly? If so why is this the case?
>
> Regards
>
> Simon
>
>


--
Pete

Thanks for the reply Pete. I'm still not sure I understand this. What is

the role of the CPPServiceProxy intended to be. I would guess, just going on
the name, that it is intended to be the CPP proxy for services as opposed to
a proxy for CPP services. But I guess I'm missing something.

The reason I'm asking the question is that I wanted to set up a local CPP
client for my PHP component. I couldn't get SCA to do this directly, i.e.

CPP Client --> PHP Component

I had to put a CPP component in the way to make it work

CPP Client --> CPP Component --> PHP Component

Which struck me as a little strange. I expect my error lies in the way that
I get hold of the context, locate the service or something else. Clearly
there is a proxy somewhere that is able to talk to my PHP component from
CPP. How do I get an instance of this one in the CPP client?

Regards

Simon

Re: [C++] C++ Proxy assumes C++ Service implementation?

[Simon Laws]

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


Pete Robbins wrote:
> On 22/01/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>>
>> On 1/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
>> >
>> > Simon,
>> >
>> > this code is in the extension that handles C++ components so we
expect
>> the
>> > implementation to be C++. This is not the "default" proxy. This code
>> will
>> > be
>> > invoked because the definition of the component is an
>> implementation.cpp
>> .
>> > There is similar code in e.g. the ruby RubyServiceProxy that will
>> handle
>> > implementation.rb.
>> >
>> > Hope this helps.
>> >
>> > Cheers,
>> >
>> >
>> > On 21/01/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> > >
>> > > The default C++ proxy currently seems to assume that its always
>> trying
>> > to
>> > > talk to a C++ service. Line 104 of CPPServiceProxy looks like
>> > >
>> > >// If we got here we have a CPP implementation
>> > >CPPImplementation* impl = (CPPImplementation
>> > > *)componentType;
>> > >
>> > > Did I understand this correctly? If so why is this the case?
>> > >
>> > > Regards
>> > >
>> > > Simon
>> > >
>> > >
>> >
>> >
>> > --
>> > Pete
>> >
>> > Thanks for the reply Pete. I'm still not sure I understand this.
>> What is
>> the role of the CPPServiceProxy intended to be. I would guess, just
>> going
>> on
>> the name, that it is intended to be the CPP proxy for services as
>> opposed
>> to
>> a proxy for CPP services. But I guess I'm missing something.
>>
>> The reason I'm asking the question is that I wanted to set up a local
>> CPP
>> client for my PHP component. I couldn't get SCA to do this directly,
>> i.e.
>>
>> CPP Client --> PHP Component
>>
>> I had to put a CPP component in the way to make it work
>>
>> CPP Client --> CPP Component --> PHP Component
>>
>> Which struck me as a little strange. I expect my error lies in the way
>> that
>> I get hold of the context, locate the service or something else.
Clearly
>> there is a proxy somewhere that is able to talk to my PHP component
from
>> CPP. How do I get an instance of this one in the CPP client?
>>
>> Regards
>>
>> Simon
>>
>>
> Ah. I see. The client interface using CompositeContext is not great. It
> feels to me like a hack to allow non-SCA code to be logically part of a
> composite. It is only for accessing a C++ component from a client. For a
> component implementation the proxies are generated for each reference
and
> wrappers are generated for each service (using scagen) and are
> compiled in
> to the component implementation. For a c++ client this is not possible
> so a
> proxy is generated for each service and this becomes part of the
> component
> implementation. This is why the client has to get a C++ proxy from the
> component implementation... which means it has to be a C++
implementation
> first!
>
> Maybe we can re-think this and find a way to return a service proxy for
a
> non-C++ component via CompositeContext (the proxy itself will still
> have to
> be a generate C++ proxy and we do not want to have to link this with the
> client code so where will it live?)
>
> Something to think about but for now you will have to have you CPP
> Component
> as the entry point from the CPP client.
>
> Cheers,
>

Connecting the C++ ServiceProxy to a ServiceWrapper wrappering a non-C++
component implementation is easy, but the real issue is that the SCA C++
C&I spec does not define an attribute to specify which DLL contains the
(generated) C++ proxy outside of of a , which you
don't have when your component is not written in C++.

I suggest to raise an SCA spec issue for this, and in the meantime,
package  these proxies in a library with a name derived from the name of
the composite or the name of the target component,  or as Pete suggested
continue to use an intermediate C++ component as an entry point from the
C++ client.

--
Jean-Sebastien


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

Pete, Jean-Sebastien, thanks, I think I understand the issue now. I'm

happy with the intermediate for what I'm doing at the moment. If a proxy is
ab

Re: [VOTE] Tuscany C++ sub-project name

[Simon Laws]

On 1/23/07, Simon Nash <[EMAIL PROTECTED]> wrote:


Andy,
+1 for "Tuscany Native".

   Simon

Andrew Borley wrote:

> My +1 is for "Tuscany Native"
>
> Cheers
> Andrew
>
> On 1/23/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
>> Hi all,
>>
>> From the "[C++] M3 release?" thread [1]:
>> Should we change the name of Tuscany C++? The "other half" of Tuscany
>> don't append "Java" to their releases and now we have decent support
>> for C++, Python, Ruby and (soon) PHP, calling it Tuscany C++ perhaps
>> misleads users into thinking it's only for people who know/use C++.
>>
>> Please vote for one of of the following suggestions we received in
>> that thread:
>>
>> [] Tuscany Native
>> [] Tuscany [language extension: PHP, Python, Ruby]
>> [] keep the old name (Tuscany C++)
>> [] something else (please suggest)
>>
>> Cheers
>>
>> Andrew
>>
>> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13137.html
>>
>
> -
> 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]


I like "Tuscany Native" too. +1

Simon

[C++] latest from svn gets axis error on build

[Simon Laws]

Hi

Am building C++ SCA/SDO from head on Fedora Core 6 using build.sh. and get
the following

g++ -DHAVE_CONFIG_H -I. -I. -I../../../../../..
-I../../../../../../runtime/core/src
-I/home/slaws/workspace/cpp/sdo/deploy/include -I/home/slaws/apps/axis2c-
bin-0.94-linux/include -D_DEBUG -g -O2 -MT Axis2Client.lo -MD -MP -MF
.deps/Axis2Client.Tpo -c tuscany/sca/ws/Axis2Client.cpp  -fPIC -DPIC -o
.libs/Axis2Client.otuscany/sca/ws/Axis2Client.cpp: In member function
'virtual void
tuscany::sca::ws::Axis2Client::invoke(tuscany::sca::Operation&)':
tuscany/sca/ws/Axis2Client.cpp:238: error:
'AXIS2_OPTIONS_SET_XML_PARSER_RESET' was not declared in this scope
tuscany/sca/ws/Axis2Client.cpp:245: error: 'AXIS2_OPTIONS_SET_SOAP_ACTION'
was not declared in this scope

I'm still at Axis 0.94. Is this something to do with Andy's axis upgrade?

Simon

Re: [C++] latest from svn gets axis error on build

[Simon Laws]

On 1/24/07, Simon Laws <[EMAIL PROTECTED]> wrote:


Hi

Am building C++ SCA/SDO from head on Fedora Core 6 using build.sh. and get
the following

 g++ -DHAVE_CONFIG_H -I. -I. -I../../../../../..
-I../../../../../../runtime/core/src
-I/home/slaws/workspace/cpp/sdo/deploy/include -I/home/slaws/apps/axis2c-
bin-0.94-linux/include -D_DEBUG -g -O2 -MT Axis2Client.lo -MD -MP -MF
.deps/Axis2Client.Tpo -c tuscany/sca/ws/Axis2Client.cpp  -fPIC -DPIC -o
.libs/Axis2Client.otuscany/sca/ws/Axis2Client.cpp: In member function
'virtual void
tuscany::sca::ws::Axis2Client::invoke(tuscany::sca::Operation&)':
tuscany/sca/ws/Axis2Client.cpp:238: error:
'AXIS2_OPTIONS_SET_XML_PARSER_RESET' was not declared in this scope
tuscany/sca/ws/Axis2Client.cpp:245: error: 'AXIS2_OPTIONS_SET_SOAP_ACTION'
was not declared in this scope

I'm still at Axis 0.94. Is this something to do with Andy's axis upgrade?

Simon


Think I've answered my own question. Greping for the offending string in
0.94 returns nothing while in 0.96 it returns something so I'll try moving
to 0.96 and see what happens.

Simon

[C++] SDO Memory management

[Simon Laws]

Hi

I note that there are serveral cases in SDO (as used during the model
loading stage of the SCA CPPCalculator samples) where valgrind reports
memory being deleted more that once. I have the example here and in my case
the problem is in
~SAX2Parser
~DataObjectImpl
~SDORuntimeException
Logger::LogArgs1()
Logger::LogArgs2()

I really thought these were are the root of my PHP extension problems but
alas no. As I'm knee deep in trying to sort this at the moment so I'm not
going to chase these any further at the moment but thought it best to warn
people. I'll raise a suitable JIRA with just this info. If anyone wants to
have a go pick an application that uses SDO and run it under valgrind. I
should point out that, for me, Purify didn't report these errors on windows.
I wouldn't read too much into that as I have so many other problems at the
moment it's not clear actually what is going on.

Regards

Simon

Re: [C++] SDO Memory management

[Simon Laws]

On 1/26/07, Geoffrey Winn <[EMAIL PROTECTED]> wrote:


I'm interested in that. I'm re-writing most of DataObjectImpl currently,
including the destructor so I may fix that one by accident. I've never
encountered valgrind before so if you can help me get started with it I'll
try to use it with SDO more regularly.

Geoff.

On 25/01/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> Hi
>
> I note that there are serveral cases in SDO (as used during the model
> loading stage of the SCA CPPCalculator samples) where valgrind reports
> memory being deleted more that once. I have the example here and in my
> case
> the problem is in
> ~SAX2Parser
> ~DataObjectImpl
> ~SDORuntimeException
> Logger::LogArgs1()
> Logger::LogArgs2()
>
> I really thought these were are the root of my PHP extension problems
but
> alas no. As I'm knee deep in trying to sort this at the moment so I'm
not
> going to chase these any further at the moment but thought it best to
warn
> people. I'll raise a suitable JIRA with just this info. If anyone wants
to
> have a go pick an application that uses SDO and run it under valgrind. I
> should point out that, for me, Purify didn't report these errors on
> windows.
> I wouldn't read too much into that as I have so many other problems at
the
> moment it's not clear actually what is going on.
>
> Regards
>
> Simon
>
>


Geoff

Using valgrind in its default configuration is easy assuming you have a
distro where it is already installed (it is on my Fedora core 5 box) you
just use

valgrind myexe

And that's it. It will run 'myexe' with a range of memory checking in force
and write info to stdout. I'm sure there are many ways you can configure it
for more complex operation but I haven't got into that yet.

If you don't have it you will have to find the rpm etc.

Regards

Simon

[C++] scagen question

[Simon Laws]

Any idea what is wrong with my installation when I get

java -jar /usr/local/tuscany/cpp/sca/deploy/bin/scagen.jar -dir . -output .
java.lang.NullPointerException
   at java.io.File.(File.java:303)
   at
org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.processComponentNode(Unknown
Source)
   at
org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.handleNode(Unknown
Source)
   at
org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle(Unknown
Source)
   at
org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleChildElements(Unknown
Source)
   at
org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleNode(Unknown
Source)
   at
org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle(Unknown
Source)
   at org.apache.tuscany.sca.cpp.tools.services.DomHandler.handleDom(Unknown
Source)at
org.apache.tuscany.sca.cpp.tools.services.XMLFileActor.actOnFile(Unknown
Source)
   at
org.apache.tuscany.sca.cpp.tools.services.CompositeOrFragmentFileHandler.actOnFile(Unknown
Source)
   at
org.apache.tuscany.sca.cpp.tools.services.DirectoryScanner.walkTree(Unknown
Source)
   at org.apache.tuscany.sca.cpp.tools.services.Scagen.main(Unknown
Source)

Simon

Re: [VOTE] Tuscany C++ sub-project name

[Simon Laws]

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


[snip]
Simon Nash wrote:
> A repackaging into a kernel and language extensions as suggested by
> Pete, Ignacio, and Jeremy seems like a good direction.  We'll still
> have to find a name for the (native, C++, scripting, ???) kernel,
> though.  And we'll have to decide what kind of distribution bundling
> is helpful for our users.  Jeremy's suggestion of combining related
> pieces from the "Java" and "C++" worlds seems like a good approach.
>
> I am not sure why we would put the cpp language extension into the
> kernel, as suggested by Pete.  Is this because it is needed by all
> other extensions that support scripting languages?
>
>   Simon
>

After having thought about various other code names, I'm starting to
like "native".

I am +1 with separating a kernel from the extensions. The CPP source
tree and build structure already have this separation anyway. The kernel
does not depend on the C++ component type support extension so I don't
think that it should include that extension.

I also like Jeremy's suggestion of combining the current java/ruby and
cpp/ruby into a Ruby top level module containing the code to support
both Jruby/Java and the Ruby native interpreter and a shared set of
samples. I think that the same idea will work well for other Scripting
component types (Python, Javascript etc.) and will help us ensure
consistency across runtimes.

I propose to go even further and generalize this idea to bindings (WS
binding, REST binding, an AMQP/Qpid binding may be a good candidate too)
and other component types as well.

I would like to stage some of these changes as they will generate
significant work to adjust all the build files etc. I'd suggest to start
changing the terminology (core to kernel, C++ to native) and see how we
can share some samples, but attack the refactoring of the source trees
and the build system later, after the C++/native M3 release.

Thoughts?

--
Jean-Sebastien


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

All of this refactoring sounds interesting and many systems distribute a

core/kernel and then optionally allow you to download extensions, PHP for
example. I should say that in the PHP case poplar extensions find their way
into the kernel/core over time once they have proved their worth because
people don't particularly like downloading extensions.

As Jean-Sebastien pointed out this separation already exists in the make
system so the user can choose precisely which bits to build once the source
distro has been downloaded. In the case of the binary distro I think the
case will be that the system only picks up those extensions that you
reference in SCDL so that fact that you have installed all of them is not an
issue given the number of extensions we have now. I would therefore suggest
that the extra complexity of delivering physically separate tars for
extensions and kernel is not required for M3 particularly because Jeremy's
ideas are interesting and may lead to rehashing the details of how this is
done for M4 anyhow.

Simon

[C++] Interface descriptions and type conversions

[Simon Laws]

I notice in implementing the PHP extension (yes - believe it or not I'm
nearly ready to make a patch for the next version ;-) that, given the way
that I have implemented the PHP extension there is insufficient information
available in the SCA runtime in order to do correct type conversions when
passing messages between components. I imagine this has been raised before
but I looked at the archive and couldn't find a relevant thread.

Imagine the scenario:

C++ Component (ComponentA)  ---WireA--->   PHP Component (ComponentB)
---WireB> C++ Component (ComponentC)

Currently the build process looks at the header files described in the
component type files and generates wrappers and proxies for the C++
components. I have currently implemented the PHP Extension to use generic
wrappers and proxies, i.e. it doesn't  use those generated based on the
interface descriptions,  so they need to dynamically manage the type
conversions for data coming in and going out of a PHP component.

WireA.

This is OK because the C++ SCA operation object that appears at Component B
has a set of data/types based on the generated proxy.  The PHP extension can
look at this and effect the right type conversions.

WireB

This is problematic. The dynamic PHP proxy has to generate an operation
object to pass to the the wrapper of ComponentC. The issue is that there is,
as far as I can tell, no dynamic way of getting at the list of types that
are expected for any particular operation. There is of course a static C++
proxy/wrapper combination that has been generated but I can't inspect it at
runtime.

I'm not keen on generating PHP specific interface classes. PHP is a dynamic
environment and it's a whole stack of extra files we could do without having
to manage particularly if we have to adapt the generator for every extension
that's constructed. Can we extend the wrapper/proxy mechanism to encapsulate
a runtime list of required types alongside the static method descriptions
that are already generated? We would need this to work for script to script
calls as well as for the script/C++ combination so maybe we need something
that hangs off the interface description part of the model. I'm not that
familiar with how that part of the model is used so a little investigation
is required.

Thoughts?

Simon

Re: [C++] scagen question

[Simon Laws]

On 1/31/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


We used to get an NPE when running scagen against one sample. It did not
affect the output though! It may have been down to invalid scdl??

Cheers,


On 31/01/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> I don't I'm afraid, SCAGEN works fine on the CppCalculator sample on
> both my Windows and Linux boxes (IBM JRE 1.5.0 and IBM JRE 1.4.2
> respectively). I remember having some troubles when I tried IBM JRE
> 1.5.0 on Linux a while back - but I can't really remember the details,
> and I don't think it was SCAGEN specific.
>
> Cheers
> Andy.
>
>
> On 1/30/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > Any idea what is wrong with my installation when I get
> >
> > java -jar /usr/local/tuscany/cpp/sca/deploy/bin/scagen.jar -dir .
> -output .
> > java.lang.NullPointerException
> > at java.io.File.(File.java:303)
> > at
> >
>
org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.processComponentNode
> (Unknown
> > Source)
> > at
> >
>
org.apache.tuscany.sca.cpp.tools.services.ComponentDomNodeHandler.handleNode
> (Unknown
> > Source)
> > at
> >
>
org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle
> (Unknown
> > Source)
> > at
> >
>
org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleChildElements
> (Unknown
> > Source)
> > at
> >
>
org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.handleNode
> (Unknown
> > Source)
> > at
> >
>
org.apache.tuscany.sca.cpp.tools.services.GenericDomNodeHandler.mapNodeToHandlerAndHandle
> (Unknown
> > Source)
> > at
> org.apache.tuscany.sca.cpp.tools.services.DomHandler.handleDom(Unknown
> > Source)at
> > org.apache.tuscany.sca.cpp.tools.services.XMLFileActor.actOnFile
(Unknown
> > Source)
> > at
> >
>
org.apache.tuscany.sca.cpp.tools.services.CompositeOrFragmentFileHandler.actOnFile
> (Unknown
> > Source)
> > at
> > org.apache.tuscany.sca.cpp.tools.services.DirectoryScanner.walkTree
> (Unknown
> > Source)
> > at org.apache.tuscany.sca.cpp.tools.services.Scagen.main
(Unknown
> > Source)
> >
> > Simon
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Pete

Ok, thanks for looking guys. I'll investigate further.


Simon

Re: [C++] Interface descriptions and type conversions

[Simon Laws]

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


Simon Laws wrote:
> I notice in implementing the PHP extension (yes - believe it or not I'm
> nearly ready to make a patch for the next version ;-) that, given the
way
> that I have implemented the PHP extension there is insufficient
> information
> available in the SCA runtime in order to do correct type conversions
when
> passing messages between components. I imagine this has been raised
> before
> but I looked at the archive and couldn't find a relevant thread.
>
> Imagine the scenario:
>
> C++ Component (ComponentA)  ---WireA--->   PHP Component (ComponentB)
> ---WireB> C++ Component (ComponentC)
>
> Currently the build process looks at the header files described in the
> component type files and generates wrappers and proxies for the C++
> components. I have currently implemented the PHP Extension to use
generic
> wrappers and proxies, i.e. it doesn't  use those generated based on the
> interface descriptions,  so they need to dynamically manage the type
> conversions for data coming in and going out of a PHP component.
>
> WireA.
>
> This is OK because the C++ SCA operation object that appears at
> Component B
> has a set of data/types based on the generated proxy.  The PHP
> extension can
> look at this and effect the right type conversions.
>
> WireB
>
> This is problematic. The dynamic PHP proxy has to generate an operation
> object to pass to the the wrapper of ComponentC. The issue is that
> there is,
> as far as I can tell, no dynamic way of getting at the list of types
that
> are expected for any particular operation. There is of course a static
> C++
> proxy/wrapper combination that has been generated but I can't inspect
> it at
> runtime.
>
> I'm not keen on generating PHP specific interface classes. PHP is a
> dynamic
> environment and it's a whole stack of extra files we could do without
> having
> to manage particularly if we have to adapt the generator for every
> extension
> that's constructed. Can we extend the wrapper/proxy mechanism to
> encapsulate
> a runtime list of required types alongside the static method
descriptions
> that are already generated? We would need this to work for script to
> script
> calls as well as for the script/C++ combination so maybe we need
> something
> that hangs off the interface description part of the model. I'm not that
> familiar with how that part of the model is used so a little
> investigation
> is required.
>
> Thoughts?
>
> Simon
>

Simon,

It's an interesting issue. To explore it let's walk through the wiring
scenario you describe and assume the following:
- ComponentA (C++) -> WireA -> ComponentB (PHP) -> WireB -> ComponentC
(C++)
- ComponentA (C++) passes a short int to ComponentB (PHP)
- ComponentB executes a PHP script which in turn passes a number to
ComponentC (C++)
- ComponentC expects that number to be given as a long int.

Here's what I think should happen in the runtime:
1. At the source of WireA, a generated C++ CPPServiceProxy adds to our
Operation object a Parameter of a type decided by the C++ client code: a
C++ short int, with type == ParameterType::SHORT.
2. At the end of WireA, a PHPServiceWrapper converts that parameter to
what the PHP script expects, for the sake of simplicity now I am going
to assume that it needs to convert it to a C++ std::string.
3. The PHP script executes, now passes an std::string containing a
number to the PHPServiceProxy at the source of WireB.
4. The PHPServiceProxy does not have much type info about that
std::string parameter and can only add it to the Operation object as a
std::string with type == ParameterType::STRING.
5. The CPPServiceWrapper at the end of WireB (actually the C++
ServiceWrapper generated for ComponentC) receives the std::string and
should convert it to what ComponentC expects: a long int.

The general idea is that a ServiceProxy sends what it is given (or picks
the most natural type out of the ParameterTypes that we have defined and
converts the data to it). A ServiceWrapper converts what it receives to
the type expected by the code it wraps. I think that the
CPPServiceWrapper code and the generated C++ ServiceWrappers are simply
missing the logic to convert data to what the target expects.

At the moment this limitation also prevents a C++ method
getCustomer(long customerID) to be exposed as a REST service for
example, as the generated C++ ServiceWrapper is missing the logic to
convert the customerID received in string form from the REST query
string to the expected C++ long int.

So we just need to add the missing type conversion logic to the C++
ServiceWrappers :)

Thoughts?

--
Jean-Sebastien


---

[C++] SCA PHP Extension patches

[Simon Laws]

I've attached patches to add reference support to the PHP Extension (
https://issues.apache.org/jira/browse/TUSCANY-1089). This is a fairly major
change and there have been several build problems in getting this to work.
As it's been a bit of a struggle I'm keen to get someone else to help me try
in on other boxes because I'm still having problems on my configuration and
its not clear if it's me or if there are rela problems. Sharing via svn is
the best way to do this but I should mention that this won't work without
some changes to the SCA_SDO PECL extension which I'm in the process of
making at the moment. They aren't there just yet.


Simon

Re: [C++] SCA PHP Extension patches

[Simon Laws]

On 2/2/07, Andrew Borley <[EMAIL PROTECTED]> wrote:


Hi Simon,
I'm taking a look at them now. I'll let you know how I get on.

Cheers
Andy

On 2/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> I've attached patches to add reference support to the PHP Extension (
> https://issues.apache.org/jira/browse/TUSCANY-1089). This is a fairly
major
> change and there have been several build problems in getting this to
work.
> As it's been a bit of a struggle I'm keen to get someone else to help me
try
> in on other boxes because I'm still having problems on my configuration
and
> its not clear if it's me or if there are rela problems. Sharing via svn
is
> the best way to do this but I should mention that this won't work
without
> some changes to the SCA_SDO PECL extension which I'm in the process of
> making at the moment. They aren't there just yet.
>
>
> Simon
>
>

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

Andy, just thinking that by defauly we may want to disable the automake

link to the PHP Extension and PHP Calculator sub projects because of course
they won't generally build unless you have your environment set up just so.
In the patches I left them enabled :-(

Simon

Re: [C++] SCA PHP Extension patches

[Simon Laws]

On 2/2/07, Andrew Borley <[EMAIL PROTECTED]> wrote:


On 2/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> On 2/2/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> >
> > Hi Simon,
> > I'm taking a look at them now. I'll let you know how I get on.
> >
> > Cheers
> > Andy
> >
> > On 2/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > I've attached patches to add reference support to the PHP Extension
(
> > > https://issues.apache.org/jira/browse/TUSCANY-1089). This is a
fairly
> > major
> > > change and there have been several build problems in getting this to
> > work.
> > > As it's been a bit of a struggle I'm keen to get someone else to
help me
> > try
> > > in on other boxes because I'm still having problems on my
configuration
> > and
> > > its not clear if it's me or if there are rela problems. Sharing via
svn
> > is
> > > the best way to do this but I should mention that this won't work
> > without
> > > some changes to the SCA_SDO PECL extension which I'm in the process
of
> > > making at the moment. They aren't there just yet.
> > >
> > >
> > > Simon
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > Andy, just thinking that by defauly we may want to disable the
automake
> link to the PHP Extension and PHP Calculator sub projects because of
course
> they won't generally build unless you have your environment set up just
so.
> In the patches I left them enabled :-(
>
> Simon
>
>
Hi Simon,
The PHP extension & sample are by default disabled at the moment - you
need to run "configure --enable-php" to build them on Linux. I've
committed the patches (& aslo updated the windows vcproj file), but
currently I'm failing to build on windows due to not having the PECL
SCA_SDO stuff that you mentioned and also getting some weird DLL
import and Winsock error messages... any ideas?

Cheers
Andy

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

yes - if you look at the top of the PHPServiceWrapper you will see a

#define you have to uncomment to make it work on windows. This needs to be
in a #ifdef win32 or similar but I've been working on UNIX for the last 3
weeks so didn't go back to fixing it.  Sorry

Simon

Re: [C++] Interface descriptions and type conversions

[Simon Laws]

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


Simon Laws wrote:
> On 2/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Simon Laws wrote:
>> > I notice in implementing the PHP extension (yes - believe it or not
>> I'm
>> > nearly ready to make a patch for the next version ;-) that, given the
>> way
>> > that I have implemented the PHP extension there is insufficient
>> > information
>> > available in the SCA runtime in order to do correct type conversions
>> when
>> > passing messages between components. I imagine this has been raised
>> > before
>> > but I looked at the archive and couldn't find a relevant thread.
>> >
>> > Imagine the scenario:
>> >
>> > C++ Component (ComponentA)  ---WireA--->   PHP Component (ComponentB)
>> > ---WireB> C++ Component (ComponentC)
>> >
>> > Currently the build process looks at the header files described in
the
>> > component type files and generates wrappers and proxies for the C++
>> > components. I have currently implemented the PHP Extension to use
>> generic
>> > wrappers and proxies, i.e. it doesn't  use those generated based on
>> the
>> > interface descriptions,  so they need to dynamically manage the type
>> > conversions for data coming in and going out of a PHP component.
>> >
>> > WireA.
>> >
>> > This is OK because the C++ SCA operation object that appears at
>> > Component B
>> > has a set of data/types based on the generated proxy.  The PHP
>> > extension can
>> > look at this and effect the right type conversions.
>> >
>> > WireB
>> >
>> > This is problematic. The dynamic PHP proxy has to generate an
>> operation
>> > object to pass to the the wrapper of ComponentC. The issue is that
>> > there is,
>> > as far as I can tell, no dynamic way of getting at the list of types
>> that
>> > are expected for any particular operation. There is of course a
static
>> > C++
>> > proxy/wrapper combination that has been generated but I can't inspect
>> > it at
>> > runtime.
>> >
>> > I'm not keen on generating PHP specific interface classes. PHP is a
>> > dynamic
>> > environment and it's a whole stack of extra files we could do without
>> > having
>> > to manage particularly if we have to adapt the generator for every
>> > extension
>> > that's constructed. Can we extend the wrapper/proxy mechanism to
>> > encapsulate
>> > a runtime list of required types alongside the static method
>> descriptions
>> > that are already generated? We would need this to work for script to
>> > script
>> > calls as well as for the script/C++ combination so maybe we need
>> > something
>> > that hangs off the interface description part of the model. I'm not
>> that
>> > familiar with how that part of the model is used so a little
>> > investigation
>> > is required.
>> >
>> > Thoughts?
>> >
>> > Simon
>> >
>>
>> Simon,
>>
>> It's an interesting issue. To explore it let's walk through the wiring
>> scenario you describe and assume the following:
>> - ComponentA (C++) -> WireA -> ComponentB (PHP) -> WireB -> ComponentC
>> (C++)
>> - ComponentA (C++) passes a short int to ComponentB (PHP)
>> - ComponentB executes a PHP script which in turn passes a number to
>> ComponentC (C++)
>> - ComponentC expects that number to be given as a long int.
>>
>> Here's what I think should happen in the runtime:
>> 1. At the source of WireA, a generated C++ CPPServiceProxy adds to our
>> Operation object a Parameter of a type decided by the C++ client code:
a
>> C++ short int, with type == ParameterType::SHORT.
>> 2. At the end of WireA, a PHPServiceWrapper converts that parameter to
>> what the PHP script expects, for the sake of simplicity now I am going
>> to assume that it needs to convert it to a C++ std::string.
>> 3. The PHP script executes, now passes an std::string containing a
>> number to the PHPServiceProxy at the source of WireB.
>> 4. The PHPServiceProxy does not have much type info about that
>> std::string parameter and can only add it to the Operation object as a
>> std::string with type == ParameterType::STRING.
>> 5. The CPPServiceWrapper at the end of WireB (actually the C++
>> ServiceWrappe

Re: [C++] Interface descriptions and type conversions

[Simon Laws]

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


Simon Laws wrote:
> On 2/2/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Simon Laws wrote:
>> > On 2/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Simon Laws wrote:
>> >> > I notice in implementing the PHP extension (yes - believe it or
not
>> >> I'm
>> >> > nearly ready to make a patch for the next version ;-) that,
>> given the
>> >> way
>> >> > that I have implemented the PHP extension there is insufficient
>> >> > information
>> >> > available in the SCA runtime in order to do correct type
>> conversions
>> >> when
>> >> > passing messages between components. I imagine this has been
raised
>> >> > before
>> >> > but I looked at the archive and couldn't find a relevant thread.
>> >> >
>> >> > Imagine the scenario:
>> >> >
>> >> > C++ Component (ComponentA)  ---WireA--->   PHP Component
>> (ComponentB)
>> >> > ---WireB> C++ Component (ComponentC)
>> >> >
>> >> > Currently the build process looks at the header files described in
>> the
>> >> > component type files and generates wrappers and proxies for the
C++
>> >> > components. I have currently implemented the PHP Extension to use
>> >> generic
>> >> > wrappers and proxies, i.e. it doesn't  use those generated based
on
>> >> the
>> >> > interface descriptions,  so they need to dynamically manage the
>> type
>> >> > conversions for data coming in and going out of a PHP component.
>> >> >
>> >> > WireA.
>> >> >
>> >> > This is OK because the C++ SCA operation object that appears at
>> >> > Component B
>> >> > has a set of data/types based on the generated proxy.  The PHP
>> >> > extension can
>> >> > look at this and effect the right type conversions.
>> >> >
>> >> > WireB
>> >> >
>> >> > This is problematic. The dynamic PHP proxy has to generate an
>> >> operation
>> >> > object to pass to the the wrapper of ComponentC. The issue is that
>> >> > there is,
>> >> > as far as I can tell, no dynamic way of getting at the list of
>> types
>> >> that
>> >> > are expected for any particular operation. There is of course a
>> static
>> >> > C++
>> >> > proxy/wrapper combination that has been generated but I can't
>> inspect
>> >> > it at
>> >> > runtime.
>> >> >
>> >> > I'm not keen on generating PHP specific interface classes. PHP is
a
>> >> > dynamic
>> >> > environment and it's a whole stack of extra files we could do
>> without
>> >> > having
>> >> > to manage particularly if we have to adapt the generator for every
>> >> > extension
>> >> > that's constructed. Can we extend the wrapper/proxy mechanism to
>> >> > encapsulate
>> >> > a runtime list of required types alongside the static method
>> >> descriptions
>> >> > that are already generated? We would need this to work for
>> script to
>> >> > script
>> >> > calls as well as for the script/C++ combination so maybe we need
>> >> > something
>> >> > that hangs off the interface description part of the model. I'm
not
>> >> that
>> >> > familiar with how that part of the model is used so a little
>> >> > investigation
>> >> > is required.
>> >> >
>> >> > Thoughts?
>> >> >
>> >> > Simon
>> >> >
>> >>
>> >> Simon,
>> >>
>> >> It's an interesting issue. To explore it let's walk through the
>> wiring
>> >> scenario you describe and assume the following:
>> >> - ComponentA (C++) -> WireA -> ComponentB (PHP) -> WireB ->
>> ComponentC
>> >> (C++)
>> >> - ComponentA (C++) passes a short int to ComponentB (PHP)
>> >> - ComponentB executes a PHP script which in turn passes a number to
>> >> ComponentC (C++)
>> >> - ComponentC expects that number to 

Re: Hello Community!

[Simon Laws]

On 2/6/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


Welcome Douglas !!!

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

On 2/6/07, Douglas Leite <[EMAIL PROTECTED]> wrote:
>
> Hello Community!
>
> I am a Computer Science student at UFMT (University of Mato Grosso) in
> Brazil.
>
> There is a small group of people here in UFMT that are working on
Tuscany
> project, and after read more about the project I have decided to join
in.
>
> Initially, I am interested in helping DAS C++ project.
>
> Although I am a beginner in big projects, like Tuscany, I hope I could
> help.
>
> Thanks,
>
> Douglas Siqueira Leite
>


Hi Douglas, welcome indeed. The only secret I've found to working on Tuscany
is don't be afraid to ask/answer questions on the mail list:-)

Regards

Simon

[C++] SVN settings?

[Simon Laws]

Is the set of SVN client configurations required to get the correct file
settings recorded anywhere for Tuscany C++?

Thanks

Simon

Re: [C++] SVN settings?

[Simon Laws]

On 2/7/07, Andrew Borley <[EMAIL PROTECTED]> wrote:


On 2/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> Is the set of SVN client configurations required to get the correct file
> settings recorded anywhere for Tuscany C++?
>
> Thanks
>
> Simon
>

Hi Simon,

yep - take a look at
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/etc/svn-config
This is the config Sebastien, Pete and I have been using.

Additionally there is
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/etc/svn-ignore
which lists the file names/types for your SVN client to ignore

I use TortoiseSVN on Windows and apply this config by overwriting the
C:\Documents and Settings\ajborley\Application Data\Subversion\config
file with the contents of svn-config above. This may work the same for
other SVN Clients (like the subclipse plugin for Eclipse), but may
not! On Linux, you need to overwrite ~/.subversion/config

Cheers
Andy

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

Thanks Andy,


It seems to be the same for Eclipse. I.e I have

C:\Documents and Settings\simon\Application Data\Subversion\config

So I've edited it to include the configuration you reference.

Thanks

Simon

Re: [C++] SCA PHP Extension patches

[Simon Laws]

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




On 2/2/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> On 2/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > On 2/2/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Simon,
> > > I'm taking a look at them now. I'll let you know how I get on.
> > >
> > > Cheers
> > > Andy
> > >
> > > On 2/2/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > > > I've attached patches to add reference support to the PHP
> Extension (
> > > > https://issues.apache.org/jira/browse/TUSCANY-1089 ). This is a
> fairly
> > > major
> > > > change and there have been several build problems in getting this
> to
> > > work.
> > > > As it's been a bit of a struggle I'm keen to get someone else to
> help me
> > > try
> > > > in on other boxes because I'm still having problems on my
> configuration
> > > and
> > > > its not clear if it's me or if there are rela problems. Sharing
> via svn
> > > is
> > > > the best way to do this but I should mention that this won't work
> > > without
> > > > some changes to the SCA_SDO PECL extension which I'm in the
> process of
> > > > making at the moment. They aren't there just yet.
> > > >
> > > >
> > > > Simon
> > > >
> > > >
> > >
> > >
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > > Andy, just thinking that by defauly we may want to disable the
> automake
> > link to the PHP Extension and PHP Calculator sub projects because of
> course
> > they won't generally build unless you have your environment set up
> just so.
> > In the patches I left them enabled :-(
> >
> > Simon
> >
> >
> Hi Simon,
> The PHP extension & sample are by default disabled at the moment - you
> need to run "configure --enable-php" to build them on Linux. I've
> committed the patches (& aslo updated the windows vcproj file), but
> currently I'm failing to build on windows due to not having the PECL
> SCA_SDO stuff that you mentioned and also getting some weird DLL
> import and Winsock error messages... any ideas?
>
> Cheers
> Andy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> yes - if you look at the top of the PHPServiceWrapper you will see a
#define you have to uncomment to make it work on windows. This needs to be
in a #ifdef win32 or similar but I've been working on UNIX for the last 3
weeks so didn't go back to fixing it.  Sorry

Simon


I've just checked in some changes to the VC project on windows which will
hopefully work for you now. I've also
updated the build for the PHP Calculator sample. Having said this I can't
get it to run on my windows box. As I've said before I'm a bit suspicious of
my windows configuration but I'm not getting the same error as before so
it's likely that ithis is a real problem with the PHP Extension code. Would
still be useful to know if you see a failure in the PHP engine code also.

Regards

Simon

Re: Suggestions for Tuscany SCA documenation?

[Simon Laws]

On 2/7/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I just added a draft @
http://cwiki.apache.org/confluence/display/TUSCANY/Getting+Started. We
might
be able to use it as a starting point and add more meat into it to help
new
users understand the basic concepts, steps and tools to develop a simple
SCA
application with Tuscany.

Thanks,
Raymond

- Original Message -
From: "haleh mahbod" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, February 07, 2007 11:33 AM
Subject: Re: Suggestions for Tuscany SCA documenation?


> Hi Shelita,
> Welcome to Tuscany. We definitly need help with documentation :)
>
> A starting point might be a user giude on  how to develop a simple SCA
> application. This document can then incrementally grow to  cover more
> advanced topics.
>
> Another project might be to work on an SCA user doc with examples. This
> would provide a quick reference to SCA rather than requiring people to
> read
> all the specifications.
>
> I would be happy to join you in this effort. We can start using
Confluence
> Wiki to work on the documents.
>
> Does the 'user guide' sound like a good starting point for you?
>
> What do others think?
>
> Haleh
>
>
> On 2/7/07, Rick Rineholt <[EMAIL PROTECTED]> wrote:
>>
>> Hello,
>> If your totally new to SCA/Tuscany having a fresh pair of eyes looking
>> at first understanding SCA, looking at our website how easy it is to
>> find resources, how well those were, then moving on to the samples in
M2
>> and then try and understand how contribute to Tuscany itself and along
>> the way provide feedback and updates can be always beneficial.  I think
>> that's ground anyone first starting out would initially have to cover
to
>> some degree or another.
>> If your not new, you'll need to give some background and where your
>> interests are in general.
>> .
>> Shelita Overton wrote:
>> > Hi I would like to help with creating some documenation for Tuscany
>> > SCA...
>> > Does anyone have any suggestions on what should be covered first?
>> > Priority?
>> > Any content that could be used as a starting point?
>> >
>> > ~Shelita Overton
>> >
>>
>>
>> -
>> 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]

Hi


Having looked a Java SCA in the M1 days I'd like to get back into it to
start investigating how it fits in with the other runtimes we have. So if
you're making beginners docs I'm happy to review it and try it out (or help
with it if you want me to). Looking at the link pasted in this thread (
http://cwiki.apache.org/confluence/display/TUSCANY/Getting+Started.) is
there going to be a distinction between setting up for developers vs users?
Also I note that there is a very early page on building SCA (
http://cwiki.apache.org/confluence/display/TUSCANY/Building+SCA+for+Java)
very little info in it now but we should not try to make competing pages.

Once the basic getting started guide is done, i.e. how do I install Tuscany
and run the samples, I agree with the suggestion of a user guide to take the
user through development of a first simple application.

Regards

Simon

Re: Move Tuscany wiki to Apache CWIKI?

[Simon Laws]

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


haleh mahbod wrote:
> +1 for moving to cwiki. Much easier to use.
>
> On 2/7/07, Rick Rineholt <[EMAIL PROTECTED]> wrote:
>>
>> I have found having too many sources 2 wikis, the web site, doco
checked
>> in to svn to be a major confusion and a general appearance
>> disorganization. I think we should at the very least now retire one of
>> the wiki sites.  I'm for moving to cwiki.
>> Venkata Krishnan wrote:
>> > Hi,
>> >
>> > I guess the website and the wiki are both needed and am very much in
>> line
>> > with Dan's thoughts on what should go into each of this.
>> >
>> > I guess its now a question of whether we want to move our content
>> out of
>> > that old wike over CWIKI.  I'd say we must go with CWIKI which is a
>> > lot more
>> > pleasant to look and feel.
>> >
>> > Thanks
>> >
>> > - Venkat
>> >
>> >
>> > On 2/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Dan Murphy wrote:
>> >> > Similar to Haleh's opinion... a hybrid of web and wiki seems to
>> make
>> >> > sense
>> >> > -  use the web site for fairly static content but link from the
>> >> website
>> >> > directly to appropriate places in the wiki where the content is
>> likely
>> >> to
>> >> > change or hasn't fully been decided yet.
>> >> >
>> >> > For example, we could remove the "how to build, test and deploy
>> Java
>> >> SCA"
>> >> > off of the web site and instead link from the web page to a wiki
>> page.
>> >> > (IMHO) it becomes easier to maintain...  perhaps if/when it
settles
>> >> > down (or
>> >> > @ V1) we could merge it back into the web site. I'd be happy to
>> help
>> >> > maintain this because I can edit the wiki - for me to contribute
to
>> >> > the web
>> >> > site takes much more effort... perhaps this isn't so important to
>> >> > others who
>> >> > are already committers...
>> >> >
>> >> > Dan
>> >> >
>> >> > On 07/02/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> Rick had asked earlier  "Two concerns come to mind if we make THE
>> >> >> website:
>> >> >> Is it backed up? can we get past revisions if needed ?  Currently
>> our
>> >> >> website is
>> >> >> in svn which covers that.
>> >> >> The other is we have had past complaints that the site was not
>> >> "fancy"
>> >> >> organized
>> >> >> etc, are we confident this wiki can handle this?"
>> >> >>
>> >> >> Is Confluence backed up regularly?
>> >> >>
>> >> >> Does it make sense to leave the website skeleton as is and move
>> all
>> >> >> documents to confluence WIKI? For example  FAQ, design docs,
>> release
>> >> >> information and downloads, etc.
>> >> >>
>> >> >> It took us a while to get the website look and feel to where it
is
>> >> right
>> >> >> now
>> >> >> and this is not the part that needs to be changed that often. We
>> >> should
>> >> >> not
>> >> >> move it until we have a good replacement.
>> >> >>
>> >> >>
>> >> >> On 2/6/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>> >> >> >
>> >> >> > Hi Kelvin,
>> >> >> >
>> >> >> > In my perception, we are moving over to the Confluence wiki -
>> >> >> > CWIKI.  Infact
>> >> >> > some of the recent updates such as things we aspire to do for
>> >> SCA M3,
>> >> >> some
>> >> >> > documentation on SCA Deployment and FAQs have already found
>> place
>> >> >> there.
>> >> >> >
>> >> >> > Thanks
>> >> >> >
>> >> >> > - Venkat
>> >> >> >
>> >> >> > On 2/6/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>> >> >> > >
>> >> >> > > As I'm updating a page on our old wiki,  I'm wondering where
>> >> we are
>> >> >> with
>> >> >> > > this and whether I should be migrating the content?
>> >> >> > >
>> >> >> > > Kelvin.
>> >> >> > >
>> >> >> > > On 24/01/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >> >> > > >
>> >> >> > > > Hi,
>> >> >> > > >
>> >> >> > > > FYI, I have added "edit" permissions to all registered
>> users.
>> >> >> > > >
>> >> >> > > > Thanks,
>> >> >> > > > Raymond
>> >> >> > > >
>> >> >> > > > - Original Message -
>> >> >> > > > From: "ant elder" <[EMAIL PROTECTED]>
>> >> >> > > > To: 
>> >> >> > > > Sent: Wednesday, January 24, 2007 4:59 AM
>> >> >> > > > Subject: Re: Move Tuscany wiki to Apache CWIKI?
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > > On 1/23/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >> >> > > > >
>> >> >> > > > > 
>> >> >> > > > >
>> >> >> > > > > 2) I'm not proposing to change the "edit" policy. The
>> >> >> > > > >> http://cwiki.apache.org/CWIKI/ page also provides some
>> >> >> guidances
>> >> >> > for
>> >> >> > > > >> cases
>> >> >> > > > >> that we use it as a sandbox (open to all registered
>> >> users) or
>> >> >> > > > >> documentation
>> >> >> > > > >> site (open to folks with CLA on file).
>> >> >> > > > >
>> >> >> > > > >
>> >> >> > > > > I also think all our content should be open to any
>> registered
>> >> >> user.
>> >> >> > We
>> >> >> > > > > want
>> >> >> > > > > everyone to help maintain it and thats going be more
>> >> likely to
>> >> >> > happen
>> >> >> > > if
>> >>

Re: Suggestions for Tuscany SCA documenation?

[Simon Laws]

On 2/8/07, Shelita Overton <[EMAIL PROTECTED]> wrote:


Hi Dan,

I think this is a great start. I think it is safe to go ahead and create
this structure.  This will definitely help to avoid duplication.  Thanks!


On 2/8/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>
> Hi Shelita,
>
> I'd like to partner with you on writing some documentation and had also
> started a page on the wiki @
>
>
http://cwiki.apache.org/confluence/display/TUSCANY/Building+SCA+for+Javawhich
> has some overlap with Raymonds more recent addition.
>
> How about we break the getting starting down into a number of smaller
> pages
> so we can work on them more easily. I propose:
>
> User Guide
>+ Getting Tuscnay's Java SCA
>+ Choosing between a package runtime and building your own
>+ Downloading and installing a release
>+ (use the the approach I'm experimenting with @
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg13707.html)
>+ Setting up a build environment
>+ Choosing a source / understanding the source tree
>+ Building - which bits to build
>  + Debugging build issues
>  + Build tips (eg. use of mvn -fn to continue building
> despite test case failures)
>+ Setting up an "SCA Developer" environment (cover both command line
> and
> IDEs (Eclipse and others)) suitable for a user of Tuscany (as opposed to
a
> developer of)
>+ Developing a simple SCA composite containing a single component
>+ Initial project setup (is there an alternative to maven ?)
>+ Developing a simple component
>+ Unit testing and debugging a component
>+ Composing components into composites
>+ Exposing the composite to the outside world (define the
> service binding)
>+ Web Services, JMS etc
>+ Resolving dependencies not contained in the composite
> (defining the reference bindings)
>+ Web Services, JMS - others ?
>+ Reusing components in composites
>+ Deploying to server runtime (eg. tomcat & geronimo ?)
>( + Managing / monitor / changing components & composites )
>...
>
> I think it might also bring up some interesting things to consider...
for
> example, "How can I reuse components in a composite without copying it
> from
> another project ?"
>
> If folks agree with this structure (or similar) then I'll go ahead and
> create it - I think it would be a good idea to agree some structure
> upfront
> to avoid duplication (which seems likely unless we have one author).
>
> WDYT ?
> Dan
>
> On 07/02/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I just added a draft @
> > http://cwiki.apache.org/confluence/display/TUSCANY/Getting+Started. We
> > might
> > be able to use it as a starting point and add more meat into it to
help
> > new
> > users understand the basic concepts, steps and tools to develop a
simple
> > SCA
> > application with Tuscany.
> >
> > Thanks,
> > Raymond
> >
> > - Original Message -
> > From: "haleh mahbod" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Wednesday, February 07, 2007 11:33 AM
> > Subject: Re: Suggestions for Tuscany SCA documenation?
> >
> >
> > > Hi Shelita,
> > > Welcome to Tuscany. We definitly need help with documentation :)
> > >
> > > A starting point might be a user giude on  how to develop a simple
SCA
> > > application. This document can then incrementally grow to  cover
more
> > > advanced topics.
> > >
> > > Another project might be to work on an SCA user doc with examples.
> This
> > > would provide a quick reference to SCA rather than requiring people
to
> > > read
> > > all the specifications.
> > >
> > > I would be happy to join you in this effort. We can start using
> > Confluence
> > > Wiki to work on the documents.
> > >
> > > Does the 'user guide' sound like a good starting point for you?
> > >
> > > What do others think?
> > >
> > > Haleh
> > >
> > >
> > > On 2/7/07, Rick Rineholt <[EMAIL PROTECTED]> wrote:
> > >>
> > >> Hello,
> > >> If your totally new to SCA/Tuscany having a fresh pair of eyes
> looking
> > >> at first understanding SCA, looking at our website how easy it is
to
> > >> find resources, how well those were, then moving on to the samples
in
> > M2
> > >> and then try and understand how contribute to Tuscany itself and
> along
> > >> the way provide feedback and updates can be always beneficial.  I
> think
> > >> that's ground anyone first starting out would initially have to
cover
> > to
> > >> some degree or another.
> > >> If your not new, you'll need to give some background and where your
> > >> interests are in general.
> > >> .
> > >> Shelita Overton wrote:
> > >> > Hi I would like to help with creating some documenation for
Tuscany
> > >> > SCA...
> > >> > Does anyone have any suggestions on what should be covered first?
> > >> > Priority?
> > >> > Any content that could be used as a starting point?
> > >> >
> > >> > ~Shel

Re: Suggestions for Tuscany SCA documenation?

[Simon Laws]

On 2/8/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Hi,

Nope I hadn't done it yet, I wanted to get a go ahead 1st :)
I'll create them now but won't get a chance to put much / any content in
b4
tomorrow... so feel free to pick a page and start work on it... we can
then
all contribute drafts and then use the commenting system in the wiki tro
refine it later...

Everyone ok with this ?

Start page is
http://cwiki.apache.org/confluence/display/TUSCANY/User+Guide

Cheers,
Dan



On 08/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 2/8/07, Shelita Overton <[EMAIL PROTECTED]> wrote:
> >
> > Hi Dan,
> >
> > I think this is a great start. I think it is safe to go ahead and
create
> > this structure.  This will definitely help to avoid
> duplication.  Thanks!
> >
> >
> > On 2/8/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Shelita,
> > >
> > > I'd like to partner with you on writing some documentation and had
> also
> > > started a page on the wiki @
> > >
> > >
> >
http://cwiki.apache.org/confluence/display/TUSCANY/Building+SCA+for+Javawhich
>
> > > has some overlap with Raymonds more recent addition.
> > >
> > > How about we break the getting starting down into a number of
smaller
> > > pages
> > > so we can work on them more easily. I propose:
> > >
> > > User Guide
> > >+ Getting Tuscnay's Java SCA
> > >+ Choosing between a package runtime and building your
own
> > >+ Downloading and installing a release
> > >+ (use the the approach I'm experimenting with @
> > >
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg13707.html
> )
> > >+ Setting up a build environment
> > >+ Choosing a source / understanding the source tree
> > >+ Building - which bits to build
> > >  + Debugging build issues
> > >  + Build tips (eg. use of mvn -fn to continue
building
> > > despite test case failures)
> > >+ Setting up an "SCA Developer" environment (cover both command
> line
> > > and
> > > IDEs (Eclipse and others)) suitable for a user of Tuscany (as
opposed
> to
> > a
> > > developer of)
> > >+ Developing a simple SCA composite containing a single component
> > >+ Initial project setup (is there an alternative to maven
> ?)
> > >+ Developing a simple component
> > >+ Unit testing and debugging a component
> > >+ Composing components into composites
> > >+ Exposing the composite to the outside world (define the
> > > service binding)
> > >+ Web Services, JMS etc
> > >+ Resolving dependencies not contained in the composite
> > > (defining the reference bindings)
> > >+ Web Services, JMS - others ?
> > >+ Reusing components in composites
> > >+ Deploying to server runtime (eg. tomcat & geronimo ?)
> > >( + Managing / monitor / changing components & composites )
> > >...
> > >
> > > I think it might also bring up some interesting things to
consider...
> > for
> > > example, "How can I reuse components in a composite without copying
it
>
> > > from
> > > another project ?"
> > >
> > > If folks agree with this structure (or similar) then I'll go ahead
and
> > > create it - I think it would be a good idea to agree some structure
> > > upfront
> > > to avoid duplication (which seems likely unless we have one author).
> > >
> > > WDYT ?
> > > Dan
> > >
> > > On 07/02/07, Raymond Feng < [EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I just added a draft @
> > > > http://cwiki.apache.org/confluence/display/TUSCANY/Getting+Started
.
> We
> > > > might
> > > > be able to use it as a starting point and add more meat into it to
> > help
> > > > new
> > > > users understand the basic concepts, steps and tools to develop a
> > simple
> > > > SCA
> > > > application with Tuscany.
> > > >
> > > > Thanks,
> > > > Raymond
> > > >
> > > > - Original Message -
> > > > From: "haleh mahbod" <[EMAIL PROTECTED]>
> > > &

Re: Content for next milestone

[Simon Laws]

On 2/8/07, Sam Ruby <[EMAIL PROTECTED]> wrote:


On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote:
>
> > On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> >> >
> >> > So I think we need a branch to do this stabilization work
> >>
> >> I'm disturbed by this proposal as I don't think we have consensus in
> >> the community yet on this issue.
> >
> > This is not an issue that requires consensus.  I've referred
> > previously to a memo tited 'rules for revolutionaries'[1] which
> > addresses the need to reduce friction in times like these.
>
> Consensus may have been the wrong word - common understanding of what
> the branch is for might have been better phrasing. There's been talk
> about stabilizing for a release (which is often when branches are
> used for), but also about developing new features (which is usually
> done in trunk). Is this someone's personal environment, or a
> revolution? I simply don't know.

It actually is unknowable.  It is the nature of the work.

The branch could go nowhere.  It could become the basis for people to
quickly these scenarios to the trunk.  It could expose problems
earlier than would otherwise be found on the trunk.

At a minimum, it will not disrupt continued progress on the trunk, and
by being done in the open and under a compatible license, it can be
readily cannibalized at any point.

> I think consensus here though is important - not on whether we create
> a branch but in the impact this has on how we develop as a community.
> We were working together, all of a sudden something has changed and
> now we have friction. That's what we need to fix.

Reviewing the archives, what I see is mounting frustration, one that
would benefit from a release valve.  No-one seems to be questioning
that the work that is going on in the trunk is necessary, the only is
growing recognition that more parallelism is required.

> >> If the issue here is that trunk is unstable, then we should stabilize
> >> trunk.
> >
> > That would be wonderful.  But let's put that in concrete terms.  At
> > least one individual (and possibly several) is interested in working
> > on the 'BigBank' end to end scenario.  Other (others?) are interested
> > in verifying fixes to issues reported in JIRA.
> >
> > Which would minimize friction more?  Allowing that work to proceed in
> > a branch, or for that individual (or individuals) to start exercising
> > their right to veto any change that impedes their progress?  The
> > latter approach would put a significant, albeit short term, damper on
> > refactoring efforts, independent of the long term value in said
> > refactoring.
> >
> > So, to put a not so fine point on it, it would represent essentially a
> > moratorium on all but the most insignificant refactoring efforts.
> >
> > Is that what this group wants?
>
> I don't know.

Actually, I would seriously doubt it.

> One of the factors here is the change in the spec APIs from 0.95 to
> 1.0 which had many incompatible changes. I think we all want to
> support 1.0 but reality is that all of our samples, "end-to-end
> scenarios" and itests are written against the 0.95 level. We knew
> evolution to 1.0 would be disruptive which is why we have a "pre-
> spec" branch as a baseline for ongoing development at the 0.95 level;
> it seems like some friction is coming because this is not working and
> perhaps tackling that will make things smoother.

Perhaps.  But it is also possible that a branch that is closer to the
current trunk would be less disruptive long term.  And not necessarily
just one branch, this process could conceivably even repeat
periodically, and eventually converge.

> People have talked about working on scenarios and Jira issues, but
> it's not clear if they are intending to do that at the 0.95 level or
> at the 1.0 level. If at the 1.0 level, the harsh reality is that we
> don't have a 1.0 level runtime yet to support them - some of us are
> working on it but it's not done yet. I think joining in that work is
> the most effective way to get something that can run 1.0 level
> scenarios, but if people want to start a branch and do it there
> that's cool too.

At some point you hit the mythical man month "nine women, one baby" issue.

re: "if people want to start a branch and do it there that's cool too."

+1

> > If so, another way to proceed is for the project to adopt a 'review
> > then commit model', whereby all changes are proposed for discussion
> > and voted on before commits are made.  Projects which place a high
> > premium on stability, like the Apache HTTPD project operate in this
> > way everyday.
>
> I've been wondering about that too - not for stability, but for the
> community-building aspect. It's certainly a better option than
> throwing vetos around.

Geronimo recently had this imposed on them.  It was just the jolt that
they needed, but once that was accomplished, it was quickly disposed
of.  My thoughts are that it is an option to 

Multi language system - from: Content for next milestone

[Simon Laws]

On 2/9/07, Jim Marino <[EMAIL PROTECTED]> wrote:


> away in PHP and C++ land. But I've only this week started again to
> think
> about looking back at getting the various runtimes to play together
> having
> not looked at Java SCA since M1 days.
That would be cool. We're getting the federated pieces in place and
are using JXTA which has a C++ implementation.

> Back then I got put off because of
> the revolution moving from M1 to the M2 approach made it very
> difficult, for
> the Java SCA novice like me at least, to do anything sensible. My
> timing
> must be really messed up because I'm now looking at this thread with a
> certain sense of Deja Vu. I'm interested in being able to test
> running Java
> SCA composites over the coming weeks. Not absolutely convinced I
> need a
> system supporting all the 1.0 features this minute but clearly it
> would be
> good not to be prevented from moving in that direction.
You probably have several options we'd be happy to help get you spun
up with:

- If you want a (relatively) stable, tested release, I would try M2.
The downside is it is based of the .95 SCA spec. For starting our and
developing apps, I would use this.

- If you want a slightly more updated version for creating runtime
extensions, the pre-spec snapshot should be relatively stable. The
changes from the M2 release are constrained so if you were more
interested in developing an extension on a stable release, I would go
with it.

- If you want to develop against the 1.0 spec, we're pretty close in
trunk to getting support for a good chunk of the 1.0 client APIs.
Meeraj has also made a lot of progress on defining the discovery and
federation messages. Perhaps we could work together on those so the
Java and C++ runtime can federate as a starting point?

I'm happy to help so drop a line on the list.

Jim


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

Thanks Jim for pointing me in the right direction. I'll go and catch up on

the deployment work you've highlighted. I don't know if this is currently in
scope but I would like to have as a target the ability to wire components
from different (language) runtimes together.  Next week I'll see If I can
get Java up with the options you've outline and see what works for me.

Simon

Re: [VOTE] Tuscany C++ sub-project name

[Simon Laws]

On 2/9/07, Andrew Borley <[EMAIL PROTECTED]> wrote:


On 1/30/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> On 1/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> > [snip]
> > Simon Nash wrote:
> > > A repackaging into a kernel and language extensions as suggested by
> > > Pete, Ignacio, and Jeremy seems like a good direction.  We'll still
> > > have to find a name for the (native, C++, scripting, ???) kernel,
> > > though.  And we'll have to decide what kind of distribution bundling
> > > is helpful for our users.  Jeremy's suggestion of combining related
> > > pieces from the "Java" and "C++" worlds seems like a good approach.
> > >
> > > I am not sure why we would put the cpp language extension into the
> > > kernel, as suggested by Pete.  Is this because it is needed by all
> > > other extensions that support scripting languages?
> > >
> > >   Simon
> > >
> >
> > After having thought about various other code names, I'm starting to
> > like "native".
> >
> > I am +1 with separating a kernel from the extensions. The CPP source
> > tree and build structure already have this separation anyway. The
kernel
> > does not depend on the C++ component type support extension so I don't
> > think that it should include that extension.
> >
> > I also like Jeremy's suggestion of combining the current java/ruby and
> > cpp/ruby into a Ruby top level module containing the code to support
> > both Jruby/Java and the Ruby native interpreter and a shared set of
> > samples. I think that the same idea will work well for other Scripting
> > component types (Python, Javascript etc.) and will help us ensure
> > consistency across runtimes.
> >
> > I propose to go even further and generalize this idea to bindings (WS
> > binding, REST binding, an AMQP/Qpid binding may be a good candidate
too)
> > and other component types as well.
> >
> > I would like to stage some of these changes as they will generate
> > significant work to adjust all the build files etc. I'd suggest to
start
> > changing the terminology (core to kernel, C++ to native) and see how
we
> > can share some samples, but attack the refactoring of the source trees
> > and the build system later, after the C++/native M3 release.
> >
> > Thoughts?
> >
> > --
> > Jean-Sebastien
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > All of this refactoring sounds interesting and many systems distribute
a
> core/kernel and then optionally allow you to download extensions, PHP
for
> example. I should say that in the PHP case poplar extensions find their
way
> into the kernel/core over time once they have proved their worth because
> people don't particularly like downloading extensions.
>
> As Jean-Sebastien pointed out this separation already exists in the make
> system so the user can choose precisely which bits to build once the
source
> distro has been downloaded. In the case of the binary distro I think the
> case will be that the system only picks up those extensions that you
> reference in SCDL so that fact that you have installed all of them is
not an
> issue given the number of extensions we have now. I would therefore
suggest
> that the extra complexity of delivering physically separate tars for
> extensions and kernel is not required for M3 particularly because
Jeremy's
> ideas are interesting and may lead to rehashing the details of how this
is
> done for M4 anyhow.
>
> Simon
>

I think I'm leaning towards this strategy too now - keep a single
binary downloadable package - as Simon says "the system only picks up
those extensions that you reference in SCDL so that fact that you have
installed all of them is not an issue".

I do think we still need a name change, and "native" seems to be the
favourite. I'm happy with this - what do others think?

The only issue is with our samples - most of them require more than
one extension (e.g. the PythonCalculator shows the use of both the
Python and WS binding extensions) - maybe we should split some of them
up a bit more. With clear docs that explain what each sample requires
this should be OK.

So my proposal now is that the C++ M3 release provides source and
binary "Tuscany SCA Native" packages for Windows, Linux and Mac OSX,
with only the extensions (and their respective samples) that can be
built on that OS available within the pac

Re: Suggestions for Tuscany SCA documenation?

[Simon Laws]

On 2/10/07, haleh mahbod <[EMAIL PROTECTED]> wrote:


Ah. You add a good point that we need to think about extension documents
as
well :)

On 2/9/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> On Feb 9, 2007, at 4:56 PM, haleh mahbod wrote:
> > "Extension developer would generally not work off the latest code (I
> > generally discourage people from doing this as the state of trunk may
> > be in flux). They would tend to go off a published release."
> >
> > OK.  Although it seems like all discussions are typically centered
> > around
> > the latest code on mailing list.
> > Maybe this is what we should encourage.
>
> When you munge everything together it can be hard to tell. Most of
> the technical discussion recently has been around changes to the
> kernel rather than extensions and so naturally relates to the latest
> kernel code. If we did have discussion around an extension, it would
> be about the latest code /of that extension/.
>
> --
> Jeremy
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


So, from this thread, a number of things that partition our documentation.

Underlying technology: Java, C++
Project: SCA, SDO, DAS
Module(?): Kernel, Runtimes, Extensions...
Release: M1, M2, M3 (are the next releases going to be at the module level
now?)
Reader: User, Extension Developer, Developer

It seems that the Cwiki is shaping up as follows:

SCA
 Java
User pages
Intro
Installing
Samples
Building an app
What extension are available
Etc…
Developer pages
Intro
Architecture
Dev env
Module docs
Etc…
C++
FAQ - not sure why this is at this level?
SDO
 Java
 C++
 FAQ
DAS
 Java
 C++
 FAQ


It's difficult to comment on whether developer docs should be separate from
extension developer docs but if feels like it's a low priority at the
moment. We should make space to describe the separate modules that are
available both from user and developer perspectives.

Is there still going to be a full milestone release at some point where
documentation is built or are the separate modules going to advance
independently? This will flavor how we keep track of what we are writing
docs for. As we are still in incubation can we continue just to worry about
the latest code? I like the idea of using new spaces to represent
documentation for major releases but that doesn't work for finer grained
releases. We need a way of marking which details relate to which version.
Confluence themselves label pages, e.g,  (
http://confluence.atlassian.com/display/DOC/Administrators+Guide), but I
don't know  how they use the labels exactly yet.

As Dan pointed out page names must be unique within a space but this doesn't
cause particular pain in our PHP site as we just prefix page names. We do
have a very small number of pages though. We also use the Left Navigation
theme. This provides a left hand menu like they have on CFX (
http://cwiki.apache.org/CXF/) as Shelita noted. Changing the theme is a
space admin task. If we want this is Ted Husted the man to talk to? Does
anyone from Tuscany have space admin privileges?

Simon

Re: Multi language system - from: Content for next milestone

[Simon Laws]

On 2/9/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Feb 9, 2007, at 5:59 AM, Simon Laws wrote:
> Thanks Jim for pointing me in the right direction. I'll go and
> catch up on
> the deployment work you've highlighted. I don't know if this is
> currently in
> scope but I would like to have as a target the ability to wire
> components
> from different (language) runtimes together.  Next week I'll see If
> I can
> get Java up with the options you've outline and see what works for me.

It's definitely in scope, in fact it's a key design issue and one
reason kernel is changing.

The design is that there is a "master" node that is working out which
"physical" nodes components are going to run on. It then passes
PhysicalComponentDefinition's to the worker nodes to get them to
create the component and any transport bindings it needs to talk to
other nodes. The PCDs are portable, independent of the type of
runtime, instead tied to the type of component.

Picking on Ruby as an example as we know we can run that on Java and
Native runtimes, there could be one common PCD for a Ruby component
that was supported by all container implementations. The master could
send that to any node to have it run a Ruby component. A runtime
could also offer "enhanced" Ruby support with additional features
that required additional configuration. If would offer support for a
different PCD with that additional metadata. Which one is selected by
the master would be part of its component allocation algorithm.

So basically, any runtime that can connect to the federated fabric
and handle a PCD can join the SCA domain. We picked JXTA and XML for
the fabric and PCD encoding as there is support for those in both
Java and C++. Adding support for that to the Native runtime would
also be good if you were skeptical of all the Java stuff.

--
Jeremy


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

Thanks Jeremy for commenting. I am of course now looking back through the

archive and seeing that discussions are underway. Doh, sorry about that.


From the distributed assembly [1], federated deployment [2], physical

component definition [3] threads I think I'm starting to appreciate the
proposed direction. There is a fair amount of detail to digest and I'm
struggling a little to separate out the generic bits from guts of what's
changing in Java.


From a native point of view I guess we need to understand


1/ How we employ JXTA to join the SCA federation
2/ The format of the physical model
3/ How we advertise our capabilities (supported components etc.) in order
that "scheduling" decisions can be made.
4/ The nature of command and control system, start, stop etc.


You'll note I'm not proffering an opinion here. I've much to learn yet:-)Maybe
we can start getting a more generic description up on the Cwiki. I looked
and couldn't see one. I may of course be looking in the wrong place. If
there isn't one I'll start putting notes up there as I find out things.

Am I right in saying that you consider deployment, i.e. actually getting
component implementations onto distributed boxes, to be a separate issue
from the federation of active runtimes already configured with
implementations.

I'm not immediately sceptical of the java stuff. I have to say I don't
understand the details. I think the value though is if we can have the
native runtime play too so I'll look there first. I note from the mail trail
that Pete is also interested in this.

[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg12900.html
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg13607.html
[3] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg13830.html

Re: Suggestions for Tuscany SCA documenation?

[Simon Laws]

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


[snip]
Tom Seelbach wrote:
> If the wiki was switched to a "left menu theme" it would probably
> apply to the whole space.
> That would not work well for Tuscany since it has 3 separate projects
> (sca, sdo, das) as well as 2 implementations (java, cpp).
> i.e. the site is very complicated and it wouldn't be worth it to carry
> that left menu everywhere.  There is always the
> horizontal link navigation at the top of every page anyway so a user
> is only one click from the top page.
>
> I just added a left-hand-nav  to the wiki homepage to serve as a TOC.
> It's pretty simple.
> I tried to follow the existing Tuscany home as much as possible, and
> link to new information on the wiki as well.
> If the team agrees with this approach, we can migrate useful
> information off of the existing homepage
> and onto the wiki.   If the team doesn't think this is the way to go,
> its a simple "undo".

+1, I like it.

> I'm willing to port some of the existing pages over and update them in
> the process if this helps.

Thanks!

--
Jean-Sebastien


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

Hi Tom


Sidebar looks good to me. Lets give it a spin and see how it goes. +1

Simon

Re: Getting plugin doco on the website

[Simon Laws]

On 2/15/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Not a very clean suggestion & one you've probably thought of already

Publish the itest site as is (in the tuscany web space) and just link to
it
from the wiki.

On 14/02/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> I started on some documentation for the itest plugin and am wondering
> how to integrate this with the stuff on the wiki.
>
> I'm using the reporting in the maven-plugin-plugin to generate the
> doco as it pulls all the goal information out of the Mojo so apart
> from usage/examples the content is self generating. It creates a mini-
> site with a bunch of HTML pages and I'd like to get that linked into
> the main site.
>
> Any ideas on how to do that with the wiki?
> --
> Jeremy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


In the old wiki you can upload html files and link to them, e.g. here are
the  attachments http://wiki.apache.org/ws-data/attachments/, if you don't
have anywhere else I guess you could host it there but it's harder than
checking it into svn somewhere.

In cwiki I've read that you can attach html but it seems a bit fiddly, e.g.
http://confluence.atlassian.com/display/CONFEXT/HTML+Plugin. Not tried any
of this though so there might be a really easy way that I just haven't
discovered.

As Dan says you can easily link to external web pages from cwiki so that's
probably the easiest solution, e.g
include the following in the wiki markup for page and you have a link to the
Apache license

[version 2 of the Apache license|http://www.apache.org/licenses/LICENSE-2.0]

Simon

Re: Tuscany Native sample matrix (was vote on project name)

[Simon Laws]

On 2/16/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


On 16/02/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> On 2/16/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > I've now removed the Axis2C clients to CppCalculator and CppBigBank.
> >
> > Cheers,
> >
> >
> > On 15/02/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> > >
> > > On 2/15/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > > starting a new thread for this.
> > > >
> > > >
> > > >
> > > > On 15/02/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >
> > > > >
> > > > > OK, it's committed - check out the Sample Dependencies table in
> > > > >
> > > > >
> > >
>
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/GettingStarted.html
> > > > > It's a big table (I've split binding extension dependencies into
> their
> > > > > service & reference pieces and also specified which container
each
> > > > > sample runs under - Axis2C simple HTTP server or HTTPD) - do
> people
> > > > > think it helps? Could it be simplified in some way?
> > > > >
> > > > > Cheers
> > > > > Andy
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > > This is good. It highlights that we can not demo Python or Ruby
> > > without a
> > > > ws binding... which is bad IMO.
> > > >
> > >
> > > Agreed. Perhaps we should remove the WS binding elements from all
the
> > > *Calculator samples (as we did with CppCalculator), so they only
have
> > > local clients.
> > >
> > >
> > > > I think we need a sample for each language extension that requires
> only
> > > the
> > > > core and the particular language extension. I'll experiment with
> > > creating a
> > > > ws binding  sample that re-uses the basic cpp calculator sample
> > > composites.
> > >
> > > Sounds good - we only need a single WS-binding oriented sample.
> > > There's plenty of other examples of the WS (and REST) bindings in
the
> > > *BigBank and other samples.
> > >
> > > Cheers
> > > Andy
> > >
> > >
-
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Pete
> >
>
> r508464 adds in an extra table that specifies the external
> library/runtime dependencies that each sample requires for
> building/running.
> See
>
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/GettingStarted.html
> again.
>
> Cheers
> Andy
>
> -


Good work. You may want to have 2 separate columns for Axis2C library and
server. The CppBigBank sample makes outbound ws calls only so does not
require the server.

Cheers,


--
Pete


Hi Andy

Starting to look useful.

- It looks a little odd (to me:-) that you map samples to Extensions and
then map them again to dependencies. Why didn't you go for
Samples->extensions->dependencies?
- There are a few dependencies missing. See (
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+CPP+Dependencies)
- In the future i.e. not for M3, I assume we could generate these tables
based on what extensions appear in the sample SCDL

Simon

Re: Problems with Ruby extension on linux

[Simon Laws]

On 2/16/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


The RubyCalculator sample fails on linux. It gets to the

require("tuscany_sca_ruby")

statement and then segv's. This is on my RHEL linux.3. On Mac it get's to
this point and fails to find the library(could be a load failure) and on
Andy's linux it gets a LoadError.

Does anyone know the last time that the ruby extension and samples worked?
Are there some new library dependencies that have been added recently?

Cheers,

--
Pete


Pete

I'm afraid I haven't run it for a while but I have it on my fc5 box so could
try it next week if that helps.

Simon

[C++] REST binding

[Simon Laws]

I'm just having a crack at putting a PHP front end on the Alert sample and
have come up against some of the assumptions in the SCA Native Rest binding.
Is there a readme anywhere that describes what the valid combinations of
verbs and data are?

Looking at the code it seems that it assumes you are mostly dealing with XML
unless you are passing parameters in on a GET. Does the binding take any
account of the content type of the message? There are also some wrapping
sematics that it would be good to get an explanation of.

Thanks

Simon

Re: [C++] REST binding

[Simon Laws]

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


Simon Laws wrote:
> I'm just having a crack at putting a PHP front end on the Alert sample
> and
> have come up against some of the assumptions in the SCA Native Rest
> binding.
> Is there a readme anywhere that describes what the valid combinations of
> verbs and data are?
>
> Looking at the code it seems that it assumes you are mostly dealing
> with XML
> unless you are passing parameters in on a GET. Does the binding take any
> account of the content type of the message? There are also some wrapping
> sematics that it would be good to get an explanation of.
>
> Thanks
>
> Simon
>

I've not looked at this code for a while but if I remember correctly
here are the patterns that are currently supported.

If the service/reference uses an  interface, we map CRUD
methods to HTTP verbs to access resource representations as follows:

resource = retrieve()
-> GET 
<- an XML element representing the REST resource

resource = retrieve(uri, parm-value-1, parm-value-n)
-> GET uri/parm-value-1/parm-value-n
or if uri ends with a '?'
-> GET uri?parm-name-1=parm-value1&parm-name-n=parm-value-n
<- an XML element representing the REST resource

uri = create(resource)
-> POST  + an XML element representing the resource to create
<- Location header containing the uri of the created resource

update(resource)
-> PUT  + an XML element representing the updated resource

update(uri, parm-1, parm-n, resource)
-> PUT uri/parm-value-1/parm-value-n + an XML element representing the
updated resource
or if uri ends with a '?'
-> PUT uri?parm-name-1=parm-value1&parm-name-n=parm-value-n + an XML
element representing the updated resource

delete()
-> DELETE 

delete(uri, parm-1, parm-n)
-> DELETE uri/parm-value-1/parm-value-n
or if uri ends with a '?'
-> DELETE uri?parm-name-1=parm-value1&parm-name-n=parm-value-n

In this mode, HTTP return codes are used almost as described in the Atom
spec. Also GET returns etags with the retrieved resource representations
to help caching by clients.

If the service/reference does not use an  interface,
then this is not a real REST pattern, we simply flow method calls over
XML / HTTP as follows:

result = method-abc(parm-1, parm-n)

if single input parameter of complex type
-> POST /method-abc + XML element representing the complex
parameter
or if multiple parameters including parameters of complex types
-> POST /method-abc + Mime multipart/form-data body
containing one parameter per part
or if multiple parameters all of simple types
-> GET
/method-abc?parm-1-name=parm-1-value&parm-n-name=parm-n-value

<- an XML element representing the result

Most combinations are demonstrated in the RestCustomer and
RestCalculator samples. It's pretty easy to run these samples and
capture the HTTP traffic with an HTTP monitor.

--
Jean-Sebastien


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

That's a great summary Jean-Sebastien. Thank you. I've copied here (

http://cwiki.apache.org/confluence/display/TUSCANY/SCA+CPP+Bindings+REST)
for safe keeping. I got caught out in making the sample work in that the
existing binding doesn't support POSTing multiple simple type parameters.
Clear now it's spelled out:-) Anyhow I go round it by changing to GET for
the time being. I'll maybe look at this if I have time in the future.

Regards

Simon

Re: Fw: JSDO for FLEX/OpenLaszlo to RoR linkage

[Simon Laws]

On 2/20/07, George Willis <[EMAIL PROTECTED] > wrote:


I'ld like to open "SDO Ruby" development.  See below.


- Forwarded Message 
From: George Willis < [EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, February 20, 2007 3:12:53 PM
Subject: Fw: JSDO for FLEX/OpenLaszlo to RoR linkage


David,

This is really a step beyond ActiveResource, where RESTful actions are
consumed and abstracted into a multi-tiered intelligent cache, that updates
via "push/pull" techniques.

Imagine a world where the DOM in an RCI Browser client is actually an
intelligent cache that is synced to a business server model.  Unbeknown to
the RCI client, the business server does not have have any persistence, but
is itself another intelligent cache that coordinates the various RCI client
concurrency, and acts as an intelligent cache client backended by another
server that provides "data mediation" to S3.  All the synchronization
happens ubiquitously, and RESTful client can also access the "model".  This
is my dream of JSDO for Rails -- an RCI technology to allow RCI developers
to work with "datasets" (DOM), and for the synchronization of concurrency
issues to be accomplished via an SDO pattern using javascript and Rails.

This may be the most important email you'll read today -- if you actually
read it :)

George Willis, ex-Fortune 500 J2EE architect turned sane
(208) 340-8246

P.S.  See the Apache Tuscany project


- Forwarded Message 
From: George Willis <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Sue Liu <[EMAIL PROTECTED]>; laszlo-dev@openlaszlo.org
Sent: Friday, February 16, 2007 1:06:22 PM
Subject: JSDO for FLEX to RoR linkage


I've looked at the various "RESTful" ways of interfacing FLEX/OpenLaszlo
with RoR, and they all seem to be taking a step back.  Let me explain.

Whether you use WebOrb services, SOAP, or REST, you are usually still
adhering to a CRUD design pattern.  You map four distinct actions on the
client side into four distinct services on the server side. (The nature of
the new ActiveResource initiative).

Now, there is nothing wrong with this, and I'm not trying to get into a
flame war.  But there have been some better design patterns that have come
forth.  Before I go on, there is some homework to be done to understand
Javascript Data Object and the SDO inititive.

http://en.wikipedia.org/wiki/Service_Data_Objects

http://www.osoa.org/display/Main/Service+Data+Objects+Home   - Note, no
Ruby :(

http://www-128.ibm.com/developerworks/java/library/j-sdo/


http://dl.alphaworks.ibm.com/technologies/faces4laszlo/faces4laszlo_whitepaper.pdf-
 SDO for OpenLaszlo to Java (Section
3.4 talks about WDO4JS is synonomous with SDO4JS which was later renamed
JSDO)

http://www.nyphp.org/content/presentations/ibm/ria-nyphp-overview.pdf -
The best article around on this stuff


http://sourceforge.net/project/showfiles.php?group_id=173788&package_id=199079&release_id=439723-
 Faces for Laszlo download

Now, if you are still with me, perhaps the lights are on.  Basically, some
bright folks at BEA had an idea and implemented it in LiquidData.  IBM liked
the design, and partnered with them to create the formal name of SDO.  IBM
used the pattern to handle persistence in Eclipse, and then both of them
built the pattern into their J2EE servers to enable Ajax.  It has since been
ported to other platforms, most notibly to enable OpenLaszlo/Java and
Ajax/PHP.

Let me explain why we should all be interested.

Did you ever stop to think about what we were really doing to the MVC
model with AJAX/RIA?  We are basically caching a submodel (in MVC terms) on
the client, manipulating that cloned copy, and then merging it back.  The
only gotcha is concurrency issues -- others making updates that impact the
submodel we are working on.

Wouldn't it be great to have a technology to handle all this in the
background?  That's what SDO is all about.  It's is basically the ideal of
creating a "dataset" (in SDO and Laszlo terms, "Dataprovider" I believe in
Flex) and making that the focus of what the client side code works on.

The idea of focussing on datasets on the client side is very
appealing.  It allows you to substitute test datasets from files or embedded
as objects in an RIA client and focus getting the client experience
developed.  It creates as natural a division of labor as when JSP tags are
implemented properly (I know, a stretch).  Basically, an RIA UI coder can
develop in some RIA syntax (openLaszlo, Flex) using the power of a
declaritive format with constraints to provide the interaction between
components, and stay focus on this task.  The marshalling of the submodel
from the server to the client and the merging of submodal changes on the
issues of locking and concurrency are handled by standard code.

Now, don't get confused when you read this stuff.  I'm not talking about
trying to use some kind of JSP tag metaphor with RoR.  What I am trying to
say is there are a lot of pieces lying around t

Re: [C++] SCA PHP Extension patches

[Simon Laws]

On 2/21/07, Caroline Maynard <[EMAIL PROTECTED]> wrote:


I've been battling with getting this working under Windows, and attach a
patch with my latest efforts. Note that these changes work hand-in-hand with
corresponding changes to the Tuscany bindings for PHP SCA, which are already
in place in the AVOCET branch in the PECL repository.

On my Windows box with the patch installed, the PHP Calculator sample runs
clean, with no crashes on shutdown and no reported leaks of PHP memory.

I've also done quite a bit of tidying up, to make the inner workings a
more standard use of the PHP engine. In particular, I've broken out the big
php_eval_script() into its component parts, which makes it much easier to
debug. Unfortunately I haven't had time to refactor
SCA_TuscanyWrapper::invoke() subsequently, so it is rather a long sprawl at
present and could do with further prettying. I also hid the SCA_Tuscany
object handle from user space, because exporting the handle as a reference
was rather dangerous code.

One thing I haven't yet tackled is getting the thread context right for
reentrant paths through the extension. I've been investigating this, and I
think it's going to require saving a thread context in each of the mediator
objects, and restoring the correct one on invoke(). However what's there
seems to work OK in the simple environment of the PHP Calculator sample.

I'm out for a few days now - could someone give it a spin on *IX and make
sure that's still OK?

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

> I've just checked in some changes to the VC project on windows which
> will
> hopefully work for you now. I've also
> updated the build for the PHP Calculator sample. Having said this I
> can't
> get it to run on my windows box. As I've said before I'm a bit
> suspicious of
> my windows configuration but I'm not getting the same error as before so
>
> it's likely that ithis is a real problem with the PHP Extension code.
> Would
> still be useful to know if you see a failure in the PHP engine code
> also.


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


Great, thanks Caroline. I'll give it a spin.

Simon

Re: [C++] SCA PHP Extension patches

[Simon Laws]

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




On 2/21/07, Caroline Maynard <[EMAIL PROTECTED]> wrote:

> I've been battling with getting this working under Windows, and attach a
> patch with my latest efforts. Note that these changes work hand-in-hand with
> corresponding changes to the Tuscany bindings for PHP SCA, which are already
> in place in the AVOCET branch in the PECL repository.
>
> On my Windows box with the patch installed, the PHP Calculator sample
> runs clean, with no crashes on shutdown and no reported leaks of PHP memory.
>
>
> I've also done quite a bit of tidying up, to make the inner workings a
> more standard use of the PHP engine. In particular, I've broken out the big
> php_eval_script() into its component parts, which makes it much easier to
> debug. Unfortunately I haven't had time to refactor
> SCA_TuscanyWrapper::invoke() subsequently, so it is rather a long sprawl at
> present and could do with further prettying. I also hid the SCA_Tuscany
> object handle from user space, because exporting the handle as a reference
> was rather dangerous code.
>
> One thing I haven't yet tackled is getting the thread context right for
> reentrant paths through the extension. I've been investigating this, and I
> think it's going to require saving a thread context in each of the mediator
> objects, and restoring the correct one on invoke(). However what's there
> seems to work OK in the simple environment of the PHP Calculator sample.
>
> I'm out for a few days now - could someone give it a spin on *IX and
> make sure that's still OK?
>
> On 07/02/07, Simon Laws < [EMAIL PROTECTED]> wrote:
>
> > I've just checked in some changes to the VC project on windows which
> > will
> > hopefully work for you now. I've also
> > updated the build for the PHP Calculator sample. Having said this I
> > can't
> > get it to run on my windows box. As I've said before I'm a bit
> > suspicious of
> > my windows configuration but I'm not getting the same error as before
> > so
> > it's likely that ithis is a real problem with the PHP Extension code.
> > Would
> > still be useful to know if you see a failure in the PHP engine code
> > also.
>
>
> --
> Caroline
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
Great, thanks Caroline. I'll give it a spin.

Simon


Hi Caroline.

I can't find the JIRA that you attached the patch to. Can you point me in
the right direction?

Thanks

Simon

Re: [C++] SCA PHP Extension patches

[Simon Laws]

On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


Thanks. The apache mailing list seems sensitive to attachments. The
Jira is the right place for it anyway.

Cheers,

On 21/02/07, Caroline Maynard <[EMAIL PROTECTED]> wrote:
> I had attached it to my post, and it appeared to get through OK for
me,  but
> perhaps not for others.  So I've now raised
> https://issues.apache.org/jira/browse/TUSCANY-1133 and attached it to
that.
>
> On 21/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> >
> > I can't find the JIRA that you attached the patch to. Can you point me
in
> > the right direction?
> >
>
> --
> Caroline
>


--
Pete

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

Thanks Caroline

[Native] PHP Client for Alert Sample

[Simon Laws]

I just checked in a PHP SCA client for the AlertAggregator sample (
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/AlertAggregator/httpserver.php/).
It uses the PHP SCA implementation but doesn't use any of the PHP Extension
functionality we are putting into the Native runtime itself. Anyhow it
shouldn't affect anything unless you explicitly go and run it. But let me
know if there are any issues.

Regards

Simon

Re: [C++] SCA PHP Extension patches

[Simon Laws]

On 2/22/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> Thanks. The apache mailing list seems sensitive to attachments. The
> Jira is the right place for it anyway.
>
> Cheers,
>
> On 21/02/07, Caroline Maynard <[EMAIL PROTECTED] > wrote:
> > I had attached it to my post, and it appeared to get through OK for
> me,  but
> > perhaps not for others.  So I've now raised
> > https://issues.apache.org/jira/browse/TUSCANY-1133 and attached it to
> that.
> >
> > On 21/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > I can't find the JIRA that you attached the patch to. Can you point
> me in
> > > the right direction?
> > >
> >
> > --
> > Caroline
> >
>
>
> --
> Pete
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Thanks Caroline


OK, the patch improves the situation on windows somewhat so it's checked in
now. I need to get it out and re-run on linux.

Regards

Simon