The term DAS-POJO Service is probably confusing. What I meant is
service implemented in Java that does not require a new component type.
POJService?
--
Kevin
Kevin Williams wrote:
I just committed the nice DAS - POJO service contribution from Luciano
and have a few comments/discussion point
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 is
service implemented in Java that does not require a new componen
Isn't this a component whose implementation is a DAS query (not DAS
itself)? The component offers a service which is defined as
DASService. So, instead of Java code, we are using a query.
I say this because in SCA we don't really have the notion of an
"implementation-less" service and a com
Hi,
From whatever little I understand I would imagine that the config. info is
something that you will inject in as component properties. i.e. have a
property in the DAS ComponentType to inject the source of this config info
(could be a the config filename or a URL that you can open and read th
On Nov 8, 2006, at 10:23 PM, Venkata Krishnan wrote:
Hi,
From whatever little I understand I would imagine that the config.
info is
something that you will inject in as component properties. i.e. have a
property in the DAS ComponentType to inject the source of this
config info
(could be a
On 11/9/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Nov 8, 2006, at 10:23 PM, Venkata Krishnan wrote:
> Hi,
>
> From whatever little I understand I would imagine that the config.
> info is
> something that you will inject in as component properties. i.e. have a
> property in the DAS Component
Yes, Jim comments are more towards what's coming...
What we have today (das/samples/das.service and
das/samples/das.service.client) is more towards integration on the
Application Layer as Venkata mentioned... And that's how I don't know how to
get rid of the configureServices...
More comments in
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 properties? Maybe some can
On Nov 8, 2006, at 10:58 PM, Luciano Resende wrote:
Yes, Jim comments are more towards what's coming...
What we have today (das/samples/das.service and
das/samples/das.service.client) is more towards integration on the
Application Layer as Venkata mentioned... And that's how I don't
know how
You could find it here :
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/das.service/src/main/java/org/apache/tuscany/samples/das/service/DASServiceImpl.java
DAS could use a external file as a configuration file, where commands can be
defined externally (e.g. SQL Queries). Thi
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
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
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
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
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
15 matches
Mail list logo
