I am creating a managed object inside App.java (which is the main class of my module). I am using guice library with dropwizard framework and getting this exception only when running with IntelliJ if I run the same code with mvn it works perfectly fine which is weird and beyond my theory. So if someone has experienced something like this or have some theory behind this then please share. feel free to ask any detail.
environment.lifecycle().manage(new Managed() {
#Override
public void start() throws Exception {
}
#Override
public void stop() throws Exception {
}
});
Exception stacktrace:-
Exception in thread "main" com.google.inject.CreationException: Unable to create injector, see the following errors:
1) Injecting into inner classes is not supported. Please use a 'static' class (top-level or nested) instead of com.phonepe.growth.App$4.
at ru.vyarus.dropwizard.guice.module.installer.InstallerModule.bindExtension(InstallerModule.java:191) (via modules: ru.vyarus.dropwizard.guice.module.GuiceSupportModule -> ru.vyarus.dropwizard.guice.module.installer.InstallerModule)
1 error
at com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:470)
at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
at com.google.inject.Guice.createInjector(Guice.java:99)
at ru.vyarus.dropwizard.guice.injector.DefaultInjectorFactory.createInjector(DefaultInjectorFactory.java:20)
at ru.vyarus.dropwizard.guice.GuiceBundle.createInjector(GuiceBundle.java:191)
at ru.vyarus.dropwizard.guice.GuiceBundle.run(GuiceBundle.java:138)
at ru.vyarus.dropwizard.guice.GuiceBundle.run(GuiceBundle.java:93)
at io.dropwizard.setup.Bootstrap.run(Bootstrap.java:200)
at io.dropwizard.cli.EnvironmentCommand.run(EnvironmentCommand.java:42)
at io.dropwizard.cli.ConfiguredCommand.run(ConfiguredCommand.java:85)
at io.dropwizard.cli.Cli.run(Cli.java:75)
at io.dropwizard.Application.run(Application.java:79)
at com.phonepe.growth.App.main(App.java:48)
This is actually a bug in guicey classpath scan (.enableAutoConfig).
Your application class is covered by a scan and so inner classes are also visible: when you start app from idea "Managed" inner class (created by the compiler for new Managed() {...}) is detected and registered as an extension which also means registration in guice context. But guice can't instantiate the inner class and throws an error.
You can enable extra diagnostic messages with .printLifecyclePhasesDetailed() (on guice bundle) and see that additional extension is indeed appear when running from idea.
Most certainly, when you run app from maven it builds into jar first and then launched. In this case, classpath scan works a bit differently and doesn't see inner classes (inside jar).. so everything works.
Please note that you don't need to instantiate and register managed object (and other common objects) manually: you can simply declare managed as a separate class and guicey will find it and properly register (both in guice and dropwizard). This is the expected way of extensions registrations, especially together with classpath scan.
Related
I am using blockhound to detect blocking calls, I would like to allow my custom methods but its not working and still throwing error.
i am using junit5 with blockhound-junit-platform
#BeforeAll
static void configureBlockHound(){
System.out.println("called");
BlockHound.builder().allowBlockingCallsInside(JWTHelper.class.getName(), "toToken").install();
}
When i run the test i can see called printed on console but still throwing exception.
Try to run blockhound in "log-only" mode first to understand the root cause.
BlockHound.install(builder -> builder
.blockingMethodCallback(method ->
log.error("[{}] Blocking call: {}", Thread.currentThread(), method))
);
I keep getting problems with Grails domain classes and using run action on Application
It appears as though the domain traits and transformations don't seem to pick up or process gorm traits correctly and compiler fails (had problems with columns without sufficient type data or bootstrap failing when I load a value into a property and it says the property doesn't exist etc.
Essentially I can't trust using the run on Application in the IDE and I don't know whether my domain classes are working or not.
However if I go to gradle view and 'bootRun' the same code it will compile and run successfully!
I've had this before and I don't know if its a grails failure or Intellij issue with Grails projects.
When I right click Application and run the command terminal shows it running like this
"D:\Program Files\Java\jdk1.8.0_181\bin\java.exe" "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2018.3\lib\idea_rt.jar=7620:C:\Program Files\JetBrains\IntelliJ IDEA 2018.3\bin" -Dfile.encoding=UTF-8 -classpath C:\Users\willw\AppData\Local\Temp\classpath1951982944.jar lcm.network.app.Application
In my latest iteration this throws a compile error on the bootstrap (as opposed to an error on domain class) with this
groovy.lang.MissingPropertyException: No such property: maintainer for class: com.softwood.domain.MaintenanceAgreement
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:66)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setGroovyObjectProperty(ScriptBytecodeAdapter.java:547)
at lcm.network.app.BootStrap$_closure1.doCall(BootStrap.groovy:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1099)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
at groovy.lang.Closure.call(Closure.java:418)
at groovy.lang.Closure.call(Closure.java:412)
at grails.util.Environment.evaluateEnvironmentSpecificBlock(Environment.java:541)
at g
However that domain class absolutely does have that property - see below
class MaintenanceAgreement extends Agreement {
String level
Map category = [:] //p1 to p5 and sla details
//static belongsTo = [serviceProvider : OrgRoleInstance, maintainer: OrgRoleInstance]
// implemented as unidirectional many to one ! mag point to org
static belongsTo = [maintainer: OrgRoleInstance]
static constraints = {
level nullable:false
//serviceProvider nullable:true
maintainer nullable:false //ref to maintainer party
category nullable:false
}
}
So you spend hours trying to sort spurious problems in your code using right click /run on Application.
I'm forced to have to use grails bootRun - which in this case runs the app just fine.
You lose some details when working this way as the stack trace for compile errors is not so clear.
Has anyone else had this problem with gorm traits processing domain objects in Intellij? Moreover how can I 'fix' the Application run action to fire all the right behaviours as bootRun seems to do?
Mike W's answer seems to be the easiest fix. When you're in IntelliJ and edit your domain models it seems to get confused and app won't compile/run as expecting.
So if bootRun works, but running application from the IDE does not, then doing this tweak seems to get things back to steady state.
If you make edits to your domain models, right click on the domain folder. Then click rebuild 'default' about half way down the menu. Wait till complete, then run your Application instance again by right click RunApplication <main> in the menu and the app should start successfully (or with debug) from within IDE.
This is easiest answer and gives best feedback to the developer with minimal extra rebuild action to remember.
I have an msf4j application in package com.a.sample1 and I want to scan some component in com.a.sample2. Is there a way to do it in msf4j? I am using:
public static void main(String[] args) {
MSF4JSpringApplication
.run(Application.class, args);
}
I can't put my application in com.a package to scan both sample1 and sample2 automatically, one reason is com.a.sample2 is coming from some external library.
In Spring Boot, if the components, JPA Repositories or Entities are not in sub packages of Application.java's package then we need to specify them explicitly. Is this at all possible in MSF4J?
Though I am still waiting for the answer to scan package other than application package, there is work around. I have created an annotation, and Imported configuration class in that annotation.
So, when you add the annotation (created in sample1) in sample2, it will import configurations from sample1 and load the beans into sample2.
I checked MSF4J sources and found, what scans started only for package of Application class, passed as first argument into run method: https://github.com/wso2/msf4j/blob/release-2.1.0/spring/src/main/java/org/wso2/msf4j/spring/MSF4JSpringApplication.java#L165
Unfortunately it is private method and you cannot change it.
From another side, "source" argument (first argument used in run method) used only for determining package autoscan - so, you can simple place any DummyClass into com.a package and run it via :
MSF4JSpringApplication
.run(DummyClass.class, args);
I have REST Assured working in one of our JAR projects. Now I'm trying to add a similar test class in our WAR project.
I added REST Assured to the WAR project:
<dependency conf="test->default" org="com.jayway.restassured"
name="rest-assured" rev="1.8.1"/>
I have also ASM on the test classpath (asm-4.0, asm-analysis-4.0, asm-commons-4.0, asm-tree-4.0, asm-util-4.0); mentioning this since the only search results on my problem suggested a relationship with ASM.
When I run my test, it gives the following error:
java.lang.NoSuchMethodError: org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(Ljava/lang/Object;Ljava/lang/Class;)Ljava/lang/Object;
at com.jayway.restassured.internal.ResponseParserRegistrar.<init>(ResponseParserRegistrar.groovy)
at com.mycompany.testSomething(SomethingTest.java:50)
I've minimized my test to the following:
#Test
public void testSomething() {
ResponseParserRegistrar r = new ResponseParserRegistrar();
}
Obviously I have no direct need to create a ResponseParserRegistrar, but this is what REST Assured does and fails on when I use REST Assured.
Your help would be much appreciated!
Have a look at FAQ #2 at https://code.google.com/p/rest-assured/wiki/FAQ, that would solve your classpath issues. Also I would encourage you to upgrade to a newer version since 1.8.1 is really old.
There is possibility server can't read your method or it will require a some parameters.
NoSuchMethodError is being thrown when program tries to call a class method that doesn’t exist. The method can be static or it can be an instance method too
I have been trying to refactor our Activiti implementation into using CDI but ran into a number of problems. I've spent way too much time trying to resolve this already, but I just can't let it go...I think I've pinned the problem down now, setting up a clean structured war without involving Activiti and have been able to reproduce what I think is the main problem.
Basically I have jar1 and jar2, both CDI enabled by including META-INF/beans.xml. Both jars specify a class in META-INF/services/test.TheTest pointing to implementations local to respective jar. jar1 depends on jar2. Also, both jars point to an implementation of javax.enterprise.inject.spi.Extension, triggering the scenario. In each implementation of Extension, I have a method like:
public void afterDeploymentValidation(
#Observes AfterDeploymentValidation event, BeanManager beanManager) {
System.out.println("In jar1 extension");
ServiceLoader<TheTest> loader = ServiceLoader.load(TheTest.class);
Iterator<TheTest> serviceIterator = loader.iterator();
List<TheTest> discoveredLookups = new ArrayList<TheTest>();
while (serviceIterator.hasNext()) {
TheTest serviceInstance = (TheTest) serviceIterator.next();
discoveredLookups.add(serviceInstance);
System.out.println(serviceInstance.getClass().getName());
}
}
Now, my problem is that the ServiceLoader does not see any implementations in either case when running WebLogic12c. The same code works perfectly fine in both Jboss 7.1.1 and Glassfish , listing both implementations of the test.TheTest interface.
Is it fair to assume that this is indeed a problem in WebLogic 12c or am I doing something wrong? Please bare in mind that I am simply trying to emulate the production setup we use when incorporating Activiti.
Regards,
/Petter
There is a Classloader Analysis Tool provided with WLS, have you seen if this will help with the diagnosis of your issue.
You can access this tool by going to ip:port/wls-cat/index.jsp
Where port will be the port of the managed server where your application is deployed.