rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-842274511
Up, still an issue with 3.2.0
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-842274511
Up, still an issue with 3.2.0
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-717288578
up, forgot to mention option 3. don't protect over this since it shouldn't
happen in several PCClassFileTransformer cases (all but agent one?). Otherwise
if protection is still
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-699522667
up, i'd like it to be fixed for 3.1.3
current options are:
1. a threadlocal toggle which is likely to work has the drawback to make the
impl context dependent
2.
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-663183133
@dazey3 oki, the fact you can't be in transform from transform is only true
for a javaagent called from defineClassX, not from a custom classloader
handling the transformation i
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-663085420
@dazey3 yep, the one mentionned on the list and the PRs:
tmploader==apploader. The toggle just disable enhancement under some setups
(close to openliberty ones where the load cl
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-662846369
@struberg right, this is where the exclude list is likely faster than the
end of the method but functionally it should just be fine.
---
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-662842764
Hmm, a kind of double lock check on a volatile boolean? Think it makes more
sense actually. Judt needs to bench the exclude list vs isEnhanced speed at
runtime - would need to r
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-662824173
@dazey3 not really, the concurrency is an issue on top of an original issue.
The toggle never worked reliably whereas the exclusion list always worked until
you plug custom impl
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-658559477
@struberg agree on A, B is true but likely slower than this exclusion list
(even if not sexy it is faster than a hashset in most cases and consumes way
less constant mem ;)), C
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-658353355
@jgrassel yes it violates but it is important to have it when startup time
is needed otherwise you basically potentially load all your app twice for
nothing (or load it all in m
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-658338171
@jgrassel The threadlocal - as the boolean today - just skips the
transformer, so it means that if a class must be enhanced and is loaded while
another is enhanced then it is sk
rmannibucau commented on pull request #65:
URL: https://github.com/apache/openjpa/pull/65#issuecomment-658324978
@jgrassel commons is excluded and the jdk as well, just to skip reading the
bytecode (which is more costly than this exclusion list if you benchmark both
options so overall the
13 matches
Mail list logo
