Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 09:19
    norio-io edited #20716
  • 09:15
    spring-issuemaster labeled #20716
  • 09:12
    norio-io opened #20716
  • 07:54
    snicoll commented #20702
  • 07:52
    snicoll milestoned #20715
  • 07:52
    snicoll edited #20715
  • 07:52
    snicoll labeled #20715
  • 07:52
    snicoll unlabeled #20715
  • 07:50
    snicoll edited #20715
  • 07:44
    mp911de commented #20702
  • Mar 28 22:30
    spring-issuemaster labeled #20715
  • Mar 28 22:28
    xp-vit opened #20715
  • Mar 28 20:55
    spring-issuemaster labeled #20714
  • Mar 28 20:55
    WalkingGhost1975 edited #20714
  • Mar 28 20:54
    WalkingGhost1975 edited #20714
  • Mar 28 20:53
    WalkingGhost1975 opened #20714
  • Mar 28 18:52
    Thinkenterprise commented #20524
  • Mar 28 18:41
    Thinkenterprise commented #20524
  • Mar 28 16:20
    adutra commented #20709
  • Mar 28 15:25
    snicoll milestoned #20713
James Howe
@OrangeDog
I imagine it depends on the container, if it's supported at all
Stéphane Nicoll
@snicoll
@jmanzaro you’d have more luck asking this on #spring-cloud
@bvn13 I don’t see what makes you think SB loads the config in random order (it doesn’t, that url points to the order we use for loading the config)
Jorge
@jmanzaro
@snicoll Ok, thanks!
Niels Doucet
@NielsDoucet
Hi, in spring-boot-dependencies version 2.2.2 the following incompatible libraries are being managed: org.eclipse.jetty:jetty-util:9.4.24.v2191120 and org.glassfish.jersey.containers:jersey-container-jetty-http:2.29.1
The incompatibility was fixed in jersey version 2.30 (see eclipse-ee4j/jersey@1504174)
Is this the right channel to report the issue? According to the github issue template I shouldn't raise an issue in github to upgrade a library.
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...
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)