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 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.
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. :)
> 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.
I guess this is something Amita and Luciano are going to put in place soon.
Right now, what has been done is an SCA Application Service abstraction of
DAS. Maybe Luciano should correct me if I have understood this all wrong.
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]
