You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Essl <ch...@yahoo.de> on 2003/09/24 21:20:41 UTC
Schema instead of BuilderFactory?
I am realy found of the idea of using the BuilderFactory.
What I suggest is that you have like for configuration-points also the
possibility to define a schema(-processing) for the most important
'configuration' - the initial setup of a ServiceImplementation.
Therefore I think a tag lets say <service-implementation
class="implementingClass"> which contains a schema-processing definition
would be useful. The <create-instance> tag could than contain the xml for
the schema. When the rules of the schema are processed, the
CoreImplementation would be on top of the stack. (May be it could also be
enforced that when for a class such a schema is given it can only be
created with <create-instance>).
Through the BuilderFactory which does this currently rather a 'property-
scripting' aproach is given. I know the BuilderFactory also has the point-
id-attribute. However using this means more typing for the user and the
service-implementor and there is a difference between service-construction
configuration and contributed configuration (similar to java constructors
and properties).
I think the suggested approach has also other advantages. It would make the
configuration of the Service easier and more clear than through the
BuilderFactory. It would relieve the service of some initial state-
checking. It would also provide better documentation about what are
initialization (constructor-like) properties and 'normal' properties.
Finally it would also make the whole 'BuilderFactory-aproach' more
powerful. (Future stuff: I was thinking of the late module loading and for
this it would be very useful - because there would be a distinction between
initial configuration and contributed configuration.)
For my problem (you know a clean-shutdown ;-)) it would certainly help.
Currently I try to define the dependencies in a configuration-point (pro:
the user can see the dependencies) but I think it should be bound to the
implementation of the Service, however also there I have my problems (the
Service does not know its id nor of its dependent services). I also think
for other such 'in-between' things (like events) such a tag would help.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Re: Schema instead of BuilderFactory?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
I don't think so.
Christian Essl wrote:
> On Wed, 24 Sep 2003 15:26:06 -0400, Harish Krishnaswamy
> <hk...@comcast.net> wrote:
>
>> In case any of you missed it.
>>
>> Christian Essl wrote:
>>
>
> Sorry but have I missed anything?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [HiveMind] Re: Schema instead of BuilderFactory?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
I don't think so.
Christian Essl wrote:
> On Wed, 24 Sep 2003 15:26:06 -0400, Harish Krishnaswamy
> <hk...@comcast.net> wrote:
>
>> In case any of you missed it.
>>
>> Christian Essl wrote:
>>
>
> Sorry but have I missed anything?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Re: Schema instead of BuilderFactory?
Posted by Christian Essl <ch...@yahoo.de>.
On Wed, 24 Sep 2003 15:26:06 -0400, Harish Krishnaswamy
<hk...@comcast.net> wrote:
> In case any of you missed it.
>
> Christian Essl wrote:
>
Sorry but have I missed anything?
Re: [HiveMind] Re: Schema instead of BuilderFactory?
Posted by Christian Essl <ch...@yahoo.de>.
On Wed, 24 Sep 2003 15:26:06 -0400, Harish Krishnaswamy
<hk...@comcast.net> wrote:
> In case any of you missed it.
>
> Christian Essl wrote:
>
Sorry but have I missed anything?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[HiveMind] Re: Schema instead of BuilderFactory?
Posted by Christian Essl <ch...@yahoo.de>.
I tried to implement it and it seems easier (and smaller) than I thought.
Attached is the patch however there are some unnice typecasts, no checking
of existence in the RegistryBuilder (I did not want to change to much in
the core) and there is only a small test (all maven tests run fine).
I did not - like I suggested - create a new tag instead I use the standard
<configuration> tag for the schema definition. I extended the <create-
instance> tag to include the new (optional) attribute configuration-id and
to allow xml-parameters under it.
If the configuration-id attribute is present the
CreateClassServiceConstructor will first get the schema (here is the dirty
casting), than create with the class-attribute (like normal) the
implementation, than pushes it on the processor and than processes the xml-
parameters and finally returns the result.
For an example of how to use it see the
hivemind.test.service.CreateInstanceContri.xml (hivemodule) file.
On Wed, 24 Sep 2003 17:44:41 -0400, Howard M. Lewis Ship
<hl...@comcast.net> wrote:
> I didn't see this earlier.
>
> It's another interesting idea; Basically, a more powerful version of
> BuilderFactory that supports a
> stack-oriented approach to constructing the service, similar to how
> contributions are processed into
> Java objects. I see this as something that could sit beside
> BuilderFactory unless it could be made
> as easy to use as BuilderFactory.
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
>> -----Original Message-----
>> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] Sent:
>> Wednesday, September 24, 2003 3:26 PM
>> To: Jakarta Commons Developers List
>> Subject: [HiveMind] Re: Schema instead of BuilderFactory?
>>
>>
>> In case any of you missed it.
>>
>> Christian Essl wrote:
>>
>> > I am realy found of the idea of using the BuilderFactory.
>> >
>> > What I suggest is that you have like for configuration-points also the
>> > possibility to define a schema(-processing) for the most important >
>> 'configuration' - the initial setup of a ServiceImplementation.
>> >
>> > Therefore I think a tag lets say <service-implementation
>> > class="implementingClass"> which contains a schema-processing >
>> definition would be useful. The <create-instance> tag could than >
>> contain the xml for the schema. When the rules of the schema are >
>> processed, the CoreImplementation would be on top of the stack. (May >
>> be it could also be enforced that when for a class such a schema is >
>> given it can only be created with <create-instance>).
>> >
>> > Through the BuilderFactory which does this currently rather a
>> > 'property-scripting' aproach is given. I know the BuilderFactory also
>> > has the point-id-attribute. However using this means more typing for >
>> the user and the service-implementor and there is a difference between >
>> service-construction configuration and contributed configuration >
>> (similar to java constructors and properties).
>> >
>> > I think the suggested approach has also other advantages. It would
>> > make the configuration of the Service easier and more clear than >
>> through the BuilderFactory. It would relieve the service of some >
>> initial state-checking. It would also provide better documentation >
>> about what are initialization (constructor-like) properties and >
>> 'normal' properties. Finally it would also make the whole >
>> 'BuilderFactory-aproach' more powerful. (Future stuff: I was thinking >
>> of the late module loading and for this it would be very useful - >
>> because there would be a distinction between initial configuration and >
>> contributed configuration.)
>> >
>> > For my problem (you know a clean-shutdown ;-)) it would certainly
>> > help. Currently I try to define the dependencies in a > configuration-
>> point (pro: the user can see the dependencies) but I > think it should
>> be bound to the implementation of the Service, however > also there I
>> have my problems (the Service does not know its id nor of > its
>> dependent services). I also think for other such 'in-between' > things
>> (like events) such a tag would help.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
RE: [HiveMind] Re: Schema instead of BuilderFactory?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I didn't see this earlier.
It's another interesting idea; Basically, a more powerful version of BuilderFactory that supports a
stack-oriented approach to constructing the service, similar to how contributions are processed into
Java objects. I see this as something that could sit beside BuilderFactory unless it could be made
as easy to use as BuilderFactory.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
> Sent: Wednesday, September 24, 2003 3:26 PM
> To: Jakarta Commons Developers List
> Subject: [HiveMind] Re: Schema instead of BuilderFactory?
>
>
> In case any of you missed it.
>
> Christian Essl wrote:
>
> > I am realy found of the idea of using the BuilderFactory.
> >
> > What I suggest is that you have like for
> configuration-points also the
> > possibility to define a schema(-processing) for the most important
> > 'configuration' - the initial setup of a ServiceImplementation.
> >
> > Therefore I think a tag lets say <service-implementation
> > class="implementingClass"> which contains a schema-processing
> > definition would be useful. The <create-instance> tag could than
> > contain the xml for the schema. When the rules of the schema are
> > processed, the CoreImplementation would be on top of the
> stack. (May
> > be it could also be enforced that when for a class such a schema is
> > given it can only be created with <create-instance>).
> >
> > Through the BuilderFactory which does this currently rather a
> > 'property- scripting' aproach is given. I know the
> BuilderFactory also
> > has the point- id-attribute. However using this means more
> typing for
> > the user and the service-implementor and there is a
> difference between
> > service-construction configuration and contributed configuration
> > (similar to java constructors and properties).
> >
> > I think the suggested approach has also other advantages. It would
> > make the configuration of the Service easier and more clear than
> > through the BuilderFactory. It would relieve the service of some
> > initial state- checking. It would also provide better documentation
> > about what are initialization (constructor-like) properties and
> > 'normal' properties. Finally it would also make the whole
> > 'BuilderFactory-aproach' more powerful. (Future stuff: I
> was thinking
> > of the late module loading and for this it would be very useful -
> > because there would be a distinction between initial
> configuration and
> > contributed configuration.)
> >
> > For my problem (you know a clean-shutdown ;-)) it would certainly
> > help. Currently I try to define the dependencies in a
> > configuration-point (pro: the user can see the dependencies) but I
> > think it should be bound to the implementation of the
> Service, however
> > also there I have my problems (the Service does not know
> its id nor of
> > its dependent services). I also think for other such 'in-between'
> > things (like events) such a tag would help.
> >
> >
> >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
RE: [HiveMind] Re: Schema instead of BuilderFactory?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I didn't see this earlier.
It's another interesting idea; Basically, a more powerful version of BuilderFactory that supports a
stack-oriented approach to constructing the service, similar to how contributions are processed into
Java objects. I see this as something that could sit beside BuilderFactory unless it could be made
as easy to use as BuilderFactory.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
> Sent: Wednesday, September 24, 2003 3:26 PM
> To: Jakarta Commons Developers List
> Subject: [HiveMind] Re: Schema instead of BuilderFactory?
>
>
> In case any of you missed it.
>
> Christian Essl wrote:
>
> > I am realy found of the idea of using the BuilderFactory.
> >
> > What I suggest is that you have like for
> configuration-points also the
> > possibility to define a schema(-processing) for the most important
> > 'configuration' - the initial setup of a ServiceImplementation.
> >
> > Therefore I think a tag lets say <service-implementation
> > class="implementingClass"> which contains a schema-processing
> > definition would be useful. The <create-instance> tag could than
> > contain the xml for the schema. When the rules of the schema are
> > processed, the CoreImplementation would be on top of the
> stack. (May
> > be it could also be enforced that when for a class such a schema is
> > given it can only be created with <create-instance>).
> >
> > Through the BuilderFactory which does this currently rather a
> > 'property- scripting' aproach is given. I know the
> BuilderFactory also
> > has the point- id-attribute. However using this means more
> typing for
> > the user and the service-implementor and there is a
> difference between
> > service-construction configuration and contributed configuration
> > (similar to java constructors and properties).
> >
> > I think the suggested approach has also other advantages. It would
> > make the configuration of the Service easier and more clear than
> > through the BuilderFactory. It would relieve the service of some
> > initial state- checking. It would also provide better documentation
> > about what are initialization (constructor-like) properties and
> > 'normal' properties. Finally it would also make the whole
> > 'BuilderFactory-aproach' more powerful. (Future stuff: I
> was thinking
> > of the late module loading and for this it would be very useful -
> > because there would be a distinction between initial
> configuration and
> > contributed configuration.)
> >
> > For my problem (you know a clean-shutdown ;-)) it would certainly
> > help. Currently I try to define the dependencies in a
> > configuration-point (pro: the user can see the dependencies) but I
> > think it should be bound to the implementation of the
> Service, however
> > also there I have my problems (the Service does not know
> its id nor of
> > its dependent services). I also think for other such 'in-between'
> > things (like events) such a tag would help.
> >
> >
> >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[HiveMind] Re: Schema instead of BuilderFactory?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
In case any of you missed it.
Christian Essl wrote:
> I am realy found of the idea of using the BuilderFactory.
>
> What I suggest is that you have like for configuration-points also the
> possibility to define a schema(-processing) for the most important
> 'configuration' - the initial setup of a ServiceImplementation.
>
> Therefore I think a tag lets say <service-implementation
> class="implementingClass"> which contains a schema-processing
> definition would be useful. The <create-instance> tag could than
> contain the xml for the schema. When the rules of the schema are
> processed, the CoreImplementation would be on top of the stack. (May
> be it could also be enforced that when for a class such a schema is
> given it can only be created with <create-instance>).
>
> Through the BuilderFactory which does this currently rather a
> 'property- scripting' aproach is given. I know the BuilderFactory also
> has the point- id-attribute. However using this means more typing for
> the user and the service-implementor and there is a difference between
> service-construction configuration and contributed configuration
> (similar to java constructors and properties).
>
> I think the suggested approach has also other advantages. It would
> make the configuration of the Service easier and more clear than
> through the BuilderFactory. It would relieve the service of some
> initial state- checking. It would also provide better documentation
> about what are initialization (constructor-like) properties and
> 'normal' properties. Finally it would also make the whole
> 'BuilderFactory-aproach' more powerful. (Future stuff: I was thinking
> of the late module loading and for this it would be very useful -
> because there would be a distinction between initial configuration and
> contributed configuration.)
>
> For my problem (you know a clean-shutdown ;-)) it would certainly
> help. Currently I try to define the dependencies in a
> configuration-point (pro: the user can see the dependencies) but I
> think it should be bound to the implementation of the Service, however
> also there I have my problems (the Service does not know its id nor of
> its dependent services). I also think for other such 'in-between'
> things (like events) such a tag would help.
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[HiveMind] Re: Schema instead of BuilderFactory?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
In case any of you missed it.
Christian Essl wrote:
> I am realy found of the idea of using the BuilderFactory.
>
> What I suggest is that you have like for configuration-points also the
> possibility to define a schema(-processing) for the most important
> 'configuration' - the initial setup of a ServiceImplementation.
>
> Therefore I think a tag lets say <service-implementation
> class="implementingClass"> which contains a schema-processing
> definition would be useful. The <create-instance> tag could than
> contain the xml for the schema. When the rules of the schema are
> processed, the CoreImplementation would be on top of the stack. (May
> be it could also be enforced that when for a class such a schema is
> given it can only be created with <create-instance>).
>
> Through the BuilderFactory which does this currently rather a
> 'property- scripting' aproach is given. I know the BuilderFactory also
> has the point- id-attribute. However using this means more typing for
> the user and the service-implementor and there is a difference between
> service-construction configuration and contributed configuration
> (similar to java constructors and properties).
>
> I think the suggested approach has also other advantages. It would
> make the configuration of the Service easier and more clear than
> through the BuilderFactory. It would relieve the service of some
> initial state- checking. It would also provide better documentation
> about what are initialization (constructor-like) properties and
> 'normal' properties. Finally it would also make the whole
> 'BuilderFactory-aproach' more powerful. (Future stuff: I was thinking
> of the late module loading and for this it would be very useful -
> because there would be a distinction between initial configuration and
> contributed configuration.)
>
> For my problem (you know a clean-shutdown ;-)) it would certainly
> help. Currently I try to define the dependencies in a
> configuration-point (pro: the user can see the dependencies) but I
> think it should be bound to the implementation of the Service, however
> also there I have my problems (the Service does not know its id nor of
> its dependent services). I also think for other such 'in-between'
> things (like events) such a tag would help.
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>