+1
On Tue, Jul 7, 2020 at 5:55 AM Sanne Grinovero wrote:
> +1 Great idea
>
> On Tue, 7 Jul 2020 at 13:15, andrea boriero wrote:
> >
> > Hi all,
> >
> > Last year the Bytecode enhancement as proxy feature was introduced (see
> > https://in.relation.to/2019/07/30/bytecode-proxy/ for details) and
+1 Great idea
On Tue, 7 Jul 2020 at 13:15, andrea boriero wrote:
>
> Hi all,
>
> Last year the Bytecode enhancement as proxy feature was introduced (see
> https://in.relation.to/2019/07/30/bytecode-proxy/ for details) and the
> hibernate.bytecode.allow_enhancement_as_proxy was added to enable/dis
Hi all,
Last year the Bytecode enhancement as proxy feature was introduced (see
https://in.relation.to/2019/07/30/bytecode-proxy/ for details) and the
hibernate.bytecode.allow_enhancement_as_proxy was added to enable/disable
the new feature.
In ORM 5.3 and 5.4 versions this feature is disabled by
Hi Luis,
On Mon, Jun 11, 2018 at 9:39 PM Luis Barreiro wrote:
> Can you please check the behavior of with the Javassist enhancer in this
> particular case? I believe it's the correct one, but one has to double
> check.
>
>From my tests, the behavior is exactly the same with Javassist.
--
Guil
Hi Guillaume,
Can you please check the behavior of with the Javassist enhancer in this
particular case? I believe it's the correct one, but one has to double
check.
Also, on a related issue, please check the comments I made on
https://hibernate.atlassian.net/browse/HHH-12593 about property acc
Hi Luis,
This question is related to https://hibernate.atlassian.net/browse/HHH-12601
.
AFAICS, the following case (e.g. having the fields defined in the parent
class and the laziness defined in the child class) is not working very well
with bytecode enhancement:
@Entity
public class Request
Per the discussion Luis and I had on IRC we will go with the prefix
"hibernate.enhancer..". "enhancer" makes it more than clear what the
intended target is.
On Fri, Dec 4, 2015 at 4:50 AM Sanne Grinovero wrote:
> Hi Luis,
> thanks for this proposal, I was looking forward to see more
> improvem
I think that document only landed on 5.1 because lazy groups is 5.1 only.
Docs for 5.0 (and these are just on how to use the build-time plugins)
are in a different place:
documentation/src/main/asciidoc/topical/bytecode/BytecodeEnhancement.adoc
On 12/04/2015 12:58 PM, Steve Ebersole wrote:
> Lu
Luis, I am trying to remember if there is any reason I only added this to
master (5.1). Was there a reason to not add it to 5.0 as well? Aside from
the parts about lazy groups that is :)
On Fri, Dec 4, 2015 at 6:28 AM Steve Ebersole wrote:
> On Fri, Dec 4, 2015 at 5:43 AM Steve Ebersole wrot
On 4 December 2015 at 12:32, Vlad Mihalcea wrote:
> I investigated this issue:
>
> On master it's all fine:
>
>
>
>
>
>
>
>
> but the 5.0.5 tag didn't declare the Bytecode chapter:
>
>
>
>
>
>
>
>
> Vlad
That's great, thanks! Now I might play with it too :)
Sa
I investigated this issue:
On master it's all fine:
but the 5.0.5 tag didn't declare the Bytecode chapter:
Vlad
On Fri, Dec 4, 2015 at 1:43 PM, Steve Ebersole wrote:
> On Fri, Dec 4, 2015 at 4:50 AM Sanne Grinovero
> wrote:
>
> > Hi Luis,
> > thanks for
On Fri, Dec 4, 2015 at 5:43 AM Steve Ebersole wrote:
> Hm, there is a problem in the doc generation apparently :( For some
> reason this chapter is not pulled in
> https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/docbook/userGuide/en-US/chapters/enhancement/BytecodeE
This all sounds good to me. For runtime enhancement I am ok with
deprecating that setting, as long as in the meantime until its removal we
continue to treat it as enabling all the enhancement features in addition
to logging that warning.
On Fri, Dec 4, 2015 at 12:29 AM Luis Barreiro wrote:
> Hi
On Fri, Dec 4, 2015 at 4:50 AM Sanne Grinovero wrote:
> Hi Luis,
> thanks for this proposal, I was looking forward to see more
> improvements in the area.
>
> Adding more properties sounds good to me, although I'd not use the
> prefix "hibernate.enhance" as it sounds like it's about enhancing
> H
Hi Luis,
thanks for this proposal, I was looking forward to see more
improvements in the area.
Adding more properties sounds good to me, although I'd not use the
prefix "hibernate.enhance" as it sounds like it's about enhancing
Hibernate - which might be true but one could say the same with many
o
I like the idea of having multiple properties to enable a particular
bytecode enhancement feature.
It could be that the clients want to speed-up dirty checking but they don't
really use the lazy initialization.
Vlad
On Fri, Dec 4, 2015 at 8:29 AM, Luis Barreiro wrote:
> Hi all,
>
> I would like
Hi all,
I would like to start a discussion to know what is the general opinion
about $subject, triggered by HHH- 10356.
I'm also taking the opportunity to hear about some considerations I have
on the configuration of the build-time plugins.
*
**
**- Run time*
Right now it is not possible t
That depends on the "allow lazy loading outside transaction" setting, much
like how the outcome of `myEntity.getChildren().size()` depends on same in
the proxy solution.
If that is allowed, then the call will build the collection (from a
"temporary Session", just like the proxy solution works) and
On 09/10/2015 09:45 AM, Steve Ebersole wrote:
> Wanted to get some opinions. I am working on HHH-10055 which is basically
> a report of problems with that "lazy loading outside of a
> session/transaction" feature when used in combination with bytecode
> enhancement. The initial problem was that
Wanted to get some opinions. I am working on HHH-10055 which is basically
a report of problems with that "lazy loading outside of a
session/transaction" feature when used in combination with bytecode
enhancement. The initial problem was that bytecode interception was not
accounting for collection
In working through the document overhaul I ran across the following passage
in the JPA specification:
The persistent state of an entity is represented by instance variables,
which may correspond to JavaBeans properties. An instance variable must be
directly accessed only from within the methods o
Hi Guillaume,
A Maven plugin for build time enhancement of entities is coded up.
Not without a few problems along the way. But I think we are there now.
Comments are in-lined with your questions.
There should be a plugin in the maven repo soon (if not now) using a
Mojo and the necessary des
Perhaps see if this can be of any use to you:
* https://github.com/alesj/maven-transformer-plugin
I'm using this as part of CapeDwarf's GAE jar transformation.
*
https://github.com/capedwarf/capedwarf-blue/blob/master/bytecode/src/main/java/org/jboss/capedwarf/bytecode/CapedwarfTransformerMojo.ja
On Wed, Mar 19, 2014 at 6:06 PM, Emmanuel Bernard
wrote:
> My comment about bytecode enhancement was at a time where Hibernate ORM
> did not make as much optimizations as it does now.
> In an ideal world, the bytecode enhancement is triggered at startup time
> like we do for Java EE. I am not sure
Hi,
I took a look at the bytecode enhancement Maven plugin and I also have
this issue https://hibernate.atlassian.net/browse/HHH-8833 .
As far as I can tell the Maven plugin (and I suppose the Gradle plugin
too) doesn't provide any information about the classpath so it's
impossible to use the byt
My comment about bytecode enhancement was at a time where Hibernate ORM
did not make as much optimizations as it does now.
In an ideal world, the bytecode enhancement is triggered at startup time
like we do for Java EE. I am not sure if that's doable in your
environment though.
On Wed 2014-03-19 1
> - has JBoss AS finally implemented the temporary class loaders required for
> runtime byte code enhancement (JPA contract)?
Yes, finally!
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-d
I need to catch up on this thread but wanted to mention that AS7-4996 is
the AS7 fix that rearranges application deployment phases if either
persistence unit property "hibernate.ejb.use_class_enhancer" or
"jboss.as.jpa.classtransformer" is true. This change is in the AS7
master (AS 7.2 target)
On 10/10/2012 02:26 AM, Emmanuel Bernard wrote:
> Yes my proposal would imply we pass along the cache data structure through
> all of our internal methods.
> My concerns about byte code enhancement are a bit diffuse but relate to:
>
> - does it add an extra build step to users?
No, we'd go all ou
Its not quite that simple, again due to how we recurse. This would
need to be a "stack" stored on a ThreadLocal. Depends what you want to
store in here I guess, but like I said we already have "context
specific caches" and it would be good to consolidate all that
information into one place.
On Wed 2012-10-10 9:26, Emmanuel Bernard wrote:
> Would using a service that store cache data structures by session work? I am
> thinking out loud here trying to push the cache idea before discarding it.
> That would require a weak-key concurrent map. The one I know is the one Jason
> wrote as
> Would using a service that store cache data structures by session work? I am
> thinking out loud here trying to push the cache idea before discarding it.
> That would require a weak-key concurrent map. The one I know is the one Jason
> wrote as a proposal for SE. I. Cannot remember where we u
Yes my proposal would imply we pass along the cache data structure through all
of our internal methods.
My concerns about byte code enhancement are a bit diffuse but relate to:
- does it add an extra build step to users?
- how much configuration is needed in SE?
- has JBoss AS finally implemente
The trouble is that you are glossing over where this "cache" comes from
and how it comes into play.
My original code was part of PersistenceContext (which is owned by
Session). You explicitly say yours is not; or more correctly you say
that in your code "cache" is call stack specific. So to m
If you have both the bytecode enhancement and the cache logic I am
talking about the code would look like this.
public EntityEntry getEntityEntry(Object entity) {
if ( isEnhanced( entity ) ) {
return ( (Enhanced) entity ).getEntityEntry();
}
int cacheIndex = cache.size-1;
if ( c
Well it does not keep track of EntityEntry specifically. It keeps
track of the replacements. But that is the point. We have quite a few
"context caches" already.
PersistenceContext was intended for this lookup. It just suffers from
a bad implementation of how that works atm.If I underst
On Tue 2012-10-09 10:30, Steve Ebersole wrote:
> On Tue 09 Oct 2012 09:57:12 AM CDT, Emmanuel Bernard wrote:
> >On Thu 2012-10-04 10:00, Steve Ebersole wrote:
> >>See https://hibernate.onjira.com/browse/HHH-7667
> >>
> >>I want to investigate expanding Hibernate's support for bytecode
> >>enhanceme
On Tue 09 Oct 2012 09:57:12 AM CDT, Emmanuel Bernard wrote:
> On Thu 2012-10-04 10:00, Steve Ebersole wrote:
>> See https://hibernate.onjira.com/browse/HHH-7667
>>
>> I want to investigate expanding Hibernate's support for bytecode
>> enhancement. I can see 3 main fronts to this:
>>
>> 1) offloadi
On Thu 2012-10-04 10:00, Steve Ebersole wrote:
> See https://hibernate.onjira.com/browse/HHH-7667
>
> I want to investigate expanding Hibernate's support for bytecode
> enhancement. I can see 3 main fronts to this:
>
> 1) offloading map lookups from the PersistenceContext . Currently we
> kee
On 4 Jan 2012, at 5:00 PM, Steve Ebersole wrote:
> Looking for input about how to best design this.
All three use cases seem useful. Right now I am not familiar enough with the
code to
give concrete design tips.
> First, is Javassist the best choice?
AFAIK it is still one of the most popula
See https://hibernate.onjira.com/browse/HHH-7667
I want to investigate expanding Hibernate's support for bytecode
enhancement. I can see 3 main fronts to this:
1) offloading map lookups from the PersistenceContext . Currently we
keep state associated with each entity in a map (a special type
41 matches
Mail list logo
