This weekend we were working trying to solve Jira#PVM-44 (spring configuration support).
At the moment we are trying to learn wich part of your configuration framework has to be done with Spring.
We first did an SpringEnvironmentFactory extending EnvironmentFactory. About this we have this first impressions:
* There is some coupling with all the parser lifecycle, meaning that in Spring there is no such concept (at the high level, of course). As we understood the intention is that we must make our own Parser that receives the config file location, parse it until we get the SpringEnvironmentFactory. This is not posible without going to deep into the spring architecture. In spring you just create an XmlApplicationContext instance from the file and you ask it for defined beans. The solution was to make an static method SpringEnvironmentFactory#parse(InputStream) -just to follow your conventions, but using this concept in spring is not really usual- that accomplish this task but ignoring all the other way.
* We defined a Context in the Environment containing a hibernate session. At first time we tried to make a SimpleContext just implementing the Context interface and keeping it as pojo as possible, to be able to fill it with Spring. We made it and succesfully register the HibernateSession on it. But the problem began when we tried to get it by class (type). The hibernate session get registered as SessionFactoryImpl and in the code it is invoked as get(SessionFactory.Class). Digging into the code we realize that all this registrations had to be done by a layer of Descriptors through the WireContext. Now the problem is that all this layer is not really so much pojo-oriented in the sense that there are no getters and setters for every property.
* Maybe the whole package org.jbpm.pvm.internal.wire.* should be avoided in the Spring configuration. But when we try to get this we realize that there are some coupling between the usage of services and the way that they get 'injected' and even this approach will translate in a lot of duplications in the code.
Have you any suggestion about this topics?
Beside how we resolve this, is necesary to add in your ivy repository the Spring dependencies. At the moment we have
Mauricio Salatino - Diego LÃ³pez LeÃ³n
PS: do you get all the notification for JIRA comments? Let us know if you want to see our code.
we're you guys in Dublin? Because I heard Tom speaking about this initiative... if so I'm sorry we did not meet.
btw, I think some info is missing in your post. Probably because of an xml tag and not using [c o d e ] tags
XmlApplicationContext instance from the file and you ask it for defined beans
exactly. you just wrap that in the SpringEnvironmentFactory.
i think that maybe spring's application context is related to both the pvm EnvironmentFactory and the Environment. as you can get singleton and non-singleton beans from the same spring application context. i wasn't able to find out how to "reset" such an environment for a new request/environment
At first time we tried to make a SimpleContext just implementing the Context interface
i think it should be done simpler. just by wrapping a spring application context into a environment/environmentfactory pair.
the thing we need to find out is how to programmatically work with spring's application context so that we can do the following:
1) create a spring application context. this may eager initialize the hibernate session factory
2) get a hibernate session from it. this will lazy initialize the hibernate session. if not done in step one, the hibernate session factory will be created for this.
3) if we get the hibernate session a second time, we will get the same hibernate session.
4) now we want to indicate to the spring application context that the request is done (in our case it will be the environment that is closed). This should imply that the hibernate session gets closed. i don't know how this is done in spring.
5) next we should be able to leverage the same singleton objects, but all non-singleton objects that we fetch should be created. e.g. if we get the hibernate session again, we should get a new one, different from the one in steps 2 and 3.
If we can do such a thing by only using spring API's in a junit test, we already have made a big step.
first step is to commit a spring configuration file and a unit test that shows how to use this in plain spring ways. then i'll have another look.
For our use, I've been thinking about having a spring application context that is local to a particular process definition, providing access to the beans with a VariableResolver. In many cases, this will help avoid expensive setup in delegations and/or facilitate scripting in lieu of delegation classes.
Ed, if you are referring to static usage, then this should be supported already, i think.
Makes very much sense.