calling methods on every level of an object graph

[Serdyn du Toit]

Hi guys,

Thanks for all the feedback on my previous query (a few months back) on web frameworks.  Finally decided to use Struts 2 - still need to wrap it up though, got everything working except sessions and will tackle that in the next couple of weeks.

New question -

Does anyone know of any open source framework one can use to call methods on every level of an object graph?

To elaborate -

Say you have an object and on that object you have a method that needs to be called at certain stages of the object's lifecycle.  That might be very similar to I guess behavior that something like JPA would support (not sure) - pluggable life cycle managers and eg @PostPersist-type methods on your entity.

In my use case I also need pluggable life cycle managers and life cycle methods.  In my use case the pluggable life cycle managers and life cycle methods can however exist on any depth in the (non-cyclical) object graph...so when the life cycle manager method is invoked on the core object all the similar life cycle methods within the object graph must also be called.

Is there any open source frameworks that can help me with this problem?  Otherwise I'll just need to roll my own.

Currently all these objects have the same interface, so it should be easy to identify their presence within the object graph.  Currently on the core object I have something similar to the following:

  public ILifeCycleManager getLifeCycleManager()

But going forward I will most likely refactor this pluggable behavior to be in an annotation:

(not an annotation-guru but something similar to the following - sorry haven't really reviewed this, will need to learn more about annotations when I get here)

@Documented @Inherited

@Retention(RetentionPolicy.RUNTIME)

@Target({ElementType.TYPE})

public @interface EntityListeners

{

  Class<?>[] value();

}

First iteration -

1) will most likely just support ONE pluggable life cycle manager per class (though the annotation above supports many)

2) will also need to support a @SkipLifeCycleManagement-type annotation where I can force the code to not traverse certain areas of the object graph - and should speed up processing

Any input appreciated :)

Thanks guys :)

Kind regards,

Serdyn du Toit

[Moandji Ezana]

This sounds fairly complex, so forgive me if I've misunderstood something.

What does it mean to have a pluggable life cycle manager *within* the object graph? They generally sit outside of it (eg. a dependency injection container, servlet container or web framework).

For comparison, in JPA, EntityListeners are singletons. An annotation on an entity binds it to a given listener (or vice-versa, I forget), and all calls go to a single instance of that listener.

This may be terribly naïve, but could the root object call the life cycle methods itself? Then the children objects could do the same on their children.

Alternatively, AOP may be of help here. I can't think of any standalone projects to traverse an object graph, though many projects do that, such as JSON libraries.

Moandji

--
You received this message because you are subscribed to the Google Groups "CTJUG Forum" group.
To post to this group, send email to CTJUG...@googlegroups.com
To unsubscribe from this group, send email to CTJUG-Forum...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/CTJUG-Forum
For the ctjug home page see http://www.ctjug.org.za
For jobs see http://jobs.gamatam.com/

[NS du Toit]

Hi Moandji,

Yeah - I was overthinking the problem, I'm going to solve it in a much simpler way.

I'm just writing a Dao's to use with MongoDb (on top of Morphia whose inbuilt Daos I don't want to use).  And MongoDb doesn't support transactional operations outside of an "entity" - but it does support much more complex objects to be persisted.  One can have Maps, Sets, and Lists within the entity and it will persist to the same "table".  Just had to rethink how I work with objects due to the inability to have transactional boundaries across entities.  (Except if one maintains an external lock somewhere, and if anyone has implemented something in that direction I might be supereager to see the code going forward).

So still prototyping and discarding bad ideas and solutions as I learn more.

Thanks for engaging me - helps me think :)

Kind regards,

Serdyn du Toit

[NS du Toit]

Just to respond to one of your comments re the web frameworks (didn't have ample time back then)

> I don't know about Log4J, but Hibernate (like Spring) scans all the mappings at startup and that can get quite slow as your application grows.

That's the way I currently configured Struts 2, that Struts 2 will scan for Struts 2 action classes within the source.  I did configure Struts 2 to only scan packages named "web" for actions (but yeah, I wouldn't want to follow this pattern for Hibernate objects as they are a much more integral part of the core code).

    <!-- Define the package names that Struts should scan for actions -->

    <constant name="struts.convention.package.locators" value="web" />

So that should reduce the time to scan all the source code.  I guess the other option without implementing it in a different way is to to buy a SSD :)

Kind regards,

Serdyn du Toit