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 the config filename or a URL that you can open and read
the
config...).
Instead of injecting a URL couldn't it just inject whatever config
was required? This would save having an extra artifact separate from
the SCDL which would make tooling a bit easier.
If this SCA Service abstraction of DAS is complete, maybe we must
actually
think of projecting it distinctly outside the SCA & DAS
infratructures - as
a component that is ready to use - i.e. can be pulled down and used
in a
service assembly. Makes sense?
I'm not following. I thought this would be a component implementation
type, like implementation.java. The configuration would be specified
in the <component> SCDL entry:
<component>
<implementation.das>
<!-- optional in-line query -->
</implementation.das>
<property name="foo">bar</property>
</component
The extension could be dynamically provisioned by the runtime but the
application SCDL would contain the above.
I did something similar for DataSources over the weekend in the
persistence module.
Jim
- Venkat
On 11/9/06, Luciano Resende <[EMAIL PROTECTED]> 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 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 points:
> >
> > Here is the service API:
> >
> > /**
> > *
> > * @author lresende
> > *
> > */
> > public interface DASService {
> > public void configureService(InputStream
configStream)
> > throws
> > DASServiceException;
> > public DataObject executeCommand(String commandName,
Vector
> > commandArguments) throws DASServiceException;
> > public DataObject execute(String adHocQuery, Vector
> > commandArguments) throws DASServiceException;
> >
> > public void applyChanges(DataObject graphRoot) throws
> > DASServiceException;
> > }
> >
> >
> >
> > We need to find a way to replace the "configureService" API
with an
> > SCA pattern for providing config information.
Yes, this was THE thing I know we need to improve as mentioned on
this
thread :
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10421.html
SCA guys, any suggestions about something already available in
SCA ? Or
maybe an Annotation ?
Amita has solved this with the DAS-container contribution but I
assume
> there is a pattern
> > for POJO services too.
> >
> > We should avoid checked exceptions.
> >
Could you elaborate little bit more here ? Why exactly this ?
> Could the Vector argument list be replaced with a List?
> >
> > I think Apache discourages the use of the @author tag
Sure, it was just a setting in my eclipse IDE, I'll create a patch
removing
that.
As for the other things... I'll look into that and provide a patch
with
the
changes...
>
> > --
> > Kevin
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
