>Sure. I could be available. Nicole, what Timezone are you in? I'm PST,
Joel, I believe you are CST.
I'm CET (Germany). Having the IRC in the evening (e.g. 19:00 CET or
later) would be fine for me.
I assume it's anyway easier for me to attend from home (due to the
companies firewall).
Best regard
On Nov 9, 2006, at 2:59 PM, Rick wrote:
I'm not convinced that DAS really requires it but I'll let them be
the judge of that. Just from what I remembered I didn't see the
need so I questioned it. I just think when possible it best to
integrate at the highest level of the stack that suits
I'm not convinced that DAS really requires it but I'll let them be the judge of
that. Just from what I remembered I didn't see the need so I questioned it. I
just think when possible it best to integrate at the highest level of the stack
that suits your needs.
Jim, you lost me and peeked my int
On Nov 9, 2006, at 11:34 AM, cr22rc wrote:
My understanding is you would need to implement classes from
tuscany-spi to implement your container. This is surely specific
to Tuscany. The work that was started by Luciano was as I
understood it a Pojo that was an SCA component. That should b
On Nov 9, 2006, at 12:56 PM, Wengatz, Nicole wrote:
Hi,
thanks for providing the information :-)
I like Joels idea to use fragment bundles. Seems to be a good way to
solve
the classloading challenge.
Is there any document available describing the composite trees?
Unfortunately not yet (I've
On Nov 9, 2006, at 9:59 AM, Kevin Williams wrote:
Jim Marino wrote:
Yes ideally, but I guess this config info is going to be quite
big - so a
whole lot of properties might be required. Maybe it would still
be ok and
its just that I am not yet used to seeing component defintions
wit
On Nov 9, 2006, at 6:44 AM, Hawkins, Joel wrote:
I think an IRC might be helpful. Comments below:
Sure. I could be available. Nicole, what Timezone are you in? I'm
PST, Joel, I believe you are CST.
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Thursday, Nove
@Nicole: Accessing the classloader corresponding to a particular bundle.
It's a back-door cheat like the Declarative Services guys use, and its
very implementation-specific. Plus it's nice to have a place to isolate
implementation-specific stuff. :-)
-Original Message-
From: Wengatz, Nic
Hi,
thanks for providing the information :-)
I like Joels idea to use fragment bundles. Seems to be a good way to
solve
the classloading challenge.
Is there any document available describing the composite trees?
@Joel: What exactly is Equinox-specific in your osgi.equinox bundle?
Thanks
Nicole
Ignacio,
I made a few minor mistakes in my original email. So here is the better
version :-)
I am currently experimenting with developing "SIP enabled" SCA
components. SIP is an asynchronous request/response, session-based
protocol, similar to HTTP.
Tuscany is deployed within our SIP applicatio
Yeah, I was going to ask about that. But since CONVERSATIONAL occurs only
once in the spec and is then replaced by SESSION, it seemed like a typo to
me. And speaking of spec clarifications, would this also include @Session
and its attribute values? I.e., do they apply to both conversations and htt
Ignacio,
Thanks for the quick reply.
I am currently experimenting with writing "SIP enabled" SCA components.
SIP is an asynchronous request/response, session-based protocol, similar
to HTTP.
Tuscany is deployed within our SIP application server. Our SIP app
server receives each incoming SIP requ
On Nov 9, 2006, at 11:16 AM, Ignacio Silva-Lepe wrote:
One of the items to be addressed for conversational services is the
definition of a SessionScopeContainer, which seems to be distinct from
HttpSessionScopeContainer. If that's the case then one question is
what
identifier to use for each
I agree that Tuscany webapps will normally receive or make remote
invocations, and these will require Tuscany extensions and their
dependencies. These extensions and dependencies can be bundled
physically within the war file, or the dependencies can be downloaded
at runtime from an external maven
Ok, but how would that work if service and client are remote ?
We would need the property defined on the client, as each client might be
using a different config file, and how we would tell the remote DAS service
to use that ? and if we specify only a file name, how the remote machine
would have
My understanding is you would need to implement classes from tuscany-spi to
implement your container. This is surely specific to Tuscany. The work that
was started by Luciano was as I understood it a Pojo that was an SCA component.
That should be able to work in any other SCA implementation.
T
On 11/9/06, Luciano Resende <[EMAIL PROTECTED]> wrote:
Hi Guys
Amita have started work to expose DAS as an SCA container, and we are
looking what would be the best way to get collaboration on continuing the
task. One of the ways we were thinking was to clean-up what is available
today and ge
One of the items to be addressed for conversational services is the
definition of a SessionScopeContainer, which seems to be distinct from
HttpSessionScopeContainer. If that's the case then one question is what
identifier to use for each one.
Currently, the value o.a.t.spi.model.Scope.SESSION is b
I think the best possible solution would be what we have discussed as
"Declarative DAS", where we would extend the programming model to expose
services that interact with a persistent layer in a declarative fashion
hiding the implementation details from the service developer, you can see
some disc
Thanks Scott. I went ahead and removed them. There was something that had me
put it in at one time, but apparently it's been fixed.
Scott Kurz wrote:
Why does the annotation:
@DataType(name = "commonj.sdo.DataObject")
appear on both the LoginService and ProfileService interfaces in the
BIgB
[ http://issues.apache.org/jira/browse/TUSCANY-763?page=all ]
Frank Budinsky resolved TUSCANY-763.
Resolution: Invalid
I just found this in the SDO spec:
• Property.default!=null requires type.dataType=true and many=false
which basically says
I absolutely want the best possible solution to integration and this
discussion is helping quit a bit. I may misunderstand but, if we
develop implementation.das and an associated container, wont this be
usable in another SCA implementation?
--
Kevin
Rick wrote:
I quickly skimmed the threads
Jim Marino wrote:
Yes ideally, but I guess this config info is going to be quite big -
so a
whole lot of properties might be required. Maybe it would still be
ok and
its just that I am not yet used to seeing component defintions with
lots of
properties. :)
Why are there so many proper
Hi Luciano, Some comments in line ...
Luciano Resende wrote:
Thanks Kevin, some comments below...
As for the naming :) I was just calling DAS exposed as an SCA service...
On 11/8/06, Kevin Williams < [EMAIL PROTECTED]> wrote:
The term DAS-POJO Service is probably confusing. What I meant i
Without looking at your whole component assembly or application, it's not
clear to me why you would want to create your own thread. I assume your
ComponentService.class includes a @Callback annotation to indicate what its
callback interface is. This is sufficient to tell Tuscany that your
Componen
Can this be a side-effect of :
http://issues.apache.org/jira/browse/TUSCANY-754
- Luciano
On 11/9/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Scott.
Actually, LoginService amd ProfileService is not required to have the
@DataType(name = "commonj.sdo.DataObject") because both interfaces onl
Hi,
I am trying to write an SCA component that invokes a callback
asynchronously (see code at the bottom of this message). In order to
simulate an asynchronous notification, a new thread is created and the
callback is invoked from within that thread.
When I execute the application it throws
Jim Marino wrote:
On Nov 8, 2006, at 8:38 AM, Simon Nash wrote:
Raymond Feng wrote:
1) It seems that you're looking for a collection of tuscany
runtime/extension jars which provides you the artifacts to build the
web application offline using ant or manually. I don't think it's
appropr
Hi, Scott.
Actually, LoginService amd ProfileService is not required to have the
@DataType(name = "commonj.sdo.DataObject") because both interfaces only deal
with simple java types.
You should only apply @DataType to interfaces used by SCDL "interface.xxx"
elements. Interfaces generated by S
Jim,
See my comments inline.
Simon
Jim Marino wrote:
On Nov 8, 2006, at 8:40 AM, Simon Nash wrote:
Jim,
See my comments inline.
Simon
It seems that if you go down this route you will wind up re-
inventing Maven. Maven seems simple enough to me.
I had not intended to reinvent mave
+1
On Nov 9, 2006, at 1:22 AM, Pete Robbins wrote:
I'd like to nominate Geoff Winn to become a Tuscany committer.
Geoff has been involved with the C++ side of Tuscany since May and has
submitted many good patches focusing on SDO C++.
Geoff is active on the SDO specification for C++ and is doin
Why does the annotation:
@DataType(name = "commonj.sdo.DataObject")
appear on both the LoginService and ProfileService interfaces in the BIgBank
sample, while it is commented out in the StockQuoteService? These services
do not involve actual SDO DataTypes, right?
It seems that it should be only
[
http://issues.apache.org/jira/browse/TUSCANY-763?page=comments#action_12448501
]
Frank Budinsky commented on TUSCANY-763:
I'm not sure if the spec is clear on this, but my understanding is that
Property.getDefault() is N/A if property
[
http://issues.apache.org/jira/browse/TUSCANY-763?page=comments#action_12448492
]
Kelvin Goodson commented on TUSCANY-763:
In answer to the above comment, the spec says (in sect 3.1.4 of the 2.1 spec
draft of 20061016)
"If a Property
I think an IRC might be helpful. Comments below:
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 1:12 AM
To: tuscany-dev@ws.apache.org
Subject: Re: OSGi Binding
>...services. I would also like to avoid proxying the OSGi services if
>poss
The DataObject would need to be an argument to nextPage(), etc.
Basically this is doing the same thing you were suggesting, but it
gets rid of the Pager API.
Brent
On 11/8/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
I am probably missing something. If we stash the page size and number
in the
+1
"Pete Robbins" <[EMAIL PROTECTED]> wrote on 11/09/2006 04:22:25 AM:
> I'd like to nominate Geoff Winn to become a Tuscany committer.
>
> Geoff has been involved with the C++ side of Tuscany since May and has
> submitted many good patches focusing on SDO C++.
>
> Geoff is active on the SDO sp
+1
On 11/9/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
I'd like to nominate Geoff Winn to become a Tuscany committer.
Geoff has been involved with the C++ side of Tuscany since May and has
submitted many good patches focusing on SDO C++.
Geoff is active on the SDO specification for C++ and is
I quickly skimmed the threads on this and I didn't pick up what the advantage
was it making this a "container". The only thing I seen was a tighter
integration between DAS and SCA. But as I understand it me this is really a
tighter integration between DAS and Tuscany implementation of SCA. In
[ http://issues.apache.org/jira/browse/TUSCANY-703?page=all ]
Venkatakrishnan updated TUSCANY-703:
Attachment: tuscany_site_Nov_9.zip
Hi,
The popular GREEN is back :).
The modified site files have been attached in the zip tuscany_site_Nov_9.zip.
+1
- Venkat
On 11/9/06, kelvin goodson <[EMAIL PROTECTED]> wrote:
+1
On 09/11/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> +1
>
> On 11/9/06, ant elder <[EMAIL PROTECTED]> wrote:
> > On 11/9/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > >
> > > I'd like to nominate Geoff Winn to become
yep - the gory details are at
http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/default.aspx
- VC++ Express was designed for .NET/CLR apps - to do native, you
need to hook it up to the platform SDK.
On 11/9/06, ant elder <[EMAIL PROTECTED]> wrote:
This was really helpful Judah. One thi
I agree with the color, my experience is that it sets a theme using different
shades and usually matches the logo. If we switch to this brown we should
switch the Tuscany logo there too.
As for the top tabs from an aesthetics view I liked them and they add another
dimension to the site. It
On 11/9/06, Simon Laws <[EMAIL PROTECTED]> wrote:
On 11/8/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> Hi everyone,
>
> Now M2 is finally available, we should start thinking about what we'd
> like to do next in Tuscany C++. There were quite a few items that were
> suggested for M2 that we end
+1
On 09/11/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
+1
On 11/9/06, ant elder <[EMAIL PROTECTED]> wrote:
> On 11/9/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > I'd like to nominate Geoff Winn to become a Tuscany committer.
> >
> > Geoff has been involved with the C++ side of Tuscany
+1
On 11/9/06, ant elder <[EMAIL PROTECTED]> wrote:
On 11/9/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> I'd like to nominate Geoff Winn to become a Tuscany committer.
>
> Geoff has been involved with the C++ side of Tuscany since May and has
> submitted many good patches focusing on SDO C++.
Thats an excellent idea. I think there are still parts of this that could be
made significantly easier by altering the SPI but I'll be happy to have them
in utility jar for now. I'll go do this.
...ant
On 11/9/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
How about adding a scripting utility
On 11/8/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
Hi everyone,
Now M2 is finally available, we should start thinking about what we'd
like to do next in Tuscany C++. There were quite a few items that were
suggested for M2 that we ended up leaving out for time reasons and it
would be good to p
On 11/9/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
I'd like to nominate Geoff Winn to become a Tuscany committer.
Geoff has been involved with the C++ side of Tuscany since May and has
submitted many good patches focusing on SDO C++.
Geoff is active on the SDO specification for C++ and is doi
This was really helpful Judah. One thing i found was that before I could get
very far with building in Visual Studio at step 8 i had to tell it about a
couple of platform SDK directories:
In Visual Studio go Tools -> Options, in Projects and Solutions select VC++
Directories, in "Show Directories
There should be absolutely no need for the webapp to have a copy of
this scdl unless it is trying to redefine how the system is
configured (which is an advanced case).
--
Jeremy
On Nov 8, 2006, at 2:10 PM, Ignacio Silva-Lepe wrote:
To answer my own question, with help from Jim, it turns ou
I'd like to nominate Geoff Winn to become a Tuscany committer.
Geoff has been involved with the C++ side of Tuscany since May and has
submitted many good patches focusing on SDO C++.
Geoff is active on the SDO specification for C++ and is doing a great job at
the moment raising Jiras documenting
How about adding a scripting utility jar? This would be an additional
jar that contained utility classes relevant to scripting extensions
that they could all refer too, avoiding duplication but not putting
too much implementation in the SPI itself (which I think we all agree
should be avoid
On Nov 8, 2006, at 11:01 PM, Jim Marino wrote:
What I would recommend doing to help Ant users is to create a
utility that can be invoked from an Ant Task, programmatically, or
from the command line which downloads transitive dependencies from
a Maven repository. As an implementation strate
--dry-run is also useful
On Nov 8, 2006, at 9:59 AM, Davanum Srinivas wrote:
-p0
-- dims
On 11/8/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
I have been using Eclipse to apply patches from contributors and I
continue to have problems when patches contain additions. I would
like
to try t
OK. Like Venkat said, I guess you could just have it point to the
name of a file as an attribute on implementation.das right?
Jim
On Nov 8, 2006, at 11:19 PM, Luciano Resende wrote:
You could find it here :
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/
das.service/src
56 matches
Mail list logo
