You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Neubauer <pe...@neubauer.se> on 2004/09/26 16:52:01 UTC
Triggers and the deployment model
Hi,
I'm thinking about a facility to provide persistence for components. YOu
could register components by providing their paths, much like the model
hanlder in the HTTP-facility. The question is - how to trigger the
update/delete etc from outside the component? I guess that comes down to
the interceptor things that were discussed earlier. Is there a good way
to do that without introducing new functionality in order to keep
Niclas' resevations in mind?
It could be something like
<component name="test"/>
<component name="persistence-hanlder"
class="my.persistence.jdo.ojb.DefaultHandler">
<configuration>
<mapping path="/test">
<update method="setName"/>
<update methid="setId"/>
</mapping>
</configuration>
This is very simplistic, and the trigger methods could certainly be
exposed via a better syntax, but we have to start somewhere...
Any suggestions?
/peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Triggers and the deployment model
Posted by Andreas Oberhack <de...@softwarefabrik.biz>.
Hi Niclas,
I'm really sharing your concerns here! Hibernate doesn't need any
bytecode enhancing and it's working fine.
Peter - I will be on IRC about at 8:30 pm.
Andreas
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: Sonntag, 26. September 2004 20:25
> To: Avalon Developers List
> Subject: Re: Triggers and the deployment model
>
> On Sunday 26 September 2004 22:52, Peter Neubauer wrote:
> > Hi,
> > I'm thinking about a facility to provide persistence for components.
>
> Before getting carried away, _I_ am VERY negative to persisting
> components. It
> doesn't make sense.
> What DOES make sense is a facility where components can persist
> ValueObjects.
>
> There are some inherent problems with JDO (and possibly Hibernate) in
that
> the
> implementation I know (Kodo), there is bytecode manipulation going on,
and
> with that certain classloading constraints, both during the
compilation as
> well as runtime.
>
> I don't have the time right now to look into it, but I just want to
raise
> a
> finger of warning about trying to persist components.
>
>
> Cheers
> Niclas
> --
> +------//-------------------+
> / http://www.bali.ac /
> / http://niclas.hedhman.org /
> +------//-------------------+
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.762 / Virus Database: 510 - Release Date: 13.09.2004
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 13.09.2004
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Triggers and the deployment model
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 26 September 2004 22:52, Peter Neubauer wrote:
> Hi,
> I'm thinking about a facility to provide persistence for components.
Before getting carried away, _I_ am VERY negative to persisting components. It
doesn't make sense.
What DOES make sense is a facility where components can persist ValueObjects.
There are some inherent problems with JDO (and possibly Hibernate) in that the
implementation I know (Kodo), there is bytecode manipulation going on, and
with that certain classloading constraints, both during the compilation as
well as runtime.
I don't have the time right now to look into it, but I just want to raise a
finger of warning about trying to persist components.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Triggers and the deployment model
Posted by Peter Neubauer <pe...@neubauer.se>.
On Mon, 2004-09-27 at 19:54 +0200, Andreas Oberhack wrote:
> Hi Peter,
> Do you want to persist the component - like CMP EntityBeans - or do you
> want to persist the objects managed by the component?
I've not really looked at that.I was getting the thought when loking at
the db-facility is just firing up the server, so I would not call it a
facility since it doesn't do anything on its own whith the components.
it's more like one of the first containers ready to be included by a
block as a subsystem.
I think it would best in the line of Merlin to persist a component in
order to take the focus away from classes, but then it seems the
component has to expose some information on how to persist itself. Maybe
that could be a bundle of persistence descriptors per component that
describe the mappings etc. as Hibernate/JDO descriptors etc. Do you have
more thoughts on that? Maybe we could have a chat on IRC?
I just feel that this is some base functionality needed. It doesn't have
to be complicated, it should just do IoC for the triggering of the
persistence calls (update, save etc.), much like the HTTP facility that
routes the calls and no more than that.
Cheers
/peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Triggers and the deployment model
Posted by Andreas Oberhack <de...@softwarefabrik.biz>.
Hi Peter,
> -----Original Message-----
> From: Peter Neubauer [mailto:peter@neubauer.se]
> Sent: Sonntag, 26. September 2004 16:52
>
> Hi,
> I'm thinking about a facility to provide persistence for components.
I was already playing arround with persistence and I'm very much
interested in a persistence facility!
But first let me ask what you have in mind exactly:
Do you want to persist the component - like CMP EntityBeans - or do you
want to persist the objects managed by the component?
Andreas
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 13.09.2004
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org