It is nice, but it must be more usefull to refactor
default tuplizer. It is not trivial to replace proxy
factory implementation at this time (or user must fork
PojoTuplizer). Probably it is more usefull to replace
"LazyLoader" implementation than code generator:
public class MyTuplizerImpl extends
ax Andersen
Sent: Thursday, March 23, 2006 11:37 AM
To: Emmanuel Bernard; Steve Ebersole
Cc: Hibernate development
Subject: Re: [Hibernate] bytecode libraries
hmm, what defines a simplicist app ? If we had this "noop" bytecode
provider
it would basically be hibernate2 default behavior (la
ed to make/adapt.
-Original Message-
From: Max Andersen
Sent: Thursday, March 23, 2006 11:37 AM
To: Emmanuel Bernard; Steve Ebersole
Cc: Hibernate development
Subject: Re: [Hibernate] bytecode libraries
hmm, what defines a simplicist app ? If we had this "noop" bytecode
pr
Sure at some point. But this is still a new evolving API and too
volatile for exposure...
-Original Message-
From: Emmanuel Bernard [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 23, 2006 10:13 AM
To: Steve Ebersole
Cc: Hibernate development
Subject: Re: [Hibernate] bytecode libraries
hmm, what defines a simplicist app ? If we had this "noop" bytecode
provider
it would basically be hibernate2 default behavior (lazy="false") or
something close to it.
This would definitly make the startup much faster, but that would only be
noticable for
large projects that does not want
Any specific reason why
hibernate.bytecode.provider
does not consider the value as a class name (if the shortcuts cglib and
javassist are not resolved)?
That would solve your problem and put it to the users shoulders
Steve Ebersole wrote:
So now that we have the BytecodeProvider abstraction,
So now that we have the BytecodeProvider abstraction, does it make sense
to allow no lazy-load capabilities for simplistic apps? Something like
a NoOpBytecodeProvider which performs no type of class enhancement?
---
This SF.Net email is sponsor
