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.
Related
I'm trying to build a dynamic database connection via Agroal inside a native image. It's not possible to use the default config params because I don't know the connection params at compile time. Is that even possible right now?
The connection is built like this at runtime:
AgroalDataSource.from(
AgroalDataSourceConfigurationSupplier()
...)
I'm currently seeing this error:
Class io.agroal.pool.ConnectionHandler[] is instantiated reflectively but was never registered.
Register the class by using org.graalvm.nativeimage.hosted.RuntimeReflection
The installed features include: [agroal, cdi, jdbc-h2, jdbc-mysql, jdbc-postgresql, kotlin, narayana-jta, resteasy, resteasy-jackson]
It runs fine on the JVM, but not using Graal. It feels like it should be possible and I'm probably missing something here. I was hoping adding agraol extension would be sufficient but obviously isn't picked up correctly.
The current situation is that we configure Agroal for native images only if you have a datasource defined using Quarkus configuration.
Thus for your use case, for now, you will have to do what we do automatically manually. What we do being registering some classes for reflection and including some resources in the native image.
See https://github.com/quarkusio/quarkus/blob/master/extensions/agroal/deployment/src/main/java/io/quarkus/agroal/deployment/AgroalProcessor.java#L91 and https://quarkus.io/guides/writing-native-applications-tips#using-a-configuration-file.
Obviously, that's not ideal. Could you open an issue on our GitHub so that we can discuss it internally and see if we should/can improve the situation?
In the end, you would still need some reflection registration for your JDBC driver though.
We have an embedded Apache FTP server running in a gateway for several years. It always worked without problems.
But now a customer is trying to connect with a device of a brand that we've never had before, and contrary to all other clients so far, that thing sends the ALLO command in advance to make sure the server has enough space.
But Apache FTP doesn't seem to know that command. the trace log states:
RECEIVED: ALLO 77482
SENT: 502 Command ALLO not implemented.
following which the client cuts the connection.
The command is also not present in the Apache documentation:
https://mina.apache.org/ftpserver-project/ftpserver_commands.html
So the question is, can I plug my own implementation into the server somehow?
Just to be clear, I'm not asking how to implement the functionality. Just how I can pass my own implementation to Apache FTP for use. If that is possible without touching the source code.
Since the application in question has been running very stable for a long time, I would really hate to tear the Apache FTP server out of there and embed another one...
Well, that was surprisingly simple once I dug myself through to the right code.
The implementation of a command is simple enough, in this case I've just started with a stub for testing:
class ALLO : AbstractCommand() {
override fun execute(session: FtpIoSession, context: FtpServerContext, request: FtpRequest) {
session.write(LocalizedFtpReply.translate(session, request, context,
FtpReply.REPLY_200_COMMAND_OKAY, "ALLO", "bring it!"))
}
}
Inherit AbstractCommand, override execute and write a response to the session.
The question is of course then how to make the server aware of the implementation, which also turns out to be really simple, although there sure as hell doesn't seem to be any documentation around. But you can just instantiate a CommandFactoryFactory, map your implementation, build the CommandFactory and set it in the FtpServerFactory:
val commandFactoryFactory = CommandFactoryFactory()
commandFactoryFactory.addCommand("ALLO", ALLO())
serverFactory.commandFactory = commandFactoryFactory.createCommandFactory()
This is what I get when I run atlas-create-jira-plugin followed by atlas-create-jira-plugin-module selecting option 1: Component Import.
The problem is that all tutorial examples appear to have plugin descriptor generated by old SDK version (that won't deploy with newer versions of SDK/Jira at all), which do not feature Atlassian-Plugin-Key, so I can't find my way to import a component.
I'm using SDK 6.2.3 and Jira 7.1.1.
Any hint - how to get this sorted out?
anonymous is correct. The old way of doing things was to to put the <component-import> tag in your atlassian-plugin.xml. The new way and also recommended is to use Atlassian Spring Scanner. When you create your add-on using atlas-jira-create-plugin and your pom.xml has the <Atlassian-Plugin-Key> tag and the dependencies atlassian-spring-scanner-annotation and atlassian-spring-scanner-runtime then you are using the new way.
If you have both the dependencies, you are using Atlassian Spring Scanner version 1.x. If you only have atlassian-spring-scanner-annotation then you are using version 2.x.
You don't have to omit/comment out Atlassian-Plugin-Key in your pom.xml and you don't have to put component-import in your atlassian-plugin.xml.
For example, you want to add licensing for your add-on and need to import the component PluginLicenseManager. You just go straight to the code and your constructor might look like this:
#Autowired
public MyMacro(#ComponentImport PluginLicenseManager licenseManager) {
this.licenseManager = licenseManager;
}
And your class like this:
#Scanned
public class MyMacro implements Macro {
If memory serves me right, be sure to check for null because sometimes Atlassian Spring Scanner can't inject a component. I think on version 1, writing an #EventListener, it could not inject a ConversionContext. But when writing a Macro, it was able to inject a ConversionContext.
According to
https://bitbucket.org/atlassian/atlassian-spring-scanner
component-import is not needed. You can replace it by #ComponentImport annotation in your Java.
Found answer here: https://developer.atlassian.com/docs/advanced-topics/configuration-of-instructions-in-atlassian-plugins
It looks like I've somehow been missing that Atlassian-Plugin-Key can be omitted, and it must be done when you need to import components.
This key just tells spring not to 'transform' plugin's Spring configuration, which must happen as part of components import process..
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've been banging my head at this for about 8 hours now, and I just can't seem to find a simple explanation on how to change my custom bootstrapper for ninject (Last worked on the code back in v2.x.x.x) to the new v3.0.0.0 syntax.
I currently have the following:
public class NinjectCustomBootStrapper : NinjectNancyBootstrapper
{
protected override Ninject.IKernel GetApplicationContainer()
{
return Program.MyContainer;
}
}
in a septate class, and :
public static IKernel MyContainer
{
get { return _myContainer ?? (_myContainer = CreateKernel()); }
set { _myContainer = value; }
}
private static IKernel CreateKernel()
{
var kernel = new StandardKernel();
kernel.Bind<CardMonitorService>().ToSelf().InSingletonScope();
return kernel;
}
in my main program 'Program.c' in a command line app.
Iv'e since updated ninject to V3.0.0.0 only to find that there's been some breaking changes. I'll admit I don't use ninject very often (I usually use structuremap), and the only reason this project does is I didn't write it originally.
Since I've upgraded Ninject, now when the app is started up I get the following exception:
Method not found: 'Ninject.Syntax.IBindingWhenInNamedWithOrOnSyntax`1<!0>
Ninject.Syntax.IBindingToSyntax`1.ToConstant(!0)'.
After a ton of searching and researching, the closest I've been able to find is this:
http://sharpfellows.com/post/Ninject-Auto-registration-is-changing-in-version-3.aspx
Which while it points me in the right direction, still isn't quite a solution as I'm not using a custom binding generator.
So my question is this.
How do I rewrite the above so that my project once again works and the WCF service when called gets the correct singleton binding handed to it when a request comes in. Going back to ninject 2 is not an option, as other dependencies in the project that have been added have forced the v3 upgrade and these add new functionality that's been requested hence why I'm working on it.
For reference this is a .NET4 build, running on NancyFX with a self hosting WCF setup as a windows service using Topshelf to provide the SCM interface.
Cheers
Shawty
Addendum to clear things up a little
This is an existing project that was originally written sometime back, I've been asked to add some new features to the project.
As part of adding these new features I have been required to upgrade the version of Ninject being used from an earlier version to V3.0.0.0 as newer dependencies added to the project require the newer version of Ninject.
Under the previous V2 of Ninject the code I have given above worked fine, with no issues, since the project has had Ninject V3 added I now get the exception as described above.
I cannot go back to the earlier version of Ninject as that will mean not being able to add the new functionality that I'm adding.
From the research I've done so far the sharpfellows link above is the closest explanation of my issue that I've managed to find so far on the internet.
I don't use Ninject very often, so I've not got the background to know what's changed between V2 & V3 that (based on my research) is the cause of my issue.
I need to know how to change my code written under V2 (and shown above) so that it works under V3.
MissingMethodException is usually a deployment problem. You compile against a different assembly than you deploy. Check that you deployed the same version and same build.
So after a week or so it turns out that the problem was that the Nancy dev team broke binary comparability with the latest version of ninject (or vice versa) :-)
There is a GitHub pull request to fix this available at :
https://github.com/NancyFx/Nancy.Bootstrappers.Ninject/pull/6
However the next version 'Nancy.Bootstrapper.Ninject' 0.12 will be out on NuGet soon which will have the fix implemented.