Re: [ANNOUNCEMENT] Apache Commons DBCP 2.10.0
Thanks, Greg. I assume that dependency was there and working with DBCP
2.9, correct?
Can you try reverting the pom change above, replacing the
Jakarta transactions reference with
org.apache.geronimo.specs
geronimo-jta_1.1_spec
1.1.1
true
Then recompile DBCP from 2.10 sources and test (just use mvn clean package
from the root of an extract of the source distribution).
Phil
On Mon, Sep 25, 2023 at 12:44 AM Greg Huber wrote:
> >> does your code maybe bring in the 2.0 jakarta spec jar?
>
> I do have :
>
> jakarta.transaction-api-2.0.1.jar
>
> which comes from hibernate-core 6.3.1.Final.
>
>
>
> ###
>
> Using eclipse here are the errors
>
> The project was not built since its build path is incomplete. Cannot
> find the class file for jakarta.transaction.Synchronization. Fix the
> build path then try building this project
>
> The type jakarta.transaction.Synchronization cannot be resolved. It is
> indirectly referenced from required type
> org.hibernate.context.internal.ThreadLocalSessionContext.CleanupSync
>
>
> Here is the class that won't compile
>
> public class ThreadLocalSessionContextNoAutoClose
> extends ThreadLocalSessionContext {
>
> private static final long serialVersionUID = -9220338553393731611L;
>
> /**
> * Create a new instance.
> *
> * @param factory The SessionFactoryImplementor
> required by the
> *super constructor.
> */
> public ThreadLocalSessionContextNoAutoClose(
> SessionFactoryImplementor factory) {
> super(factory);
> }
>
> /**
> * Returns false to prevent auto closing.
> *
> * @return false to prevent auto closing.
> */
> protected boolean isAutoCloseEnabled() {
> return false;
> }
>
> /**
> * Returns false to prevent auto flushing.
> *
> * @return false to prevent auto flushing.
> */
> protected boolean isAutoFlushEnabled() {
> return false;
> }
>
> /**
> * Uses super.buildOrObtainSession(), then sets the
> resulting
> * Session's flush mode to FlushMode.NEVER
> to
> * prevent auto-flushing.
> *
> * @return A session configured with FlushMode.NEVER.
> */
> protected Session buildOrObtainSession() {
> Session s = super.buildOrObtainSession();
> s.setHibernateFlushMode(FlushMode.MANUAL);
> return s;
> }
>
> /**
> * Returns an instance of CleanupSynch which prevents
> auto
> * closing and unbinding.
> *
> * @return A CleanupSynch which prevents auto closing and
> * unbinding.
> */
> protected CleanupSync buildCleanupSynch() {
> return new NoCleanupSynch(factory());
> }
>
> /**
> * A simple extension of CleanupSynch that prevents
> any cleanup
> * from happening. No session closing or unbinding.
> */
> private static class NoCleanupSynch
> extends ThreadLocalSessionContext.CleanupSync {
>
> private static final long serialVersionUID =
> -6191453375299821467L;
>
> /**
> * Creates a new instance based on the given factory.
> *
> * @param factory The required SessionFactory that is
> *passed to the super constructor.
> */
> public NoCleanupSynch(SessionFactory factory) {
> super(factory);
> }
>
> /**
> * Does nothing, thus helping to prevent session closing and/or
> * unbinding.
> */
> public void beforeCompletion() {
> // do nothing
> }
>
> /**
> * Does nothing, thus helping to prevent session closing and/or
> * unbinding.
> *
> * @param i
> */
> public void afterCompletion(int i) {
> // do nothing
> }
> }
>
> }
>
> Thanks.
>
> On 24/09/2023 20:34, Phil Steitz wrote:
> > On Sun, Sep 24, 2023 at 10:28 AM Greg Huber wrote:
> >
> >> Forgot to add, I use hibernate 6.
> >>
> > I suspect this is a side effect of the change to use the jakarta spec jar
> >
> > In 2.10, we have
> >
> >
> > jakarta.transaction
> > jakarta.transaction-api
> > 1.3.1
> >
> >
> > vs
> >
> >
> >org.apache.geronimo.specs
> >geronimo-jta_1.1_spec
> >1.1.1
> >true
> >
> >
> > in 2.9. What I don't get is where Greg's code is picking
> > up jakarta.transaction.Synchronization because the jakarta version we
> > "upgraded" to still exports the javax classes and these are what dbcp
> > uses. Greg - does your code maybe bring in the 2.0 jakarta spec jar?
> >
> > Phil
> >
> >
> >> Cheers.
> >>
> >> On Sun, 24 Sept 2023 at 12:49, Gary Gregory
> >> wrote:
> >>
> >>> What else has changed in your app?
> >>>
> >>> Gary
> >>>
> >>> On Sun, Sep 24, 2023 at 5:13 AM Greg Huber
> wrote:
>
Re: Jxpath getting stuck on trying to do a getValue
Not really in a way that makes sense for a publicly archived ML like this,
IMO. If you can "boil it down" to the essence of the problem you should be
able to convey the example without revealing anything private.
Alternatively, you can debug it yourself. If you want to report any problem
you find in this manner you'd still need to boil it down later but as
support is not guaranteed in community-run open source, DIY is always best.
Matt
On Mon, Sep 25, 2023, 12:23 AM Debraj Manna
wrote:
> I can share a reproducible project but I would like to avoid doing it in a
> public link like in GitHub, etc. Is there a way to do that?
>
> On Mon, 25 Sep, 2023, 01:10 Matt Benson, wrote:
>
> > TBH I'm somewhat surprised it doesn't already, but I haven't actually
> > ran/debugged your example.
> >
> > On Sun, Sep 24, 2023 at 2:32 PM Debraj Manna
> > wrote:
> >
> > > Is there a way I can throw some error from jxpath when this situation
> > > arises instead of getting stuck in a never ending loop?
> > >
> > > On Sun, 24 Sep, 2023, 22:54 Matt Benson, wrote:
> > >
> > > > Well, to be clear, you can have linked nodes. But if N had both
> `next`
> > > and
> > > > `previous` members is where you'd run into trouble.
> > > >
> > > > On Sun, Sep 24, 2023 at 12:22 PM Matt Benson
> > > wrote:
> > > >
> > > > > If you're doing a search down the tree you'd need some way to keep
> > > JXPath
> > > > > from traversing these relationships, yes.
> > > > >
> > > > > On Sun, Sep 24, 2023 at 11:59 AM Debraj Manna <
> > > subharaj.ma...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Are you saying that in JxPath we cannot use something like below?
> > > > >>
> > > > >> class A {
> > > > >> int n;
> > > > >> A next;
> > > > >> }
> > > > >>
> > > > >> On Sun, Sep 24, 2023 at 8:43 PM Matt Benson
> > > wrote:
> > > > >>
> > > > >> > Is it possible the proto message (I'm not familiar with this
> API)
> > is
> > > > >> built
> > > > >> > with internal recursive references, i.e. some child has a
> property
> > > > that
> > > > >> > points, possibly indirectly, to its parent? That would be the
> most
> > > > >> probable
> > > > >> > explanation, particularly as you say feeding jxpath the known
> > > absolute
> > > > >> path
> > > > >> > works.
> > > > >> >
> > > > >> > Matt
> > > > >> >
> > > > >> > On Sun, Sep 24, 2023, 9:44 AM Debraj Manna <
> > > subharaj.ma...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > It looks like it is getting stuck in some infinite loop. The
> > > thread
> > > > >> stack
> > > > >> > > looks like below after ~ 8 hours from the start.
> > > > >> > >
> > > > >> > > main Runnable CPU usage on sample: 979ms
> > > > >> > > jdk.internal.reflect.GeneratedMethodAccessor640.invoke()
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > >> > > java.lang.reflect.Method.invoke(Method.java:568)
> > > > >> > >
> > > > >>
> > > org.apache.commons.jxpath.util.ValueUtils.getValue(ValueUtils.java:367)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getBaseValue(BeanPropertyPointer.java:120)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getImmediateNode(BeanPropertyPointer.java:149)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> org.apache.commons.jxpath.ri.model.beans.PropertyPointer.getImmediateValuePointer(PropertyPointer.java:161)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> org.apache.commons.jxpath.ri.model.NodePointer.getValuePointer(NodePointer.java:297)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> org.apache.commons.jxpath.ri.model.beans.PropertyIterator.getNodePointer(PropertyIterator.java:121)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> org.apache.commons.jxpath.ri.axes.DescendantContext.nextNode(DescendantContext.java:115)
> > > > >> > >
> > > > >>
> > > org.apache.commons.jxpath.ri.EvalContext.nextSet(EvalContext.java:349)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> org.apache.commons.jxpath.ri.axes.ChildContext.getSingleNodePointer(ChildContext.java:70)
> > > > >> > >
> > > > >>
> > > org.apache.commons.jxpath.ri.compiler.Path.searchForPath(Path.java:201)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> org.apache.commons.jxpath.ri.compiler.Path.getSingleNodePointerForSteps(Path.java:176)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> org.apache.commons.jxpath.ri.compiler.LocationPath.computeValue(LocationPath.java:87)
> > > > >> > >
> > > > >> > >
> > > >
Re: [ANNOUNCEMENT] Apache Commons DBCP 2.10.0
>> does your code maybe bring in the 2.0 jakarta spec jar?
I do have :
jakarta.transaction-api-2.0.1.jar
which comes from hibernate-core 6.3.1.Final.
###
Using eclipse here are the errors
The project was not built since its build path is incomplete. Cannot
find the class file for jakarta.transaction.Synchronization. Fix the
build path then try building this project
The type jakarta.transaction.Synchronization cannot be resolved. It is
indirectly referenced from required type
org.hibernate.context.internal.ThreadLocalSessionContext.CleanupSync
Here is the class that won't compile
public class ThreadLocalSessionContextNoAutoClose
extends ThreadLocalSessionContext {
private static final long serialVersionUID = -9220338553393731611L;
/**
* Create a new instance.
*
* @param factory The SessionFactoryImplementor
required by the
* super constructor.
*/
public ThreadLocalSessionContextNoAutoClose(
SessionFactoryImplementor factory) {
super(factory);
}
/**
* Returns false to prevent auto closing.
*
* @return false to prevent auto closing.
*/
protected boolean isAutoCloseEnabled() {
return false;
}
/**
* Returns false to prevent auto flushing.
*
* @return false to prevent auto flushing.
*/
protected boolean isAutoFlushEnabled() {
return false;
}
/**
* Uses super.buildOrObtainSession(), then sets the
resulting
* Session's flush mode to FlushMode.NEVER to
* prevent auto-flushing.
*
* @return A session configured with FlushMode.NEVER.
*/
protected Session buildOrObtainSession() {
Session s = super.buildOrObtainSession();
s.setHibernateFlushMode(FlushMode.MANUAL);
return s;
}
/**
* Returns an instance of CleanupSynch which prevents auto
* closing and unbinding.
*
* @return A CleanupSynch which prevents auto closing and
* unbinding.
*/
protected CleanupSync buildCleanupSynch() {
return new NoCleanupSynch(factory());
}
/**
* A simple extension of CleanupSynch that prevents
any cleanup
* from happening. No session closing or unbinding.
*/
private static class NoCleanupSynch
extends ThreadLocalSessionContext.CleanupSync {
private static final long serialVersionUID = -6191453375299821467L;
/**
* Creates a new instance based on the given factory.
*
* @param factory The required SessionFactory that is
* passed to the super constructor.
*/
public NoCleanupSynch(SessionFactory factory) {
super(factory);
}
/**
* Does nothing, thus helping to prevent session closing and/or
* unbinding.
*/
public void beforeCompletion() {
// do nothing
}
/**
* Does nothing, thus helping to prevent session closing and/or
* unbinding.
*
* @param i
*/
public void afterCompletion(int i) {
// do nothing
}
}
}
Thanks.
On 24/09/2023 20:34, Phil Steitz wrote:
On Sun, Sep 24, 2023 at 10:28 AM Greg Huber wrote:
Forgot to add, I use hibernate 6.
I suspect this is a side effect of the change to use the jakarta spec jar
In 2.10, we have
jakarta.transaction
jakarta.transaction-api
1.3.1
vs
org.apache.geronimo.specs
geronimo-jta_1.1_spec
1.1.1
true
in 2.9. What I don't get is where Greg's code is picking
up jakarta.transaction.Synchronization because the jakarta version we
"upgraded" to still exports the javax classes and these are what dbcp
uses. Greg - does your code maybe bring in the 2.0 jakarta spec jar?
Phil
Cheers.
On Sun, 24 Sept 2023 at 12:49, Gary Gregory
wrote:
What else has changed in your app?
Gary
On Sun, Sep 24, 2023 at 5:13 AM Greg Huber wrote:
Hello,
On upgrading from 2.9.0 I get this message and my class won't compile.
I get this error
The type jakarta.transaction.Synchronization cannot be resolved. It is
indirectly referenced from required type
org.hibernate.context.internal.ThreadLocalSessionContext.CleanupSync
I am on :
openjdk version "11.0.19" 2023-04-18 LTS
OpenJDK Runtime Environment Zulu11.64+19-CA (build 11.0.19+7-LTS)
OpenJDK 64-Bit Server VM Zulu11.64+19-CA (build 11.0.19+7-LTS, mixed
mode)
Not too sure what I need to do to fix this.
Cheers
On 03/09/2023 22:51, Gary Gregory wrote:
The Apache Commons DBCP team is pleased to announce the release of
Apache Commons DBCP 2.10.0.
Apache Commons DBCP software implements Database Connection Pooling.
This is a minor release, including bug fixes and enhancements:
https://commons.apache.org/proper/commons-dbcp/changes-report.html#a2.10.0
For complete information on Apache Commons DBCP, including
