You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Alexis Agahi <al...@users.sf.net> on 2003/11/01 10:14:47 UTC
[RT] Component Persistence
Hi,
As I'm now using hibernate on current biz project, some ideas come to my brain
about how could have transparent persistence with avalon compenent.
Based on hibernate (JDO?) approach that all object could be mapped in database
with get/setter method to populate the object field from db (or persist state
to db), any component could support such feature.
The main problem would be how manage compenent persistance.
I have a suggestion: via a Persitence interface that could be added in
component lifecycle.
such as
public interface Persistence
{
public void persitence( PersistenceManager persistenceManager );
}
PersistenceManager class would manage object persistance/lookup(load) and
transaction provider.
For exemple:
Let say we have a persistant component called "Foo"
/**
* @avalon.component version="1.0" name="Foo" lifestyle="transient"
* @avalon.service type="Foo"
*/
public class Foo implements (AvalonFrameWorksStuff)
{
Long m_primaryKey;
String m_value;
....
public void setId( Long id )
{
m_primaryKey = id;
}
public Long getId()
{
return m_primaryKey;
}
public void setValue( String value )
{
m_value = value;
}
public String getValue()
{
return m_value;
}
}
We suppose that this object is mapped in db using persistence mapping
descriptor (such as hibernate or jdo) file.
Now we have a compenent Bar depending on Foo
/**
* @avalon.component version="1.0" name="Bar" lifestyle="transient"
* @avalon.service type="Bar"
*/
public class Bar implements
Servicealbe, Persistence
{
String m_serviceManager;
....
/**
* @avalon.dependency type="Foo:1.0" key="Foo"
*/
public void service( ServiceManager serviceManager)
throws ServiceException
{
m_serviceManager = serviceManager;
}
public void persitence( PersistanceManager persistanceManager ){
PrimaryLookupCriteria criteria = new PrimaryLookupCriteria( new Long( 1 ) );
Foo foo = persistanceManager.lookup( m_serviceManager, "Foo", criteria );
getLogger().info( foo.getValue() );
Transaction = null;
try{
tx = persistanceManager.getTransaction();
foo.setValue( "Dude!" );
tx.save( foo );
tx.commit();
}
catch( TransactionExcetion te )
{
tx.rollback();
}
finally
{
if( tx != null ) tx.close();
}
}
}
Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Leo Simons <le...@apache.org>.
Alexis Agahi wrote:
> As I'm now using hibernate on current biz project, some ideas come to my brain
> about how could have transparent persistence with avalon compenent.
just another opinion:
You do not want persistence of avalon components. You need to persist
data. Data != component.
The component should just be logic, which is already persisted in the
form of the classfile. The integral part of the component that is not in
its classfile is its configuration (and metadata). Those are already
persistent (all those xml files).
This abstraction seperation has been shown to work well (IMNSHO, best).
The merging of your component container and your data container is a bad
idea. Rather, your data container is a service provided to other components.
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Alexis Agahi <al...@users.sf.net>.
On Saturday 01 November 2003 16:35, Peter Courcoux wrote:
> Alex,
>
> O/T a bit for this thread but possibly of interest.
>
> If you're not already aware of it, Eric Pugh wrote a hibernate component
> for ECM which, I believe, is on the Hibernate site.
>
> Regards,
for reader information
http://www.hibernate.org/123.html
http://jakarta.apache.org/turbine/fulcrum/fulcrum-security/apidocs/org/apache/fulcrum/security/spi/hibernate/simple/BaseHibernateManager.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Component Persistence
Posted by Eric Pugh <ep...@upstate.com>.
Also, related to what you are looking for, the Xingu project has a
Persistence component: http://xingu.sf.net that persists objects via both
OJB and Hibernate depending on what you pick. It leverages the Hibernate
component to handle starting up hibernate. If you write to it, you can
provide other backends quite easily.
Part of the reason I was involved in the project was to validate the concept
that with a good API you could have multiple backend providers.
Eric
> -----Original Message-----
> From: Peter Courcoux [mailto:peter@courcoux.biz]
> Sent: Saturday, November 01, 2003 4:35 PM
> To: Avalon Dev List
> Subject: Re: [RT] Component Persistence
>
>
> Alex,
>
> O/T a bit for this thread but possibly of interest.
>
> If you're not already aware of it, Eric Pugh wrote a
> hibernate component
> for ECM which, I believe, is on the Hibernate site.
>
> Regards,
>
> Peter
>
> On Sat, 2003-11-01 at 09:14, Alexis Agahi wrote:
> > Hi,
> >
> > As I'm now using hibernate on current biz project, some
> ideas come to my brain
> > about how could have transparent persistence with avalon compenent.
> >
> > Based on hibernate (JDO?) approach that all object could be
> mapped in database
> > with get/setter method to populate the object field from db
> (or persist state
> > to db), any component could support such feature.
> >
> > The main problem would be how manage compenent persistance.
> > I have a suggestion: via a Persitence interface that could
> be added in
> > component lifecycle.
> >
> > such as
> > public interface Persistence
> > {
> > public void persitence( PersistenceManager persistenceManager );
> > }
> >
> > PersistenceManager class would manage object
> persistance/lookup(load) and
> > transaction provider.
> >
> >
> >
> > For exemple:
> >
> > Let say we have a persistant component called "Foo"
> >
> > /**
> > * @avalon.component version="1.0" name="Foo" lifestyle="transient"
> > * @avalon.service type="Foo"
> > */
> > public class Foo implements (AvalonFrameWorksStuff)
> > {
> > Long m_primaryKey;
> > String m_value;
> > ....
> >
> > public void setId( Long id )
> > {
> > m_primaryKey = id;
> > }
> > public Long getId()
> > {
> > return m_primaryKey;
> > }
> >
> >
> > public void setValue( String value )
> > {
> > m_value = value;
> > }
> > public String getValue()
> > {
> > return m_value;
> > }
> > }
> >
> > We suppose that this object is mapped in db using
> persistence mapping
> > descriptor (such as hibernate or jdo) file.
> >
> >
> > Now we have a compenent Bar depending on Foo
> >
> > /**
> > * @avalon.component version="1.0" name="Bar" lifestyle="transient"
> > * @avalon.service type="Bar"
> > */
> > public class Bar implements
> > Servicealbe, Persistence
> > {
> > String m_serviceManager;
> > ....
> > /**
> > * @avalon.dependency type="Foo:1.0" key="Foo"
> > */
> > public void service( ServiceManager serviceManager)
> > throws ServiceException
> > {
> > m_serviceManager = serviceManager;
> > }
> >
> >
> >
> > public void persitence( PersistanceManager persistanceManager ){
> >
> > PrimaryLookupCriteria criteria = new
> PrimaryLookupCriteria( new Long( 1 ) );
> > Foo foo = persistanceManager.lookup(
> m_serviceManager, "Foo", criteria );
> >
> > getLogger().info( foo.getValue() );
> >
> > Transaction = null;
> > try{
> > tx = persistanceManager.getTransaction();
> > foo.setValue( "Dude!" );
> > tx.save( foo );
> > tx.commit();
> > }
> > catch( TransactionExcetion te )
> > {
> > tx.rollback();
> > }
> > finally
> > {
> > if( tx != null ) tx.close();
> > }
> >
> >
> > }
> >
> > }
> >
> >
> >
> >
> > Cheers
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> > For additional commands, e-mail: dev-help@avalon.apache.org
> --
> Peter Courcoux <pe...@courcoux.biz>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Peter Courcoux <pe...@courcoux.biz>.
Alex,
O/T a bit for this thread but possibly of interest.
If you're not already aware of it, Eric Pugh wrote a hibernate component
for ECM which, I believe, is on the Hibernate site.
Regards,
Peter
On Sat, 2003-11-01 at 09:14, Alexis Agahi wrote:
> Hi,
>
> As I'm now using hibernate on current biz project, some ideas come to my brain
> about how could have transparent persistence with avalon compenent.
>
> Based on hibernate (JDO?) approach that all object could be mapped in database
> with get/setter method to populate the object field from db (or persist state
> to db), any component could support such feature.
>
> The main problem would be how manage compenent persistance.
> I have a suggestion: via a Persitence interface that could be added in
> component lifecycle.
>
> such as
> public interface Persistence
> {
> public void persitence( PersistenceManager persistenceManager );
> }
>
> PersistenceManager class would manage object persistance/lookup(load) and
> transaction provider.
>
>
>
> For exemple:
>
> Let say we have a persistant component called "Foo"
>
> /**
> * @avalon.component version="1.0" name="Foo" lifestyle="transient"
> * @avalon.service type="Foo"
> */
> public class Foo implements (AvalonFrameWorksStuff)
> {
> Long m_primaryKey;
> String m_value;
> ....
>
> public void setId( Long id )
> {
> m_primaryKey = id;
> }
> public Long getId()
> {
> return m_primaryKey;
> }
>
>
> public void setValue( String value )
> {
> m_value = value;
> }
> public String getValue()
> {
> return m_value;
> }
> }
>
> We suppose that this object is mapped in db using persistence mapping
> descriptor (such as hibernate or jdo) file.
>
>
> Now we have a compenent Bar depending on Foo
>
> /**
> * @avalon.component version="1.0" name="Bar" lifestyle="transient"
> * @avalon.service type="Bar"
> */
> public class Bar implements
> Servicealbe, Persistence
> {
> String m_serviceManager;
> ....
> /**
> * @avalon.dependency type="Foo:1.0" key="Foo"
> */
> public void service( ServiceManager serviceManager)
> throws ServiceException
> {
> m_serviceManager = serviceManager;
> }
>
>
>
> public void persitence( PersistanceManager persistanceManager ){
>
> PrimaryLookupCriteria criteria = new PrimaryLookupCriteria( new Long( 1 ) );
> Foo foo = persistanceManager.lookup( m_serviceManager, "Foo", criteria );
>
> getLogger().info( foo.getValue() );
>
> Transaction = null;
> try{
> tx = persistanceManager.getTransaction();
> foo.setValue( "Dude!" );
> tx.save( foo );
> tx.commit();
> }
> catch( TransactionExcetion te )
> {
> tx.rollback();
> }
> finally
> {
> if( tx != null ) tx.close();
> }
>
>
> }
>
> }
>
>
>
>
> Cheers
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
--
Peter Courcoux <pe...@courcoux.biz>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Stephen McConnell <mc...@apache.org>.
Alexis Agahi wrote:
>On Sunday 02 November 2003 14:05, Stephen McConnell wrote:
>
><snip/>
>
>
>
>>Mapping from MyStateValueType (an interface) to a home is not the same
>>as service to provider resolution. Instead, what you want to locate is a
>>component that implements a home interface for the MyStateValueType -
>>e.g. MyStateValueTypeHome is the home interface and
>>MyStateValueTypeHomeProvider is the component implementation that
>>provides creation, retrival and destruction of instance of
>>MyStateValueType.
>>
>>At the meta-data level would would need something like:
>>
>> <component class="MyDemoComponent" name="whatever">
>> <identity>
>> <key>12345</key>
>> </identity>
>> </component>
>>
>>The container on creation of an identifiable component resolves the home
>>factory (an implicit lifecycle dependency) and if the meta-data declares
>>a key, then a persistent value is retrieved and supplied to the
>>component via a context entry. If no identity is supplied, a new state
>>value is created and supplied.
>>
>>Any thoughts?
>>
>>
>
>
>I'm not sure to understand clearly your approach.
>Tell me if I'm wrong
>
>You suggest 3 parts
>1/ compenent: implementing home interface (2)
>2/ home: interface that define persisted data
>3/ provider: impl that provides custom finder for home interface of the
>component (1)
>
Close.
>
>but I dont get clearly identity/home purpose.
>
I'll explain below.
>Should home define method that
>will be used by provider to establish persitence? (if yes, then this sounds
>nice ,))
>
Here is a move detailed breakdown of the terms I'm using:
* identifiable component - an instance of a identifiable component type
* identifiable component type - a type that includes an <indentifiable>
elements declaring a home interface
* home - a component implementing a home interface
* home interface - defintion of storage value creation, query
and destruction operations
* home component - a component that implements the home interface
and handles storage value creation query and destruction
using some persistence solution
So for example, lets imagine we have something called a User and that
we maintain multiple users. From this we would need:
Interfaces:
* User - an service interface
* UserStorage - an interface defining operation on a user storage
value instance
* UserHome - the home interface
Classes:
* DefaultUser - an identifiable component
* DefaultUserStorage - a class implementing UserStorage using a
particular persistence solution
* DefaultUserHome - implementation of the UserHome
A container on deploying a identifiable component would locate and
deploy a component implementing the UserHome service, get an instance of
UserStorage from the home and add this to the identifiable
components context.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merlin Component Service for Turbine
Posted by Stephen McConnell <mc...@apache.org>.
Eric Pugh wrote:
>Hi all,
>
>I have committed the first cut of the MerlinComponentService [1] by Peter
>Courcoux and added in a working unit test [2]. Here are my issues at this
>point with understanding Merlin.
>
>1) If you look at the unit test, I can run the HelloComponent from the Maven
>tutorial fine. In fact, by adding it to the Turbine repo, Merlin nicely
>downloads and installs the jar! Very handy.
>
>However... I want to master all my jar dependencies in my project.xml file.
>That way, run I build the maven war task to build my WAR file to deploy, all
>my dependencies are included, versus this dynamic downloading from the
>block.xml files. However, there doesn't seem to be built in any way to load
>all my jars from the WEB-INF/lib directory. The DefaultFileRepository could
>be pointed at a web-inf/lib directory, but it wants to load things as
>WEB-INF/lib/{groupId}/jar/{artifactId}. However, I could replace it with
>one that resolved them directly.
>
If you want to have local copies of jar files (merlin system and app) then
we should be populating the WEB-INF/ with both a system repository and an
application repository. Resolving against a flat /lib is not recommended
as jar names are scoped relative to a group and you quickly end up with
name conflicts in a flat structure.
>But, the other problem is that I can't seem to pass in my own classloader.
>I do most of my development in Eclipse, and one of the things I am used to
>with ECM is just including my jar in my classpath and having everything
>work. But, because Merlin is using it's own classloader, it doesn't pick up
>the Eclipse classpath, therefore it has to download and install it someplace
>to use it. (I think...)
>
In Merlin there is a strict isolation between container classes and
component
classes. ECM does not have this notion. I don't know what would be
required
to deal with this in Eclipse - but there are others here who use Eclipse and
Merlin who can probably help.
>2) If you look in the MerlinCompoenentServiceTest the second unit test won't
>run. I am not sure how to load the TestComponent when it is part of the
>same code. Or, does it have to be a seperate project? I am used to writing
>components that are just part of my application classpath and source tree,
>not loaded from seperate jars.
>
I took a quick look at the build but was unable to run maven. Looks
like your assuming RC1 and I'm using beta-10 (RC1 has bugs related to
doc generation) - so the following comments are related to just looking.
First off - I strongly recommend - in fact I *very* *very* strongly
recommend - that you do *not* include all the merlin system jar files in
you project.xml. An embedded merlin jar such as merlin-unit-3.2.2
handles all of this automatically - you simply do not need to expose of
this stuff - and in fact - your asking for problems within the maven
classloader. What you should be doing is including just one application
embeddor jar (e.g. turbine-merlin-1.x.jar). That jar would contain the
kernel bootstrap which in turn builds a classloader heirachy that is
seperate and independent of the maven classloader.
Once you have that in place - you simply provide component deployment
dirtectives to the kernel it establishes. Those directives can be
directories, jar files, url to remotely located deployment descriptors.
It is in the deployment descriptor that you reference something like
TestComponent.
Concerning the test case failure - can you post the error report?
>3) Integrating ECM components. I am looking at the various changes, and to
>use a component that was compatible with ECM in Merlin requires some
>signficant changes. I guess the big issue is the need for the .xinfo file.
>If I have an existing jarred up ECM component that I want to use in Merlin.
>Can I just write by hand the .xinfo file?
>
Yes.
>How do I get it to load? Just
>add into my /classes directory the full path to the class name and put the
>.xinfo there?
>
Yes - if - and only if - the directory containing the xinfo file is
included in the classpath declaration for a container in you deployment
descriptor (block.xml).
>So, the .class file is loaded from the jar, but the .xinfo
>loads form the /classes directory?
>
Yep - its possible - providing your container classpath contains both.
>
>4) Running unit tests inside of Eclipse. I discovered one issue, which is
>that the AbstractMerlinTestCase expects a System property like this in the
>getBaseDirectory method. I'm guessing because it is oriented towards Maven:
>
> String basedir = System.getProperty( "basedir" );
>
>However, in Eclipse this isn't provided, therefore it fails with an NPE.
>Now, I think the AbstractMerlinTestCase could do something like:
> if(basedir==null){
> basedir = new File(".").toString()
> }
>
> I think it is crucial to be able to run unit tests via the IDE debugger.
>
It should be possible to update the abstract unit test form this sort of
context.
>
>
>Overall, I can definitly see the niceness of having a single Merlin
>repository on a machine for multiple applications. However, I think for
>many of the Turbine users, they are going to want to instead have all their
>jars included in the war file, or at least, have the option. I like the
>repository as it'll make my WAR files much smaller and look forward to when
>I can set up a single repo to load from.
>
Suggestion for now is to leverage the shared repository - get things
working and validated (it is simply simpler). Next step is to build a
war file and aggregating the jar files into system and application
repositories in the war file - and that can be done with a bit of jelly
in the maven.xml.
Last comment - we are in the process of improving the kernel embedding
side of things and will be refactoring all of the embedded scenarios to
use a common defaults and parameterization model. This will make things
a lot simpler - in fact the TurbineMerlinComponentService will probably
shrink down to only a few lines of code - and as a result - the stuff
such classloader establishment will be taken care of automatically.
Cheers, Steve.
>
>Eric Pugh
>
>
>[1]
>http://cvs.apache.org/viewcvs/jakarta-turbine-2/src/java/org/apache/turbine/
>services/avaloncomponent/TurbineMerlinComponentService.java
>[2]
>http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-2/src/test/org/apache/turb
>ine/services/avaloncomponent/MerlinComponentServiceTest.java
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Merlin Component Service for Turbine
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I have committed the first cut of the MerlinComponentService [1] by Peter
Courcoux and added in a working unit test [2]. Here are my issues at this
point with understanding Merlin.
1) If you look at the unit test, I can run the HelloComponent from the Maven
tutorial fine. In fact, by adding it to the Turbine repo, Merlin nicely
downloads and installs the jar! Very handy.
However... I want to master all my jar dependencies in my project.xml file.
That way, run I build the maven war task to build my WAR file to deploy, all
my dependencies are included, versus this dynamic downloading from the
block.xml files. However, there doesn't seem to be built in any way to load
all my jars from the WEB-INF/lib directory. The DefaultFileRepository could
be pointed at a web-inf/lib directory, but it wants to load things as
WEB-INF/lib/{groupId}/jar/{artifactId}. However, I could replace it with
one that resolved them directly.
But, the other problem is that I can't seem to pass in my own classloader.
I do most of my development in Eclipse, and one of the things I am used to
with ECM is just including my jar in my classpath and having everything
work. But, because Merlin is using it's own classloader, it doesn't pick up
the Eclipse classpath, therefore it has to download and install it someplace
to use it. (I think...)
2) If you look in the MerlinCompoenentServiceTest the second unit test won't
run. I am not sure how to load the TestComponent when it is part of the
same code. Or, does it have to be a seperate project? I am used to writing
components that are just part of my application classpath and source tree,
not loaded from seperate jars.
3) Integrating ECM components. I am looking at the various changes, and to
use a component that was compatible with ECM in Merlin requires some
signficant changes. I guess the big issue is the need for the .xinfo file.
If I have an existing jarred up ECM component that I want to use in Merlin.
Can I just write by hand the .xinfo file? How do I get it to load? Just
add into my /classes directory the full path to the class name and put the
.xinfo there? So, the .class file is loaded from the jar, but the .xinfo
loads form the /classes directory?
4) Running unit tests inside of Eclipse. I discovered one issue, which is
that the AbstractMerlinTestCase expects a System property like this in the
getBaseDirectory method. I'm guessing because it is oriented towards Maven:
String basedir = System.getProperty( "basedir" );
However, in Eclipse this isn't provided, therefore it fails with an NPE.
Now, I think the AbstractMerlinTestCase could do something like:
if(basedir==null){
basedir = new File(".").toString()
}
I think it is crucial to be able to run unit tests via the IDE debugger.
Overall, I can definitly see the niceness of having a single Merlin
repository on a machine for multiple applications. However, I think for
many of the Turbine users, they are going to want to instead have all their
jars included in the war file, or at least, have the option. I like the
repository as it'll make my WAR files much smaller and look forward to when
I can set up a single repo to load from.
Eric Pugh
[1]
http://cvs.apache.org/viewcvs/jakarta-turbine-2/src/java/org/apache/turbine/
services/avaloncomponent/TurbineMerlinComponentService.java
[2]
http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-2/src/test/org/apache/turb
ine/services/avaloncomponent/MerlinComponentServiceTest.java
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Alexis Agahi <al...@users.sf.net>.
On Sunday 02 November 2003 14:05, Stephen McConnell wrote:
<snip/>
> Mapping from MyStateValueType (an interface) to a home is not the same
> as service to provider resolution. Instead, what you want to locate is a
> component that implements a home interface for the MyStateValueType -
> e.g. MyStateValueTypeHome is the home interface and
> MyStateValueTypeHomeProvider is the component implementation that
> provides creation, retrival and destruction of instance of
> MyStateValueType.
>
> At the meta-data level would would need something like:
>
> <component class="MyDemoComponent" name="whatever">
> <identity>
> <key>12345</key>
> </identity>
> </component>
>
> The container on creation of an identifiable component resolves the home
> factory (an implicit lifecycle dependency) and if the meta-data declares
> a key, then a persistent value is retrieved and supplied to the
> component via a context entry. If no identity is supplied, a new state
> value is created and supplied.
>
> Any thoughts?
I'm not sure to understand clearly your approach.
Tell me if I'm wrong
You suggest 3 parts
1/ compenent: implementing home interface (2)
2/ home: interface that define persisted data
3/ provider: impl that provides custom finder for home interface of the
component (1)
but I dont get clearly identity/home purpose. Should home define method that
will be used by provider to establish persitence? (if yes, then this sounds
nice ,))
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Stephen McConnell <mc...@apache.org>.
Alexis Agahi wrote:
> ... I'm trying to see beyond this, to maybe get some
>
>magical model, maybe inside component manager or Merlin Extension.
>
>
I think the elegant approach is for a container to provide support for
identity
at the meta-info and meta-data layers, combined with a common set of
patterns
concerning home interfaces.
1. meta-info tag declaring type as identifiable + storage value type
2. where (1) implies a storage value type home
3. where (2) implies a storage value type home implementation
4. where (1) implies a standard meta-data key description
5. from which automated state value supply is possible
E.g.
<type>
<info>
<name>demo</name>
<lifestyle>singleton</lifestyle>
<identity type="MyStateValueType"/>
</info>
</type>
Mapping from MyStateValueType (an interface) to a home is not the same
as service to provider resolution. Instead, what you want to locate is a
component that implements a home interface for the MyStateValueType -
e.g. MyStateValueTypeHome is the home interface and
MyStateValueTypeHomeProvider is the component implementation that
provides creation, retrival and destruction of instance of MyStateValueType.
At the meta-data level would would need something like:
<component class="MyDemoComponent" name="whatever">
<identity>
<key>12345</key>
</identity>
</component>
The container on creation of an identifiable component resolves the home
factory (an implicit lifecycle dependency) and if the meta-data declares
a key, then a persistent value is retrieved and supplied to the
component via a context entry. If no identity is supplied, a new state
value is created and supplied.
Any thoughts?
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Alexis Agahi <al...@users.sf.net>.
On Sunday 02 November 2003 07:28, Niclas Hedhman wrote:
> If you would make, for instance, Merlin EJB/CMP-like, you are facing a much
> larger challenge than having a Persistable interface.
> You need to introduce runtime modifiable dependency links and likewise
> Configuration. You would need to define a transaction system and many other
> intricate mechanisms straight into Avalon Framework.
> You basically need a JDO/Hibernate/OJB/whatever implementation right in the
> core.
Dude this is just a RT. I'm just trying to see if we could have a simple
approach. A tradeof beetween EJB & JDO & Avalon.
BTW as some (& you) have sugested, a component could be defined to handle
persistence. This already exist and seems quite obvious.
> I don't think that is feasible, even by leveraging something like
> Hibernate, it requires massive changes, and for those who MUST HAVE it, I
> seriously think they should look at above links.
Dont be pessimist, we are here to raise challenges. And sometime there are
simple and small solution.
> Compared to a PersistenceManager as a Component (whether coming via
> ServiceManager, Context or container extensions) is a lot easier to deal
> with.
No prob, it is just that I'm trying to see beyond this, to maybe get some
magical model, maybe inside component manager or Merlin Extension.
> I hope my negativism doesn't hamper your creativity.
negativism is not good for health.
I'm not claiming creativity, but just trying to see if there is some good idea
from this thread that could enhance component model or Merlin management.
take care.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 02 November 2003 03:35, Alexis Agahi wrote:
> This is maybe because I'm trying to consider the component as EJB/CMP.
> Anything that need to have persistent data.
> For me a compenent is an object like any other, except it features
> lifecycle interfaces. So I'm trying to imagine if a component could handle
> persistence lifecycle interface.
Hmmm...
Actually, I agree with Hammett that we have slightly different views of what a
Component is and how it is interacting with its environment.
public void twistHead( int degrees )
{
if( degrees > 30 || degrees < -30 )
throw new MassivePainException( "it is Sunday." );
}
Nevertheless,
<quote>
Anything that need to have persisted data.
</quote>
Here you are argueing against yourself. If a Component needs to have persisted
data, the Component itself is not persisted, but values of the Component is.
In this case we are back to Component Managed Persistence of its value
objects.
<quote>
This is maybe because I'm trying to consider the component as EJB/CMP.
</quote>
Sorry to say, but if you want EJB/CMP, go to
http://java.sun.com/j2ee
or
http://www.jboss.org
;o)
Sarcasm put aside,
If you would make, for instance, Merlin EJB/CMP-like, you are facing a much
larger challenge than having a Persistable interface.
You need to introduce runtime modifiable dependency links and likewise
Configuration. You would need to define a transaction system and many other
intricate mechanisms straight into Avalon Framework.
You basically need a JDO/Hibernate/OJB/whatever implementation right in the
core.
I don't think that is feasible, even by leveraging something like Hibernate,
it requires massive changes, and for those who MUST HAVE it, I seriously
think they should look at above links.
Compared to a PersistenceManager as a Component (whether coming via
ServiceManager, Context or container extensions) is a lot easier to deal
with.
I hope my negativism doesn't hamper your creativity.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by hammett <ha...@apache.org>.
> But how do you get/find a component (using a sort of finder, for exemple)?
> Something like, lookup & load the component having name 'joe'".
Loading/searching share a lot, so a different entity was created, something
like EntityFinder. But this was our strategy, it could be different :-)
Regards,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Stephen McConnell <mc...@apache.org>.
Alexis Agahi wrote:
>But how do you get/find a component (using a sort of finder, for exemple)?
>Something like, lookup & load the component having name 'joe'".
>
If the "joe" value is the identifiable key to a persistent value, then
the key is scoped within a home relative to a persistent value type in
the context of a storage connection.
Steve.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Alexis Agahi <al...@users.sf.net>.
On Sunday 02 November 2003 00:57, hammett wrote:
> Do you want some messages like "store" and "load" managed by some external
> entity (component)?
why not, I dont have strong requirement ;)
> Then that can be done by a additional extension, but I don't know why this
> should be done this way. Niclas see a persistence engine as a different
> component and I see components that can handle their own persistence
> transparently.
Yes that could be nice: transparently persistence.
> I strongly advise you to support persistence that can be plugged in and
> off, so please check http://www.prevayler.org/
>
> Few months ago I worked in a simple business model (using avalon) whose
> business objects implemented IBusinessObject that exposed save/remove.
> These methods ask for their PersistenceManager (as Niclas commented). So,
> for Unit testing we could use prevayler, but in our real solution we used a
> common rdbms.
>
> [AvalonService( typeof(IEntity) )]
> [AvalonComponent( "entity", Lifestyle.Transient )]
> [AvalonDependency( typeof(IEntityPersistence), "Persistence",
> Optional.False )]
> public class Entity : AbstractBusinessObject, IEntity, ILookupEnabled
> {
> <....>
> /// <summary>
> /// Saves this object against the storage.
> /// <seealso cref="Keldor.Common.Entity.Persistence.IEntityPersistence"/>
> /// </summary>
> public override void Save()
> {
> IEntityPersistence persistence = (IEntityPersistence)
> _manager["Persistence"];
> persistence.Save(this);
> }
>
> /// <summary>
> /// Removes this object from the storage.
> /// <seealso cref="Keldor.Common.Entity.Persistence.IEntityPersistence"/>
> /// </summary>
> public override void Remove()
> {
> IEntityPersistence persistence = (IEntityPersistence)
> _manager["Persistence"];
> persistence.Remove(this);
> }
> }
I see, you mean the component save/load it state via load/save methods that
could also occurse during lifecycle.
Nice.
But how do you get/find a component (using a sort of finder, for exemple)?
Something like, lookup & load the component having name 'joe'".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by hammett <ha...@apache.org>.
----- Original Message -----
From: "Alexis Agahi" <al...@users.sf.net>
> For me a compenent is an object like any other, except it features
lifecycle
> interfaces. So I'm trying to imagine if a component could handle
persistence
> lifecycle interface.
Do you want some messages like "store" and "load" managed by some external
entity (component)?
Then that can be done by a additional extension, but I don't know why this
should be done this way. Niclas see a persistence engine as a different
component and I see components that can handle their own persistence
transparently.
I strongly advise you to support persistence that can be plugged in and off,
so please check http://www.prevayler.org/
Few months ago I worked in a simple business model (using avalon) whose
business objects implemented IBusinessObject that exposed save/remove. These
methods ask for their PersistenceManager (as Niclas commented). So, for Unit
testing we could use prevayler, but in our real solution we used a common
rdbms.
[AvalonService( typeof(IEntity) )]
[AvalonComponent( "entity", Lifestyle.Transient )]
[AvalonDependency( typeof(IEntityPersistence), "Persistence",
Optional.False )]
public class Entity : AbstractBusinessObject, IEntity, ILookupEnabled
{
<....>
/// <summary>
/// Saves this object against the storage.
/// <seealso cref="Keldor.Common.Entity.Persistence.IEntityPersistence"/>
/// </summary>
public override void Save()
{
IEntityPersistence persistence = (IEntityPersistence)
_manager["Persistence"];
persistence.Save(this);
}
/// <summary>
/// Removes this object from the storage.
/// <seealso cref="Keldor.Common.Entity.Persistence.IEntityPersistence"/>
/// </summary>
public override void Remove()
{
IEntityPersistence persistence = (IEntityPersistence)
_manager["Persistence"];
persistence.Remove(this);
}
}
Regards,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Alexis Agahi <al...@users.sf.net>.
On Saturday 01 November 2003 12:39, Niclas Hedhman wrote:
> On Saturday 01 November 2003 19:01, Alexis Agahi wrote:
> > Why not; good idea, but I dont know if PersistenceManager is a classical
> > component, would it be able to deal with new component lifecycle?
> >
> > I mean when a lookup is performed on persistenceManager it should respect
> > component dependency, and all lifecycle stage (including persistence
> > stuff).
> >
> > If a compenent can handle such features, then no problem.
>
> Huh???
>
> You are envisioning Persisted components... I have a problem seeing this as
> natural thing. I see components having smaller artefacts (value objects of
> some kind) that they can store away.
This is maybe because I'm trying to consider the component as EJB/CMP.
> Can you give an example of a component that you would like to see to be
> persisted?
Huh ?? :))
Anything that need to have persistent data.
For me a compenent is an object like any other, except it features lifecycle
interfaces. So I'm trying to imagine if a component could handle persistence
lifecycle interface.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 01 November 2003 19:01, Alexis Agahi wrote:
> Why not; good idea, but I dont know if PersistenceManager is a classical
> component, would it be able to deal with new component lifecycle?
>
> I mean when a lookup is performed on persistenceManager it should respect
> component dependency, and all lifecycle stage (including persistence
> stuff).
>
> If a compenent can handle such features, then no problem.
Huh???
You are envisioning Persisted components... I have a problem seeing this as
natural thing. I see components having smaller artefacts (value objects of
some kind) that they can store away.
Can you give an example of a component that you would like to see to be
persisted?
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Alexis Agahi <al...@users.sf.net>.
On Saturday 01 November 2003 11:16, Niclas Hedhman wrote:
> Although I am pretty keen on getting into a Persistence model for
> component's value objects (as the component itself rarely is persistable),
> I fail to see the need for a extension of Avalon Framework.
>
> IMHO, the PersistenceManager is just any Avalon component, which is
> configured the normal way, and looked up via the ServiceManager by
> components that requires it.
Why not; good idea, but I dont know if PersistenceManager is a classical
component, would it be able to deal with new component lifecycle?
I mean when a lookup is performed on persistenceManager it should respect
component dependency, and all lifecycle stage (including persistence stuff).
If a compenent can handle such features, then no problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Stephen McConnell <mc...@apache.org>.
Niclas, and Alexis:
You may be suprised to know that in the past I have used the context
object to pass a persistent value to a component that maintain a
persistent state.
I have not used the ServiceManager bacause I'm not providing a service
to the component.
I don't know OJB and Hibernate but I do know PSS (Persistent State
Service) and what PSS lets me do is to establish a value object that I
can use to encapsulate state. If I pass the value to a component as
part of the supplied context - I am saying - "here is the instance that
makes up part of the component state". The logical question from this is
"how do you establish the state value instance?". Well - components are
created to handle requests (i.e. provide services) but in the case of a
persistent component we are talking about an identifiable component.
Therefore we have a home component (a component that understands the an
identify relative to a particular scope). The home component handles
the request for a service relative to an identity. This gets translated
into the establishment of a component with a context entry corresponding
to the identity state.
Cheers, Steve.
Niclas Hedhman wrote:
>On Saturday 01 November 2003 17:14, Alexis Agahi wrote:
>
>
>>Hi,
>>
>>As I'm now using hibernate on current biz project, some ideas come to my
>>brain about how could have transparent persistence with avalon compenent.
>>
>>Based on hibernate (JDO?) approach that all object could be mapped in
>>database with get/setter method to populate the object field from db (or
>>persist state to db), any component could support such feature.
>>
>>The main problem would be how manage compenent persistance.
>>I have a suggestion: via a Persitence interface that could be added in
>>component lifecycle.
>>
>>such as
>>public interface Persistence
>>{
>> public void persitence( PersistenceManager persistenceManager );
>>}
>>
>>PersistenceManager class would manage object persistance/lookup(load) and
>>transaction provider.
>>
>>
>
>Although I am pretty keen on getting into a Persistence model for component's
>value objects (as the component itself rarely is persistable), I fail to see
>the need for a extension of Avalon Framework.
>
>IMHO, the PersistenceManager is just any Avalon component, which is configured
>the normal way, and looked up via the ServiceManager by components that
>requires it.
>
>I don't see the difference (other than casting) of;
>
>public void service( ServiceManager sm )
>{
> m_ServiceManager = sm;
>}
>public void persistence( PersistenceManager pm )
>{
> m_Persistence = pm;
> // snip
>}
>
>
>and
>
>public void service( ServiceManager sm )
>{
> m_ServiceManager = sm;
> m_Persistence = (PersistenceManager) sm.lookup( PersistenceManager.ROLE);
>}
>
>
>Please elaborate what is the benefit?
>
>
>Niclas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Component Persistence
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 01 November 2003 17:14, Alexis Agahi wrote:
> Hi,
>
> As I'm now using hibernate on current biz project, some ideas come to my
> brain about how could have transparent persistence with avalon compenent.
>
> Based on hibernate (JDO?) approach that all object could be mapped in
> database with get/setter method to populate the object field from db (or
> persist state to db), any component could support such feature.
>
> The main problem would be how manage compenent persistance.
> I have a suggestion: via a Persitence interface that could be added in
> component lifecycle.
>
> such as
> public interface Persistence
> {
> public void persitence( PersistenceManager persistenceManager );
> }
>
> PersistenceManager class would manage object persistance/lookup(load) and
> transaction provider.
Although I am pretty keen on getting into a Persistence model for component's
value objects (as the component itself rarely is persistable), I fail to see
the need for a extension of Avalon Framework.
IMHO, the PersistenceManager is just any Avalon component, which is configured
the normal way, and looked up via the ServiceManager by components that
requires it.
I don't see the difference (other than casting) of;
public void service( ServiceManager sm )
{
m_ServiceManager = sm;
}
public void persistence( PersistenceManager pm )
{
m_Persistence = pm;
// snip
}
and
public void service( ServiceManager sm )
{
m_ServiceManager = sm;
m_Persistence = (PersistenceManager) sm.lookup( PersistenceManager.ROLE);
}
Please elaborate what is the benefit?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org