Dao Spring Hibernate implementation. Your opinions are appreciated (-:
Hi there
I just wanted to know if my simple Dao Spring Hibernate implementation is good. Hope you can give me your opinions.
public class BaseDao extends HibernateDaoSupport{
public BaseDao() {
}
protected void saveOrUpdate(Object obj){
getHibernateTemplate().saveOrUpdate(obj);
}
protected void delete(Object obj){
getHibernateTemplate().delete(obj);
}
protected Object find(Class clazz, Serializable id){
return getHibernateTemplate().load(clazz, id);
}
protected List findByQueryWithValue(String query, Object value){
return getHibernateTemplate().find(query, value);
}
}
****************************************************
public interface UserDao {
public void saveUser(User user);
public User findUser(Long id);
public User findUserByName(String uName);
public void deleteUser(User user);
}
*************************************************
public class UserDaoImp extends BaseDao implements UserDao{
public UserDaoImp() {
}
public void saveUser(User user){
super.saveOrUpdate(user);
}
public void deleteUser(User user){
super.delete(user);
}
public User findUser(Long id){
return (User) super.find(User.class, id);
}
}
***************************************************************************
I wanted to use a very simple 1 DaoManager for all daos that will just return the right DaoImpl when I call the Dao.
If I use a seperate DaoManger for every dao, it's just duplicating the dao again in my opinion.
So I use:
public class DaoManager {
private UserDao userDao;
public DaoManager() {
}
public void setUserDao(UserDao userDao) {
this.userDao = userDao;
}
public UserDao getUserDao(){
return userDao;
}
}
other daos can be added with setter and getter and be set in the application context in Spring.
***************************************************
applicationContext:
<bean id="userDao" class="com.xxxx.dao.hibernateImp.UserDaoImp">
<property name="sessionFactory" ref="factory"/>
</bean>
<bean id="daoManager" class="com.xxxx.service.DaoManager">
<property name="userDao" ref="userDao"/>
</bean>
to add more daos I just add the dao bean and add a property line in the daoManager bean.
**********************************************************
BaseAction:
protected DaoManager daoManager;
public void setDaoManager(DaoManager daoManager){
this.daoManager = daoManager;
}
in my action classes that extends BaseDao(WebWork):
public String execute(){
UserDao userDao = daoManager.getUserDao();
User user = new User();
user.setUsername("justMe");
user.setPassword("myPass");
userDao.saveUser(user);
}
Well, what do you think? almost everything is standard here (I think). I just wanted to "save" on some interfaces with the DaoManager and make it simpler.
Thanks in advance (-:
Dror
You can get rid of your DaoManager class by loading your beans via the WebApplicationContext. You can use a ContextLoaderListener to find the root WebApplicationContext for your web app.
YoGeea at 2007-7-14 22:55:54 >
small typing mistakethe action classes will extend the BaseAction (-:
Thanks YoGee
I'm a little bit confused here (-:
I use the setBean method to load the bean. I can use it directly in the Action class without the DaoManager, but then I have to write the setBean method in every Action class and for every bean.
That's why I use the DaoManager that loads all the dao beans with the set methods.
Are you suggesting that I should use this in the BaseAction:
ApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(getSession().getServletContext());
And then this in the actions to get the beans?
ctx.getBean("userDao");
When should I use the WebApplicationContext and when should I use the setBean to load the beans?
I'm building a web application that will hopefully have many users (-:
Thanks
Dror
Here is an example:
In your web.xml file:
<listener>
<listener-class>xxx.yyy.ConfigurationListener</listener-class>
</listener>
The ConfigurationListener class:
package xxx.yyy;
import javax.servlet.ServletContextEvent;
import org.springframework.web.context.ContextLoaderListener;
public class ConfigurationListener extends ContextLoaderListener {
public void contextInitialized(final ServletContextEvent servletContextEvent) {
super.contextInitialized(servletContextEvent);
SpringContext.initialize(servletContextEvent.getServletContext());
}
}
And the SpringContext class:
package xxx.yyy;
import java.io.Serializable;
import javax.servlet.ServletContext;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;
public class SpringContext implements Serializable {
private static final long serialVersionUID = 3125223827888524892;
private static WebApplicationContext wac;
private static boolean initialized = false;
private SpringContext() {}
protected static synchronized WebApplicationContext initialize(final ServletContext servletContext) {
if (wac == null) {
wac = WebApplicationContextUtils.getRequiredWebApplicationContext(servletContext);
initialized = true;
}
return wac;
}
public static Object load(final String name) throws IllegalStateException {
if (!initialized) throw new IllegalStateException("SpringContext has not been initialized.");
return wac.getBean(name);
}
}
Now you can simply do this:
final UserDAO adao = (UserDAO) SpringContext.load("userDao");
YoGeea at 2007-7-14 22:55:54 >
I thought Spring already has the following contextLoaderListener? What is the different? <listener><listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener>
> I thought Spring already has the following
> contextLoaderListener? What is the different?
> <listener>
>
> listener-class>org.springframework.web.context.Context
> LoaderListener</listener-class>
> </listener>
That's what I use.
%
I'm not sure what you "save" here.If you're using Java 5 you can write a generic DAO. Added type safety that way.%
Not directly pertinent, but I'm not a big fan of DAOs that only do stuff that's already available from the Hibernate Session. In my opinion a DAO should contain app-specific closely related data access methods, and you should add them as they are required, not prepopulate it with a bunch of stuff that may never be used.
I also think that your general approach here is misguided for other reasons:
The HibernateTemplate serves almost exactly the same purpose as the BaseDao class that you've created.
Spring is all about IoC and your DaoManager pretty much subverts this. Unless you want to make your app independent of Spring (fairly pointless) as well as independent of it's database implementation, just use injection to provide your Dao to classes that will make use of it.
I.e. instead of pulling in a UserDao from the manager, just provide getters and setters.
Unless I'm missing something you're over-engineering badly here.
Here's a concrete illustration of the sort of approach that I take with pretty much all of my DAOs, but using your example:
public class UserDao extends HibernateDaoSupport {
public void saveUser(User user) {
// Your code should always know whether it
// is saving or updating. Don't just assume they
// meant to do an update if they give you a
// persistant object.
getHibernateTemplate().save(user);
}
// Business code is unlikely to use PKs for retrieval. Implement
// this method only if it's actually required.
//public User findUser(Long id) {
//}
// Make sure you've got an index on the name column!
public User findUserByName(String uName) {
return getHibernateTemplate().findByNamedQueryAndParam("findUserByName","username",uName);
}
public void deleteUser(User user) {
getHibernateTemplate().delete(user);
}
}
And here's how my services are implemented.
public class UtilisingService {
private UserDao userDao;
public void doSomething() {
final User user = new User("Bloggs");
userDao.save(user);
}
public void doSomethingElse() {
final User admin = userDao.findUserByName("admin");
...
}
public void setUserDao(UserDao userDao) {
this.userDao = userDao;
}
public UserDao getUserDao() {
return this.userDao;
}
}
The application context then uses injection to provide the UserDao where it's needed.
<bean id="userDao" class="com.xxxx.dao.UserDao">
<property name="sessionFactory" ref="factory"/>
</bean>
<!-- I would normally wrap services in a transaction interceptor by the way -->
<bean id="utilisingService" class="com.xxxx.service.UtilisingService">
<property name="userDao" ref="userDao"/>
</bean>
<bean id="anotherUtilisingService" class="...">
<property name="userDao" ref="userDao"/>
</bean>
etc.
If you're really worried about boilerplate code getting duplicated I suppose it's ok to push the common functionality of the UserDao up into a base class, as long as it really is common to all DAO classes, is used by all DAO classes, and the methods you're providing in those DAO classes do actually get used by the client code! Don't just provide a doFoo method becuase it's in the base class.
I wouldn't usually bother to push the getter and setter pair up into a superclass of the Service because each service is likely to require a different smattering of DAOs anyway.
I can't promise that this is the "Officially the best" way to do it, but I can promise that it works extremely well for me in the day job.
D.
> I thought Spring already has the following> contextLoaderListener? What is the different? No difference, it just saves looking up the WebApplicationContext which is useful if you don't have a ServletContext at hand.
YoGeea at 2007-7-14 22:55:54 >
> Not directly pertinent, but I'm not a big fan of DAOs
> that only do stuff that's already available from the
> Hibernate Session. In my opinion a DAO should contain
> app-specific closely related data access methods, and
> you should add them as they are required, not
> prepopulate it with a bunch of stuff that may never
> be used.
Is that what the OP is doing here? I'm not familiar with Spring.
While I'm at it, can I ask another (possibly dumb) question? What benefits do you get from Spring? When I go out and look at it I just see a lot of 'stuff'. I don't really see any explanation of what problems it solves. I'm sure I'm just missing something. Can somebody clue me in? I spent a little time to really understand what IoC means last night and I feel I understand it and I just don't see the big deal. I don't really see why I need a container for that. Oh, yeah, fair warning: I hate JavaBeans.
> What benefits do you get from Spring?
Cleaner code and easier testing.
> When I go out and look at it I just see a lot of
> 'stuff'. I don't really see any explanation of what
> problems it solves. I'm sure I'm just missing
> something. Can somebody clue me in? I spent a
> little time to really understand what IoC means last
> night and I feel I understand it and I just don't
> see the big deal. I don't really see why I need a
> container for that.
I completely understand where you're coming from. I keep meaning to write up a proper article on the subject. When I first looked into Spring I kept finding stuff that said, in effect: "Spring is good because it's IoC/Loosely coupled" without finding anything to back up the obvious question: "Why is that a good thing?"
I think most importantly, it makes it a hell of a lot easier to write decent unit tests. If your resources are all injected, pushing a mock object in to represent the resources that you're not testing becomes a hell of a lot easier.
The same aspect encourages you to produce a really clean design. You don't write blocks of dodgy boilerplate code to acquire and initialize resources - that all happens in the config file. You just use them as if they'd always been there.
Spring ties all this together with wrappers for pre-existing libraries, so you don't have to write your own code to make them IoC aware - which then provides a nice degree of consistency to the configuration of your application as a whole. Add excellent documentation and you're done.
> Oh, yeah, fair warning: I hate
> JavaBeans.
Yep. They're the weak point. Java badly needs a way to enforce/facilitate JavaBean requirements. Spring 2 helps a little with some handy annotations, but there's a need for better compile-time checking.
The other thing you lose with Spring is a degree of static type checking. But the trade off seems to be worth it in practice.
> > What benefits do you get from Spring?
>
> Cleaner code and easier testing.
>
> > When I go out and look at it I just see a lot of
> > 'stuff'. I don't really see any explanation of
> what
> > problems it solves. I'm sure I'm just missing
> > something. Can somebody clue me in? I spent a
> > little time to really understand what IoC means
> last
> > night and I feel I understand it and I just don't
> > see the big deal. I don't really see why I need a
> > container for that.
>
> I completely understand where you're coming from. I
> keep meaning to write up a proper article on the
> subject. When I first looked into Spring I kept
> finding stuff that said, in effect: "Spring is good
> because it's IoC/Loosely coupled" without finding
> anything to back up the obvious question: "Why is
> that a good thing?"
>
> I think most importantly, it makes it a hell of a lot
> easier to write decent unit tests. If your resources
> are all injected, pushing a mock object in to
> represent the resources that you're not
> testing becomes a hell of a lot easier.
I totally understand the value of IoC. I use it all the time. I think I might
even take it farther than what Spring does but perhaps there's another
name for that.
What I don't get is why I need Spring. IoC is just a design principle. It's
not something that you get only with Spring.
> The same aspect encourages you to produce a really
> clean design. You don't write blocks of dodgy
> boilerplate code to acquire and initialize resources
> - that all happens in the config file. You just use
> them as if they'd always been there.
I'm already doing that. When I look at code using Spring to say, get
some data from the DB and how I am doing it, it's basically the same
except my code is a lot shorter (and doesn't use beans.)
The downside is obviously that I have to write the code to make this
happen as opposed to just using it from Spring, but it really wasn't
that hard.
> Spring ties all this together with wrappers for
> pre-existing libraries, so you don't have to write
> your own code to make them IoC aware - which then
> provides a nice degree of consistency to the
> configuration of your application as a whole. Add
> excellent documentation and you're done.
Right. I can see this as an advantage. But if the overall approach isn't
right for me and my team, I'm not sure this balances out.
> > Oh, yeah, fair warning: I hate
> > JavaBeans.
>
> Yep. They're the weak point. Java badly needs a way
> to enforce/facilitate JavaBean requirements. Spring 2
> helps a little with some handy annotations, but
> there's a need for better compile-time checking.
I don't really want JavaBeans to become more rigourous, I want them
to die. In my mind, they have most of the problems of hashmaps with
very few of the benefits. They are only dynamic on the recieving end.
They can't be made dynamic on the supplying end. That means that
every task starts with 'write a bean'.
To be more clear, where I work we have literally thousands of tables.
Maybe even tens of thousands. There's definitely overlap in tables and
what each column represents but trying to create a bean-based
representation of this data would be a tremendous undertaking and it
would be, frankly, unmaintanable and extremely expensive and I'd
wager, fairly unsuccessful.
What I have been using is a truly light-weight and dynamic approach.
For example, if I need to get a piece of data from database A to a server
B, I don't have to reference it anywhere in my code. It's just
configured. I don't need to write or change a class to add a piece of
data to an Object.
> The other thing you lose with Spring is a degree of
> static type checking. But the trade off seems to be
> worth it in practice.
I'm pretty much over the whole type checking thing. I think it's really
good for reusable infrastructure components that need to be reliable
and will remain relatively static over time but for things that are
constantly changing (like business logic) it's a waste of time. I'm even
thinking of using a Java aware dynamic language (e.g. Jython, Groovy,
or JRuby) to write the business apps and use Java to write the core
building. I don't see XML as a good choice for this.
But I'm really open to the possibility that I am truly missing something
big here. I kind of see Spring as a replacement for EJB (plus some)
when not that many people needed EJB in the first place.
blocks.
> I totally understand the value of IoC. I use it all
> the time. I think I might
> even take it farther than what String does but
> perhaps there's another
> name for that.
I'd be interested in hearing what "farther" is.
> What I don't get is why I need Spring. IoC is just a
> design principle. It's
> not something that you get only with Spring.
Absolutely. There are several IoC frameworks out there - PicoContainer, Hivemind, etc.
But Spring is far more than just IoC. AoP is another aspect. Even if you don't care about either of those, it's the distillation of Interface 21's accumulated experience in design and Java EE solutions. I think they write better code than the run of the mill programmer, too. Not every team has someone like Juergen Hoeller to ride herd on code reviews. It's solid, well tested plumbing code that you don't have to write or maintain. I don't know if you write unit tests as rigorously as they do, but it gives me comfort that Spring is so well engineered. They have zero cyclic dependencies in their code base, and an average coupling between classes of 3%. Can you say that?
> I'm already doing that. When I look at code using
> Spring to say, get
> some data from the DB and how I am doing it, it's
> basically the same
> except my code is a lot shorter (and doesn't use
> beans.)
Most of my Spring-based database methods are one line long. How to you get them to be shorter? Fewer keystrokes? I'll admit that Rod Johnson likes long class names.
> The downside is obviously that I have to write the
> code to make this
> happen as opposed to just using it from Spring, but
> it really wasn't
> that hard.
That's not always the point. Only you get to debug your code. There are hundreds of people banging on Spring every day and exposing problems to be fixed.
> Right. I can see this as an advantage. But if the
> overall approach isn't
> right for me and my team, I'm not sure this balances
> out.
Your team uses your code? It's not just you? You foist your IoC framework on the people that work for you? Oh, my. I think that's terrible. As Spring is more widely adopted I have a good chance of having a portable skill. I'm betting that nobody outside your organization is using your framework.
> I don't really want JavaBeans to become more
> rigourous, I want them
> to die. In my mind, they have most of the problems
> of hashmaps with
> very few of the benefits. They are only dynamic on
> the recieving end.
> They can't be made dynamic on the supplying end.
> That means that
> very task starts with 'write a bean'.
>
> To be more clear, where I work we have literally
> thousands of tables.
> Maybe even tens of thousands. There's definitely
> overlap in tables and
> what each column represents
Sounds like you've got a legacy "Don't Repeat Yourself" mess there.
> but trying to create a
> bean-based
> representation of this data would be a tremendous
> undertaking and it
> would be, frankly, unmaintanable and extremely
> expensive and I'd
> wager, fairly unsuccessful.
>
> What I have been using is a truly light-weight and
> dynamic approach.
> For example, if I need to get a piece of data from
> database A to a server
> B, I don't have to reference it anywhere in my code.
> It's just
> onfigured. I don't need to write or change a class
> to add a piece of
> data to an Object.
Sounds very client/server and awfully database aware.
> I'm pretty much over the whole type checking thing.
> I think it's really
> ood for reusable infrastructure components that need
> to be reliable
> and will remain relatively static over time but for
> things that are
> constantly changing (like business logic) it's a
> waste of time. I'm even
> thinking of using a Java aware dynamic language (e.g.
> Jython, Groovy,
> or JRuby) to write the business apps and use Java to
> write the core
> building. I don't see XML as a good choice for
> this.
I agree with this. I think compile time type safety might be overrated.
> But I'm really open to the possibility that I am
> truly missing something
> big here. I kind of see Spring as a replacement for
> EJB (plus some)
> when not that many people needed EJB in the first
> place.
I think they need a lot of the pieces built into EJB (e.g., transactions, high throughput, etc.), just not the EJB implementation.
%
> I totally understand the value of IoC.
Ok. Most of what I said isn't applicable then.
> IoC is just a design principle. It's
> not something that you get only with Spring.
Sure.
>> (Spring's various wrappers)
> Right. I can see this as an advantage. But if the
> overall approach isn't right for me and my team,
> I'm not sure this balances out.
I don't know what you mean by "approach" here - if you mean "using beans" then I guess I just like beans more than you.
> I don't really want JavaBeans to become more
> rigourous, I want them to die.
Don't agree here.
> In my mind, they have most of the problems
> of hashmaps with very few of the benefits.
Definitely don't agree here either, largely because...
> I'm pretty much over the whole type checking thing.
...I'm not. I like static type checking and don't like giving it up.
> To be more clear, where I work we have literally
> thousands of tables.
Then I suspect you're a very atypical user. The apps I'm involved in rarely exceed a hundred tables.
> Maybe even tens of thousands. There's definitely
> overlap in tables and what each column represents
> but trying to create a bean-based
> representation of this data would be a tremendous
> undertaking and it
> would be, frankly, unmaintanable and extremely
> expensive and I'd
> wager, fairly unsuccessful.
It sounds like you have a legacy system - and yes, I doubt that retrofitting Spring to it would help much. Certainly I'm of the opinion that Hibernate (which is my preferred persistence technology) is a very poor fit in large legacy environments.
> But I'm really open to the possibility that I am
> truly missing something big here.
Do you get the opportunity to apply technology to smaller scale builds? If so, then I guess it's just a matter of taste - if not you might want to see if you like it better in that sort of environment.
D.
> It sounds like you have a legacy system - and yes, I
> doubt that retrofitting Spring to it would help much.
> Certainly I'm of the opinion that Hibernate (which is
> my preferred persistence technology) is a very poor
> fit in large legacy environments.
Actually, I'm in virgin territory with Java here. There are Java people
around, but I'm the only one on my team and the only one using it in
the way that I am. Most of the Java code here is web-based but my
work is more behind-the-scenes.
> > But I'm really open to the possibility that I am
> > truly missing something big here.
>
> Do you get the opportunity to apply technology to
> smaller scale builds? If so, then I guess it's just a
> matter of taste - if not you might want to see if you
> like it better in that sort of environment.
Actually, my current project (the first I've done here) is fairly reasonable
in scope. I've worked with Hibernate in the past and I found it to be
pretty slow and actually kind of cumbersome, even for a small project.
I think it actually makes a lot of things way more complicated than they
need to be.
With my current design, I basically use a function-pointer like interface
to receive each row as the JDBC retrieves them. This lets me execute
with a small footprint because I am basically streaming the data. With
hibernate (int the past) I would have to lazy-load children on even really
small tables because if I didn't, it would take minutes to load. Now I
just use SQL and get the data as I need it. I know SQL and so does
everyone else I work with. They don't know HQL, XML, Spring, etc.
Maybe after I get people comfortable with straight Java, I can look into
using a framework like this. I think Spring is a pretty clever framework
but I wonder if trying to be everything to everyone has dilluted it a little bit.
> Actually, my current project (the first I've done here) is fairly reasonable
> in scope. I've worked with Hibernate in the past and I found it to be
> pretty slow and actually kind of cumbersome, even for a small project.
Hmm. Well, that's not my experience - I find it pretty straight forward to get it up and running. It can be painful if you've got a poorly designed database to work against, or if your database design relies heavily upon sprocs to maintain business rules.
I'd say that for very small projects (a handful of tables) it's not worth the learning curve of Hibernate if you're not already familiar with it. But it rarely takes me as much as ten minutes to sort out the basic configuration - but then I keep template files kicking around for just such an eventuality.
> With hibernate (int the past) I would have to lazy-load
> children on even really small tables because if I didn't, it would take
> minutes to load.
Minutes!? That's unheard of for anything I'd consider to be a "small" table unless you're pulling all the associations in as well.
But yes, you would normally lazy load. It's the default behaviour in H3, and remember most of my experience is with that, not the 2.x flavours.
D.
> > Actually, my current project (the first I've done
> here) is fairly reasonable
> > in scope. I've worked with Hibernate in the past
> and I found it to be
> > pretty slow and actually kind of cumbersome, even
> for a small project.
>
> Hmm. Well, that's not my experience - I find it
> pretty straight forward to get it up and running. It
> can be painful if you've got a poorly designed
> database to work against, or if your database design
> relies heavily upon sprocs to maintain business
> rules.
I had to use 'long' conversations which really complicates things.
> I'd say that for very small projects (a handful of
> tables) it's not worth the learning curve of
> Hibernate if you're not already familiar with it. But
> it rarely takes me as much as ten minutes to sort out
> the basic configuration - but then I keep template
> files kicking around for just such an eventuality.
>
> > With hibernate (int the past) I would have to
> lazy-load
> > children on even really small tables because if I
> didn't, it would take
> > minutes to load.
>
> Minutes!? That's unheard of for anything I'd consider
> to be a "small" table unless you're pulling all the
> associations in as well.
There were maybe a hundred rows with perhaps an average of a
dozen children for each. Maybe the stuff was configured badly but it
ran like a dog. I had to write my code in a really weird way to get the
lazy-loading to do what I wanted too. Could have been user-error but I
spent a lot of time reading up on how to solve these problems and still
wasn't all that happy with the results in the end.
Unfortunately that was at a previous job and I can't give you the
particulars which kind of makes it pointless to discuss I guess.
I suppose the point is that it's one more thing to have to understand
and I'm not sure it really solves many problems for me.
> But yes, you would normally lazy load. It's the
> default behaviour in H3, and remember most of my
> experience is with that, not the 2.x flavours.
Oh yeah, that was the other painful thing, I had to support 2.x and 3.x
and they changed all the package names and a lot of the APIS between
versions. That was a whole other set of code to write.
I think I wrote as much code to get hibernate configured and get the data
where it needed to be as it took me to write my own functional-style
wrapper around JDBC.
Anyway, thanks for the discussion I don't mean to judge or push my
ideas on you. Sometimes I think I come across that way. So I just
want to say that I value your input. If you have questions about what I
am doing or anything, feel free to ask but I think you've answered my
questions.
> Anyway, thanks for the discussion I don't mean to
> judge or push my ideas on you. Sometimes I think
> I come across that way.
Not really. I prefer a robust discussion anyway. I don't suffer from the "everything's a nail" delusion just because I have a nice new hammer. Sometimes the technology du jour isn't appropriate.
D.
> > Anyway, thanks for the discussion I don't mean to
> > judge or push my ideas on you. Sometimes I think
>
> > I come across that way.
>
> Not really. I prefer a robust discussion anyway.
Good to know. That's my preference too.
> I don't suffer from the "everything's a nail" delusion
> just because I have a nice new hammer.
I'm getting into woodworking and do you know how many tools there
are? I can't even count them all. I think it rivals the number of tools
available for Java. I went to get some tools for building some drawers
and I might have to file for bankruptcy.
> Sometimes the
> technology du jour isn't appropriate.
I don't think it's just the technology du jour. I think there's something
there. I think (maybe) that it's addressing symptoms of a problem and
not the problem itself. And I think the problem is a lot of really bad ideas
that were considered 'best practices' not that long ago. And perhaps
some limitations of Java that are becoming tiresome. If I had to pick
between Spring and Hibernate or EJB 2, I would choose Spring in
a heartbeat. I'm not yet convinced I'd choose EJB 3 over Spring.
I'm just not sure I need any of it at this point.
> I went to get some tools for building some drawers and I might have to file for bankruptcy.:o)~
> I'm getting into woodworking and do you know how many
> tools there are?
Funnily enough I once had a summer job working in a hardware store. So I've a notion. I used to know what they were all called and hadn't the faintest idea what half of them were for. I've had IT managers like that, so I guess what goes around comes around...
D.
