JD Daniels wrote:
Wait a minute ok I think I see now...
project/java
persistenceFactory.java - interface to cocoon's persistenceFactory, methods createSession
HibernateFactory.java - implements persistenceFactory, methods configure, service, initialize, dispose, createSession
Ok so far so good, when cocoon starts up, the hibernate factory is initialized, and the sessionfactory is in existence:
cfg = new net.sf.hibernate.cfg.Configuration();
cfg.addClass(com.kismetsoftware.insecticide.Company.class);
cfg.addClass(com.kismetsoftware.insecticide.Project.class);
cfg.addClass(com.kismetsoftware.insecticide.Bug.class);
cfg.addClass(com.kismetsoftware.insecticide.Comment.class);
sf = cfg.buildSessionFactory();
You should be declaring these inside hibernate.cfg.xml to avoid putting all this hardcoded junk in your code. What you are doing will work, but gives you pain with no gain, in your particular case.
I was thinking this would be moved to happen at every request, which I definately did not want. It makes sense now. So when I change the persistence mechanism, it *should* be only these two classes that need to be changed right?
You should only create one SessionFactory per application lifecycle.
Should change to:
// Create Persistence Session
var factory = cocoon.getComponent(Packages.com.kismetsoftware.insecticide.PersistenceFactory.ROLE);
Right, this is the part that I am less keen on. I don't see the point of creating this dependency between Cocoon and your backend.
var hs = factory.createSession();
// Might as well quit now if the session is no good :(
if (hs == null){throw new Packages.org.apache.cocoon.ProcessingException("Persistence session is null ");}
// Grab the class with the methods to do what we want (Constructor takes the session as an arguement)
var bugSearch = new Packages.com.kismetsoftware.insecticide.BugSearch(hs);
Well, you shouldn't even be exposing any of this Hibernate stuff in the flow code at _all_. The Hibernate session is just wrapping your JDBC connection and whatever transaction JTA/JDBC transaction that you're currently in, so you could create a class to wrap that.
// Look up our Entry var bean = bugSearch.findBugById(id);
Yes, that's looking better. But call it a 'facade', so that others who work on your code will understand the role of bugSearch immediately just by looking at the name.
right? Or would it be better to have one class such as BugFacade with all methods dealing with bugs? (save, find, delete etc)
You can run into an anti-pattern quickly here, but you should ideally have all of your transactional and business logic methods exposed in one interface or class, not just your bug search stuff.
(Aside: are you really writing _another_ bug tracking system...???)
Lastly, I am pretty sure the above would work, but to be really separate-y, what about:
var bugSearch = new Packages.com.kismetsoftware.insecticide.BugSearch(hs); var bean = bugSearch.findBugById(id);
Right.
much simpler and really doesn't care how BugSearch does what it does. How would I get a grip on the cocoon component inside BugSearch.java?
I don't think you should be, but maybe someone else has a good argument for creating this dependency.
<quote> You should really be using the "Open Session in View" pattern:
http://hibernate.org/Documentation/OpenSessionInView </quote>
Sorry, but this has confused me further.. where would this fit into a cocoon framework?
Cocoon sits on top of a web container. The servlet 2.3 api supports servlet filters. What this person is suggesting is that you use a servlet filter to drop a hibernate session into a threadlocal that sits in the thread currently servicing your request. It's a very standard way of doing stuff like this... definitely take the time to understand that.
phil.
JD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Whirlycott Philip Jacob [EMAIL PROTECTED] http://www.whirlycott.com/phil/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
