I think it's great idea to have this built-in. At work, I'm not
able to upgrade our hibernate version (2.0) since I can't upgrade our
xdoclet (still at 1.2b2) since we're using a few things that are not
supported and it keeps going in circle.
By the way, Hibernate is great!
--- Les Hazlewoo
> Oh, looking back at your original code, it seems like Tomcat lets you
> bind a Reference to an ObjectFactory in the webapp.xml. This is
> tomcat-specific stuff, by the looks.
>
> Oh, now I remember! Tomcat has a read-only JNDI server, doesn't it? That
> is why you had trouble? Why don't you j
Title: Message
I'm
answering my own question:
JSR-175 is a good idea for common support by tools and
compile-time checking. This is definitely better than "write my xdoclet
tags, deploy, and see if it worked".
Les
-Original Message-From: Les Hazlewood
Sent: Wednesday, Ap
On 07 Apr (13:04), John J. Allison wrote:
> Well, I'm open to suggestions, but there are alot of people using
> plain old Tomcat and it'd be nice if this stuff just worked with
> Tomcat & Hibernate & JNDI.
Why? The only benefit would be a SessionFactory in JNDI, why do we need
this exactly? It's
Oh, looking back at your original code, it seems like Tomcat lets you
bind a Reference to an ObjectFactory in the webapp.xml. This is
tomcat-specific stuff, by the looks.
Oh, now I remember! Tomcat has a read-only JNDI server, doesn't it? That
is why you had trouble? Why don't you just get a re
Title: Message
What
is the benefit of this over XDoclet tags? I find the XDoclet tags already
in use _much_ easier to read and understand than these Any reason for
supporting JSR-175 other than "its cool cause now the JDK will support
it"? The only benefit I can see is that JSR-175 su
> U ... as per the Hibernate documentation:
>
> new Configuration().configure().buildSessionFactory()
>
> will instantiate a SessionFactory and bind its Reference to JNDI and
> register it with the ObjectFactory.
>
It works by calling "new SessionFactoryImpl" which calls
SessionFactoryObje
Hit the wrong reply and didn't Cc: the list on this.
Of course if this is boring, somebody tell me to shut up.
> Sorry, I simply do not buy that DBCP dynamically instantiates a new
> datasource when you lookup against an unbound name! There is a
> connection pool already configured, and a refere
Sorry, I simply do not buy that DBCP dynamically instantiates a new
datasource when you lookup against an unbound name! There is a
connection pool already configured, and a reference already bound to
JNDI. Clearly.
AFAIK, the correct behavior if I attempt to lookup() an unbound name is
always
U ... as per the Hibernate documentation:
new Configuration().configure().buildSessionFactory()
will instantiate a SessionFactory and bind its Reference to JNDI and
register it with the ObjectFactory.
Who else but SessionFactoryObjectFactory, which implements ObjectFactory?
Who else is doin
I'm afraid that I have to say your reading of the JNDI spec is mistaken.
Keep
reading further down into that JavaDoc, where it makes quite clear that the
ObjectFactory is responsible for creating objects for References that were
/already bound to a name/, ie. exactly how Hibernate is doing it now.
> I'm afraid that I have to say your reading of the JNDI spec is mistaken.
Fair enough, could be.
> Keep
> reading further down into that JavaDoc, where it makes quite clear that the
> ObjectFactory is responsible for creating objects for References that were
> /already bound to a name/, ie. exac
> Please note that this new code module added added as a part of Middlegen
> 2.1 we are working on at the moment. Its an improvement on the old demo
> application that had an EJB backend that we have supplied with previous
> versions of the tool. Since this is only in CVS it is likely to not be
> This is absolutely correct behavior. SessionFactoryObjectFactory is
> meant to return already-bound session factories.
>
> John J. Allison wrote:
>
> >Poking around, I noticed that SessionFactoryObjectFactory never
> >actually creates a SessionFactory. When getObjectInstance() is
> >called, th
Don't forget that Metadata are partly checked at compile time and *that*
is very helpful.
It is true that complex classes will be harder to read due to
declarative / code mix, but I believe it will be more readable than
HibernateDoclet tags.
I'm for now a big fan of hbms because it's very synthe
On 08 Apr (00:44), Gavin King wrote:
> pain, especially since my IDE can't help me. Note also that we reduce
> total LOC,
> since more info can be inferred from the context of the annotation.
I agree with that, my problem is really very pragmatic: Suppose I have a
mapping for my Oracle and one f
On 07 Apr (16:30), Emmanuel Bernard wrote:
> Here is a simple example which widely use default values of each
> annotations, and thus not expressed (actually hbm does the same).
I haven't read the spec fully, but what is the point of this annotation
stuff anyway? It's not like putting metadata i
Depends whether you really view the mapping information as meta-source.
I just think it is "declarative source". I don't see it as necessarily
"meta"
anything. This language feature just gives Java a new declarative syntax
that
can be mixed with the usual procedural style.
Don't mix source and m
I disagree. It is an ease-of-use feature. It is just soo much easier
when everything
is in one place. cross-referencing between mappings and sourcecode is
always a
pain, especially since my IDE can't help me. Note also that we reduce
total LOC,
since more info can be inferred from the context of
Here is a simple example which widely use default values of each
annotations, and thus not expressed (actually hbm does the same).
package org.hibernate.test.metadata;
// annotation import
import net.sf.hibernate.annotation.ClassAnn;
import net.sf.hibernate.annotation.IdAnn;
import net.sf.hib
Fantastic :) Hey, can you show us an example of an annotated class?
Emmanuel Bernard wrote:
After been convinced by Max, I've commited it into
HibernateExt/metadata (HEAD)
To build it :
- use the JDK 1.5
- build an hibernate2.2 dist in the dir containing HibernateExt
Usually
|-
After been convinced by Max, I've commited it into HibernateExt/metadata
(HEAD)
To build it :
- use the JDK 1.5
- build an hibernate2.2 dist in the dir containing HibernateExt
Usually
|- Hibernate2 (taken from CVS - v22branch)
|- HibernateExt (taken from CVS - HEAD)
This is absolutely correct behavior. SessionFactoryObjectFactory is
meant to return already-bound session factories.
John J. Allison wrote:
Poking around, I noticed that SessionFactoryObjectFactory never
actually creates a SessionFactory. When getObjectInstance() is
called, that's what Tomcat ex
John et al,
Please note that this new code module added added as a part of Middlegen
2.1 we are working on at the moment. Its an improvement on the old demo
application that had an EJB backend that we have supplied with previous
versions of the tool. Since this is only in CVS it is likely to no
24 matches
Mail list logo
