spring-projects/spring-boot

Spring Boot

Niels Doucet

@NielsDoucet

the error resulting from this combination of libraries is: java.lang.IllegalAccessError: org.glassfish.jersey.jetty.JettyHttpContainerFactory$JettyConnectorThreadPool.newThread(Ljava/lang/Runnable;)Ljava/lang/Thread;

Stéphane Nicoll

@snicoll

@NielsDoucet Thanks for the feedback. An incompatiblity is more a bug than a dependency upgrade request. If you can provide more details, we’d like an issue please

Niels Doucet

@NielsDoucet

will do, thanks :+1:

Daniil Gaidukov

@danzik

Hi! I have a few SpringBootTest's, but I'm not sure that it good approach create applicationcontext for each class annotated @SpringBootTest. Could anyone explain why we should create each time context/ use only one?

boda2004

@boda2004

to eliminate influence of previous tests

so you get clean environment for each test

James Howe

@OrangeDog

within a test class it reuses the environment unless @DirtiesContext

it's assumed that separate @SpringBootTest classes will want different configurations

Ingo Griebsch

@ingogriebsch

Hi all, I want to test a special flyway migration step. I implemented a flyway callback and integrated it into Flyway. So far so good. Know I want to implement some tests to check how the migration works a) if the database is empty, b) if the database is not yet migrated, c) if the database was already migrated. Therefore I started to implement a @JdbcTest using a posgres-testcontainer. The env is so far working, the only problem I have is to find a place where I can prepare the database for the different cases. Therefore I'm searching for a place I could hook into to execute some sql files/statements before Flyway is getting executed. All things I tried (spring.datasource.data, spring.flyway.initSqls etc) are not working (i.e. a triggered to late). Has someone a hint how to implement such a test? :)

aghag10

@aghag10

Hello! I'm seeing some issues with a class (class A) marked with Configurable annotation autowiring another class. Class A is being manually instantiated by Class X that's not Spring managed. Class A is autowiring class B. There is a delay in the instantiation order of Class A and class B. As a result, we end up hitting an NPE in class A, when it tries to invoke a method in class B. I tried debugging the issue to see in what order the 2 classes are being instantiated. I'm seeing two issues here - 1) post construct method in class A is never called 2) post construct method in class B is being called 2-3 minutes after I see a log message from an init function in class A. I've tried setting @Configurable(preconstruct = true, autowire=Autowire.BY_NAME), but no luck. Any comments/suggestions?
@aghag10 1) try to instantiate your class A by Spring itself. 2) don't use @Autowire on property private ClassB classB, turn it out to ClassA's constructor param.

@bvn13 1) I can't make class A spring managed since class X that's instantiating class A can not be made Spring managed. 2) I don't follow. If that's the case, class B won't be autowired anymore?

Vyacheslav N. Boyko

@bvn13

Hello! I'm seeing some issues with a class (class A) marked with Configurable annotation autowiring another class. Class A is being manually instantiated by Class X that's not Spring managed. Class A is autowiring class B. There is a delay in the instantiation order of Class A and class B. As a result, we end up hitting an NPE in class A, when it tries to invoke a method in class B. I tried debugging the issue to see in what order the 2 classes are being instantiated. I'm seeing two issues here - 1) post construct method in class A is never called 2) post construct method in class B is being called 2-3 minutes after I see a log message from an init function in class A. I've tried setting @Configurable(preconstruct = true, autowire=Autowire.BY_NAME), but no luck. Any comments/suggestions?
@aghag10 1) try to instantiate your class A by Spring itself. 2) don't use @Autowire on property private ClassB classB, turn it out to ClassA's constructor param.

@bvn13 1) I can't make class A spring managed since class X that's instantiating class A can not be made Spring managed. 2) I don't follow. If that's the case, class B won't be autowired anymore?

1) I got it. 2) This way - yes. But I've found an example of how to get spring bean from outside of spring-managed zone https://confluence.jaytaala.com/display/TKB/Super+simple+approach+to+accessing+Spring+beans+from+non-Spring+managed+classes+and+POJOs

Witold Kupś

@Azbesciak

@boda2004 the problem is that that nginx is not mine - I am using this API, only. And pay for it...

Alexander Wilhelmer

@awilhelmer

WTF http://repo.spring.io/libs-snapshot/ro/isdc/wro4j/gradle/wro4j-gradle-plugin/1.8.0.Beta4/wro4j-gradle-plugin-1.8.0.Beta4.jar cannot import Projects anymore!?

20min ago it worked ...

Ibanga Enoobong Ime

@IEnoobong

use https?

Alexander Wilhelmer

@awilhelmer

apply plugin: 'wro4j' <--- how?

Stéphane Nicoll

@snicoll

@awilhelmer nothing to do with the plugin but rather the repositories you’ve defined in your build. Check the Gradle forum for more help on that

repo.spring.io does not service requests on http anymore

nightswimmings

@nightswimmings

Hi! Does anybody know how can I force all nested transactions within a method to use its very same parent transactionManager? nested transactions com from dependencies annotated with @transactional, which ends up being binded to the @Primary TransactionManager, not the one declared in my parent method

nightswimmings

@nightswimmings

The weird thing is that theres no propagation specified, so I would have guessed that Propagation=REQUIRED adopted by all means parent transaction, including its transactionmanager

nightswimmings

@nightswimmings

Observing this, https://github.com/spring-projects/spring-framework/blame/cef4478b7b917033a8a01a6e633f6f59aab67e59/spring-tx/src/main/java/org/springframework/transaction/interceptor/TransactionAspectSupport.java#L449, which hasnt been changed in 3 years, I assume that's the expected behavior:
evaluation of transactionmanager is done on each @Transactional and it's orthogonal to propagation type

James Howe

@OrangeDog

You need a primary transaction manager that understands multiple transaction managers

otherwise the individual managers have no way to know about each others' transactions

or make sure you always specify the right one in @Transactional

Konstantin Bläsi

@konstantinblaesi

can I make spring log the final configuration values (multiple sources, profiles merged) ?

James Howe

@OrangeDog

@konstantinblaesi probably one of the actuators will report what you want (configprops, env)

nightswimmings

@nightswimmings

@OrangeDog The thing is I dont need to understand multiples, I always specify it, but I cannot modify the third-party lib, so I am looking for a way to specify the txManager for the dependency or either exclude it at all as a last resort

James Howe

@OrangeDog

What I said is still correct. Your primary manager will need some logic to decide which of the others it should delegate to (e.g. the one with a current transaction)

Konstantin Bläsi

@konstantinblaesi

@OrangeDog I checked configprops, very cool thanks :)

nightswimmings

@nightswimmings

@OrangeDog sorry, I am having difficulties to understand what you describe but I am forgetting something for sure. If I go to the third-party library, delete or edit the @Transactional annotation to use same txmanager than mylib, then at what point theres delegation?

James Howe

@OrangeDog

I am assuming you don't want to or cannot edit the third-party library

nightswimmings

@nightswimmings

exactly, but this is the behavior Id like to imitate, if i manage to do that, then do I need to do a composed manager?

if only I could do a @Transactional(propagation=ignoresubtransactions) or either something like @EnableTransactional(exclude=third-party.class)

and that is assuming that the current and expected behavior is that upon propagation=REQUIRED, transaction does support parent transaction but not parent's transactionmanager which I don't see it obvious at all

James Howe

@OrangeDog

You need a primary transaction manager that understands multiple transaction managers or make sure you always specify the right one in @Transactional

What the aspect does is determine what transaction manager to call around the method. It doesn't do any tracking of transactions or managers itself.

A third option is a custom aspect that looks at the method's class/package to decide which transaction manager to use, but IMO that's more messy.

none of which has anything to do with propagation

nightswimmings

@nightswimmings

all the solutions seem no trivial for a hotfix then :'(...

Are we sure theres no mechanism for marking a bean as not qualifiable to support transactions? I mean something like @EnableTransactions(exclude=thirdparty.class). I need the bean to be managed, but I want the @Transactional to be ignored

Anyway, thanks for your help james

James Howe

@OrangeDog

there is not

perhaps you could do something really hacky with Bean(Definition)PostProcessors but the other solutions are all easier

aghag10

@aghag10

@bvn13 Thanks. I'll give that a shot.

bjonnh

@bjonnh

I have two models (kotlin data classes) linked through a manytomany relationship (pg database)

when I want to do A.allofB.size where allofB is the manytomany field that link A to B (through a join table)

I get in infinite recursion

I've dealt with infinite recursion when serializing my data (Json), but in that case I am not serializing anything…

(and the two manytomany sides are LAZY)

If I remove the manytomany field on the class B, then I can run that (but I cannot find all the A linked to an object B from an object of type B)

Where communities thrive

People

Repo info

Activity