Reusable 'Module' configuration files?

[zanfolim]

Hello everybody,

I´ve been thinking about the following issue for some time and I would like to share/discuss it with anyone interested on it. Here it goes:

Besides having reusable components, we also want to be able to have reusable modules (a module being something like a security related set of components that offers user admin, audit info, etc).
Such a module could be used many times, like in a credit card processing application, a CRM system, etc). We could always wire the components of the modules in the final application, but it would be nice if we could wire the application starting from the modules themselves. So, what if we could ‘reuse’ of the modules configuration files, in the following way:

Every software module, composed of a series of components, would have the following bean configuration files, that will be loaded by the BeanFactory:
- Server.cfg.xml: this is the module core definition file. The file wires the business objects with its DAOs, resource bundles, transaction proxies, and wherever is required for running the application, without referring to external resources;
- Resource.cfg.xml: this file will define the external resources, like the database to use and the transactional managener
- Bind.cfg: this file would expose only the beans required by client applications: depending on the deployment configuration, this would be the only required configuration file to be sent with client applications (the other ones would be on the application server side, for example.)

When building the applications, we would want to merge the various server.cfg.xml and bind.cfg files from the modules and define only the resource.cfg.xml files for a given application. This way, only the external resources would have to be rewritten, and we could avoid duplicating the wiring code every time the component is deployed with a new application.

Is somebody trying any approach like this? Would anyone suggest something better or a way to enhance this?

Thanks,

Tedi

[jbetancourt]

Would this be somewhat related to the concept of a Spring deployment unit? This was discussed in connection with the Geronimo server, see

http://sourceforge.net/mailarchive/m...msg_id=8917793

I'm wondering why not just use an existing plug-in architect model. For example, if OSGi were used, a spring 'component' could be an Eclipse plug-in (maybe).

j. betancourt

[billsalvucci]

I'm about to try something similar to this. The only issue that I see is with bean defs like sessionFactory and serviceTransactionInterceptor that need to be merged not simply extended. I was thinking about subclassing the bean class and overriding, for example, the setMappingResources to merge the list if it is already set, not just replace the list which will happen if you simply extend the bean def. We'll still need to extend the beanDef, but it looks like we will need to extend the underlying class as well.

Everytime I implement something like this to "improve" Spring, I find out the next day that Spring already has it built in and it is always a better solution than what I have come up with. So can anyone save me the trouble and point me to the existing solution.

[adepue]

The referenced thread is more than a year old - what is the status of this "Spring deployment unit"?

[billsalvucci]

One major issue that I have come up against is with respect to hibernate mapping files. We use joined-subclass for inheritance and the subclass mappings get written to the parent class hbm.xml. This is a problem when we have a parent class in one deploment unit and a subclass of that parent class in another. It becomes a real problem when you multiple deployment units each with a subclass of parent. There is on hbm.xml file across all of them, and these "child" deployment units do not know about each other.

How do people make reusable domain classes like Person, Address, etc. Just about every application that I write uses these classes.

[jbetancourt]

The referenced thread is more than a year old - what is the status of this "Spring deployment unit"?

I don't know. But, related news, there is a new JSR related to OSGi:
http://jcp.org/en/jsr/detail?id=291

This specification will define a dynamic component framework including component lifecycle for existing Java SE platforms. The dynamic component model will support assembly of applications from components and support implementation detail hiding between components as well as lifecycle management of those components.

....

The specification will enable components to be declared through metadata and be assembled at runtime using a class loader delegation network. The specification will also allow components to be dynamically life cycle managed (install, start, stop, update, uninstall).

This specification will be based upon JSR 232 which references the recently published OSGi Service Platform Release 4 Core Specification.
This specification will be a subset of JSR 232 including the modularity and lifecycle aspects of the OSGi R4 framework but excluding the service aspects of the framework, declarative service support, and the services defined by JSR 232.

....

It appears that this is different then JSR 277, which targets static component assembly: http://www.jcp.org/en/jsr/detail?id=277. Maybe these committees should sit together and have tea and biscuits.

[zanfolim]

Well, the thread is quite old now. If anyone interested, we have been using the approach first described since the post date and it has worked nicely.