I've been having very hard time trying to make it work on my end. What I want to achieve is bringing up my spring-boot project that would weave all Java classes with AspectJ when I just run "java -jar app.jar" (Tomcat 8 embedded is used) without any Java agent params.
Is this generally possible? And if yes, what are the required config stuff that should be paid attention to?
Thanks a lot in advance.
It might be possible, but you would probably (at a minimum) need a custom main() method that created an LTW classloader and used that to launch your app. The default classloader in the java -jar would not be LTW-enabled. Any reason you don't want to use an agent (since you obviously control the launcher)?
Here a library that initializes aspectj and spring-aspects at runtime by injecting instrumentation: https://github.com/subes/invesdwin-instrument
You can use it as a sample.
Related
I am working on creating an internal library/starter for my team that will add support for creating native images, providing all of the hints that our currently unsupported dependencies will need. I really like providing the metadata via code (using RuntimeHintsRegistrar), but there are also certain classes that need to be initialized at build time for whatever reason.
Right now I'm passing the --initialize-at-build-time and the classes to the Spring Boot Maven Plugin via the BP_NATIVE_IMAGE_BUILD_ARGUMENTS, but ideally I'd like to avoid each consuming app having to include this in their own POM's plugin configuration.
I also understand that I can go more low-level and provide the argument inside of the META-INF/native-image directory in a native-image.properties file, but I'm not sure whether that will play nice with the Spring-provided RuntimeHintsRegistrar effectively creating that underneath the covers.
What is the best way to tell native-image the classes that should be initialized at build time without each consuming app having to pass it in their own POM? Also, if I use the GraalVM tracing agent to generate hints, will those hints play nicely with the ones that RuntimeHintsRegistrar generates?
Thanks in advance!
I noticed that there are only a few camel extensions available to use in native mode. I am wondering if it's still possible to use the other camel components if you don't compile to native? And if, is it usefull to go that way, or should we for example stick to spring boot?
Note that all Camel extensions might not need a Quarkus one. Basically, a Quarkus extension is needed if we need to tune the Camel extension for GraalVM (add reflection declarations for instance). The interesting thing is that you can even do the work manually to make your Camel extension work in GraalVM mode and then report back so that we create a proper extension for all future use.
In JVM mode, all Camel extensions should work flawlessly. If you encounter an issue, please open a GitHub issue and we will take a look at it.
About if using Quarkus in JVM mode is worth it, I'm obviously partial but I think the Quarkus approach is beneficial even in JVM mode. You still have some of the benefits of better boot time and reduced memory usage. Obviously, depending on your application, they might not be important to you.
Reading the Spring AOP documentation (link), I'm having a hard time (maybe also because english is not my native language) understanding these paragraphs.
First, I read
Further, in certain environments, this support enables load-time
weaving without making any modifications to the application server’s
launch script that is needed to add
-javaagent:path/to/aspectjweaver.jar or (as we describe later in
this section)
-javaagent:path/to/org.springframework.instrument-{version}.jar
(previously named spring-agent.jar).
And
Developers modify one or more files that form the application context
to enable load-time weaving
Which files? #Aspect classes and aop.xml files?
Then, when describing an example in the same sub-chapter, they say
We have one last thing to do. The introduction to this section did say
that one could switch on LTW selectively on a per-ClassLoader basis
with Spring, and this is true. However, for this example, we use a
Java agent (supplied with Spring) to switch on the LTW. We use the
following command to run the Main class shown earlier:
And they apply a Java Agent to the JVM.
-javaagent:C:/projects/foo/lib/global/spring-instrument.jar
Now I have a couple of doubts.
If I #EnableLoadTimeWeaving, do I need the spring-instrument Jar file as Java Agent?
I suppose the answer is yes, because we need to add bytecode to the class file before loading it. But a confirmation would be much appreciated.
The Jar naming is a little ambiguos, first they mention spring-agent.jar, then they use org.springframework.instrument-{version}.jar, and then spring-instrument.jar.
Are we always talking about the same Jar file?
I see from another question you asked that you are using Spring Boot and running a fat jar. In this case you don't need #EnableLoadTimeWeaving or spring-instrument (formerly known as spring-agent). Just ignore them if you are not running in an appserver for which you don't control the agent path.
I opened an issue for you about the confusion in the docs: https://github.com/spring-projects/spring-framework/issues/22429.
I currently have a Java/Spring application that is primarily configured via XML. The plan is to slowly migrate the application to Scala. I felt an easy first step would be to replace the XML configuration with a Scala configuration classes.
I have looked over spring-scala and was going to try it out, however, I am running into issues figuring out how to bootstrap the classes extending FunctionalConfiguration.
The application currently uses application.xml loaded from web.xml to start the bootstrapping process via a component-scan. Unfortunately this doesn't seem to pick up the Scala config classes.
Any suggestions on how to bootstrap a spring-scala configuration?
Best,
Peter
Spring-scala seems quite dead. It's not necessary to use it in order to migrate to scala. Old-fashioned java config works pretty well with scala.
Moreover, currently you don't need web.xml and even external servlet container - you can use spring-boot. It'll allow you to throw away all XMLs and some java configuration parts.
Here's an example of the approach with spring-boot & scala. I hope this helps.
We are using websphere application server 8.5 for our enterprise applications.
I want to know is there any integration testing framework other than arquillian?
I tried running with arquillian with embedded and remote. Because embedded does not provide support for CDI we don't want to use it. And with remote we are not able to start our tests because of some security issue. Even if we try to solve that we cannot use #PersistenceContext or #Resource etc.
So I would like to know if there is any integration testing framework exclusively for websphere.
Thank you
P.S.
I think I misunderstood #PersistenceContext and #Resource. Please correct me if I am wrong.
I can use #PersistenceContext or #Resource in my actual application but not in my arquillian classes. Am I right? Earlier I thought I cannot use these anywhere in my code.
Secondly, as a quick test, I tried disabling administration security on WAS and the test case ran successfully.
I want to know is there any integration testing framework other than arquillian?
Currently there are not any good Java EE test alternatives to Arquillian that I know of. However, you can make a decent test framework using some very basic ant scripting and junit.
(See this answer for testing in Java EE for an example implementation)
I think I misunderstood #PersistenceContext and #Resource. Please correct me if I am wrong.
I can use #PersistenceContext or #Resource in my actual application but not in my arquillian classes. Am I right? Earlier I thought I cannot use these anywhere in my code.
If you're going to use #PersistenceContext or #Resource in a class, that class should be container managed (i.e. deployed in an application as part of an ear/war/ejb module)
For future reference:
Secondly, as a quick test, I tried disabling administration security
on WAS and the test case ran successfully
For secured server you need to add username/password and ssl config. For further information look here.
Because embedded does not provide support for CDI we don't want to use
it.
That is actually not true. Embedded containers do support CDI and according to the arquillian blog CDI is one of the few reasons to use them... Update: On a 2nd look you are right as shown here. The blog is probably talking about all the other containers...
What is not supported by embedded containers?
Remote interfaces are not supported in the embeddable container.
In any way the above quoted article provides a good starting point when to use which container type.