We are migrating from JBoss 5 to WildFly 8.2. Still using Spring 3.1. Suddenly none of our aspects can be found when application starts.
We might have solved (partially) the XML configuration (by placing more wildcards around), but annotation based configuration of aspects cannot be solved the same way (no wildcard possible for aspect itself since this is annotated class). Here is the Aspect class definition:
package com.mycompany.session;
#Aspect
#Component("mySessionManager")
public class SessionManager {
// intercepting any class, any method starting with com.mycompany.some
#Pointcut("execution(* com.mycompany.some.*.*(..))")
public void myPointcut() {}
#Around(value="myPointcut()")
public Object process(ProceedingJoinPoint jointPoint)
throws Throwable
{ ... the rest of code }
}
When starting this code without changes under WildFly we get this error:
java.lang.IllegalArgumentException: warning can't determine implemented interfaces of missing type com.mycompany.session.SessionManager
Anything wrong with code? Anything needs to be different in WildFly versus older jboss?
Thanks,
Nikolay
Related
The AWS SDK can locate API call interceptors via classpath scanning (looking for software/amazon/awssdk/global/handlers/execution.interceptors and instantiating classes specified there).
I'm writing a Java Agent with the intention of causing my interceptors to be locatable by the AWS SDK.
My interceptor is bundled with the Java Agent.
My interceptor implements AWS's ExecutionInterceptor.
The AWS SDK is not bundled with my agent, because I'd like the end-user to provide their own AWS SDK version.
For regular standalone applications, this is a no-brainer, as the Java Agent is automatically added to the runtime classpath of the application. The AWS SDK finds my interceptors with no problem.
However, this approach completely breaks with Spring Boot applications where the AWS SDK is bundled as a dependency under BOOT-INF/lib. The reason boils down to Spring Boot's classloading hierarchy. My interceptor class can be found, but its loading fails due to inability to find AWS's ExecutionInterceptor, as it is loaded in a "lower" classloader in the hierarchy.
So I figured that my approach should be to somehow modify Spring Boot's classloader search. However, I'm facing these issues:
At the time of the agent being called, Spring Boot's "lower" classloader isn't created yet.
I am not entirely sure what it is that I need to instrument.
I've read of Byte Buddy being able to help in such "interesting" circumstances but haven't found a way to make this work yet. Any ideas?
(EDIT: I'm looking for a solution that doesn't require code/packaging changes, hence the Java Agent approach)
(EDIT: Things I've tried)
Following Rafael's answer: The method in the SDK that resolves all interceptors is in the class SdkDefaultClientBuilder, and is called resolveExecutionInterceptors.
The following, then, works for standalone JARs which are not SpringBoot applications:
public static void installAgent(Instrumentation inst) {
new AgentBuilder.Default()
.with(RedefinitionStrategy.DISABLED)
.type(ElementMatchers.nameEndsWith("SdkDefaultClientBuilder"))
.transform(
new Transformer() {
#Override
public Builder<?> transform(Builder<?> builder, TypeDescription typeDescription,
ClassLoader classLoader, JavaModule module) {
return builder.visit(Advice.to(MyAdvice.class).on(ElementMatchers.named("resolveExecutionInterceptors")));
}
}
).installOn(inst);
}
For SpringBoot applications, however, it looks like the advice isn't applied at all. I am guessing that this is because the SdkDefaultClientBuilder type isn't even available at the time when the agent starts. It is available during SpringBoot's runtime, in a different classloader.
Byte Buddy allows you to inject code in any method of any class, so the first and only major thing you would need to find out would be where your interceptor is instantiated. This can typically be done by setting a breakpoint in the constructor of the interceptor in the working scenario and investigating the methods in the stack. Find out where the classes are discovered, for example the method where software/amazon/awssdk/global/handlers/execution.interceptors is read.
Once you have identified this method, you would need to find a way to manually extract the interceptors defined by your agent and to manually add them. For example, if the file-extracted interceptors are added to an argument of type List<Interceptor>, you could use Byte Buddy to modify this method to also add those of your agent.
Normally, you use Byte Buddy's AgentBuilder in conjunction with Advice to do so. Advice let's you inline code into another method as for example, assuming you find a method with an argument of type List<Interceptor>:
class MyAdvice {
#Advice.OnMethodEnter
static void enter(#Advice.Argument(0) List<Interceptor> interceptors) {
interceptors.addAll(MyAgent.loadMyInterceptors());
}
}
You can now inline this code into the method in question by:
class MyAgent {
public static void premain(String arg, Instrumentation inst) {
new AgentBuilder.Default().type(...).transform((builder, ...) -> builder
.visit(Advice.to(MyAdvice.class).on(...))).install(inst);
}
}
You might need to use AgentBuilder.Transformer.ForAdvice if the classes in question are not available on the agent's class loader where Byte Buddy resolves the advice using both the target and the agent class loader.
A project I'm working on is utilizing Spring Cloud Config server to handle property update/refresh.
One question that has repeatedly come up is how to reference/serve plain text from the config server.
I know that the server supports serving plain-text. What I'm trying to figure out is that if I have a reference /foo/default/master/logj42.xml.
How would I reference this in an "agnostic" way such that if I were to put:
{configserver}/foo/default/master/log4j2.xml in the config file
The reference {configserver} would be expanded.
Additionally, when using "discovery", if I inject the reference to the "resource" as above, the default mechanism will attempt to use java.net.URLConnection to load the content. I do not think it will resolve the 'discovery' host.
Thanks in advance.
It also can be resolved using Customizing Bootstrap Configuration without aspects by creating custom property source and set configserver uri after locating from discovery.
I had similar issue, more details in this stackoverflow post
I found a way to do this that is minimally invasive but "pierces the veil" of where the config server actually resides.
On the primary application class, the annotation #EnableDiscoveryClient needs to be added.
I created an aspect to add a property source with a key that indicates the actual URI of the server handling the request:
#Component
#Aspect
public class ResolverAspect {
#Autowired
private DiscoveryClient discoveryClient;
#Pointcut("execution(org.springframework.cloud.config.environment.Environment org.springframework.cloud.config.server.environment.EnvironmentController.*(..))
private void environmentControllerResolve();
#Around("environmentControllerResolve()")
public Object environmentControllerResolveServer(final ProceedingJoinPoint pjp) throws Throwable {
final Environment pjpReturn = (Environment)pjp.proceed();
final ServiceInstance localSErviceInstance = discoveryClient.getLocalServiceInstance();
final PropertySource instancePropertySource =
new PropertySource("cloud-instance", Collections.singletonMap("configserver.instance.uri", localServiceInstance.getUri().toString()));
pjpReturn.addFirst(instancePropertySource);
return pjpReturn;
}
}
By doing this, I expose a key configserver.instance.uri which can then be referenced from within a property value and interpolated/resolved on the client.
This has some ramifications with regard to exposing the actual configuration server, but for resolving resources that do not necessarily utilize the discovery client this can be utilized.
It looks like mentioned annotations are executed inside the deployment. I need them to be run outside, let's say to start some simulator class on startup and stop it on the end. How can I do it? The simulator uses socket communication and it should not be started inside the server.
How to mix arquillian with "plain" junit(not executed in container).
You can use the arquillian #RunAsClient annotation combined with the junit #BeforeClass and #AfterClass:
#BeforeClass
#RunAsClient // runs as client
public static void shouldBeAbleToRunOnClientSideBeforeRemoteTest() throws Exception {
System.out.println("before!!");
}
#AfterClass
#RunAsClient // runs as client
public static void shouldBeAbleToRunOnClientSideAfterRemoteTest() throws Exception {
System.out.println("after!!");
}
The answer that Franck gives will certainly work, and will probably be what most users will want to use. If, however, you need to get some more detail about what's going on, or need some more control you can certainly hook into the Arquillian life cycle and register observers for all sorts of events that Arquillian emits. Unfortunately, it isn't as easy as listening to a CDI event.
You'll need to create a services entry in META-INF/services with the file name of org.jboss.arquillian.core.spi.LoadableExtension. The contents of that file will be the Fully Qualified Name (FQN) of the classes that implement the LoadableExtension interface from Arquillian. You can then in the register(ExtensionBuilder) method register any classes that will observe events. Those classes will simply need a public void methodName(#Observes EventType) method for all the events they want to listen for. The #Observes annotation is in the org.jboss.arquillian.core.api.annotation package.
You can see this in action the Arquillian Recorder Reporter extension here, here, and here. I understand this is probably more than what most people will want to do, but again, if you need the power and hooks, Arquillian should be able to give you what you need.
First off I want to say there is a ton of answers on SO and google searches surrounding this, however I'm running into an issue that prevents those solutions from working. The answer here seems to be the way to go. (kernel.Inject(Roles.Provider);)
The issue that I'm having is that when I'm trying to inject the RoleProvider Roles.Provider is null, however my custom provider is found in the list within Roles.Providers. I am thinking that Ninject is trying to access the role provider too soon.
In my NinjectWebCommon class it appears that it's using WebActivator to start itself. [assembly: WebActivator.PreApplicationStartMethod(typeof(Admin.App_Start.NinjectWebCommon), "Start")]
It appears that all of the articles I've come across are using older versions of Ninject and are doing a lot of the heavy lifting in the Global.asax Application_Start... Using my implementation how can I get DI working for a custom role provider?
I'm using the [Inject] attribute within my custom provider.
The WebActivator pipeline runs way before even the standard ASP.NET stack is created. It means that you won't have access to anything created by ASP.NET during bootstrap in NinjectWebCommon.
Use that file only to declare bindings that do not depend on ASP.NET stuff to be up.
In order to get around this issue, you should use Global.asax Application_Start handler to load any additional modules/bindings that are dependend on ASP.NET stuff such as Roles.Provider.
Here is a suggestion that may solve your problem:
public void Application_Start()
{
var kernel = (new Bootstrapper()).Kernel;
kernel.Inject(Roles.Provider);
//Other initialization stuff
}
The Bootstrapper class is a lazy singleton that has a static IKernel initialized within your NinjectWebCommon.cs. So this is the proper way of retrieving the configured kernel instance from outside your NinjectWebCommon.
Give it a try.
suppose i have a jax-rs resource class that looks like this:
#Path("/nodes")
public class NodeResource {
//Temp - those injections should work
#EJB
ListNodesLocal nodeList;
//stuff
}
and i want some sort of lifecycle callback so i can manually lookup that field via JNDI because injection isnt working for me yet (using jboss 6 m5. see this issue : https://jira.jboss.org/browse/JBAS-8575).
ideally im looking for something like
#PostConstruct
private void init() {
//manual JNDI to come here
}
can i do this somehow ? i've tried javax.annotation.PostConstruct to no avail. is there something that works?
Since you linked to jboss in your question this answer assumes you're using the Resteasy implementation of JAX-RS. You can register interceptors to hook into the lifecycle. See here. That's how I was able to use Shiro annotations to authorize clients who want to invoke my API.