I'm new to Karaf. I have a jar that has a class App with a method main. When I drop the jar in the The Karaf log service console says the bundle is started but nothing seems to happen. The first thing (the jar) does is a simple database write so I can see if it's running (no log file is generated although one is expected).
The jar depends on lots of other jars. Our sysadmin will not install Maven on the production servers. Where does one put helper jars (like mysql-connector-java-[version].jar)?
Does Karaf use the Manifest file to find the main class? Do I have to implement some special interface or something?
thanks for any help.
As Karaf is a OSGi Container, you should first read some stuff on how to write proper OSGi bundles.
First of all you'll need a Activator that'll start your bundle (just like a main). A Main Class is never interpreted. Yes Karaf, as it is a OSGi container, does "read" the Manifest, but to make sure first it's a proper OSGi bundle second how the resolving should take place by reading Package-Import/-Export.
Regarding the "Packaging" - using lot's of other jar's/bunldes - , you'd either can built a custom Karaf (read the Karaf documentation on how to do this) or create a KAR for your Bundles containing your bundles and a feature.xml (again take a look at the documentation at Karaf)
Related
I am using a Java Application that runs on Jetty-8.
Is there any ways to have the lists of all jars that Jetty scans..
Can we print something (like jar's name or something) when jetty executes those jars.
update
The core issue is jetty-8 slow startup.
I already added metadata-complete="true", and startup time has decreased.
But the problem here is to validate this concept
"metadata tag skips scanning jars of our web application."
Just to do an experiment I have made following changes :
Try 1 :
Removed All meta data tag from web.xml
Jetty log level mode changed to DEBUG.
What I have found in debug level logs is its scanning all jars of my web application. [ That is OK]
Then,
Added metadata tag and restarted server and found it is processing same means its scanning the jars of my web application.
Here I am looking for the ways that make sure that metadata tag is skipping scanning jars from my web application.
There is a command
java -jar start.jar --dry-run
lists all the dependency jars with classpath.
java -jar start.jar --help
gives you detailed usage of start.jar
Note: Jetty 8 is EOL (End of Life). You are strongly encourage to upgrade.
The metadata-complete="true" attribute on the WEB-INF/web.xml does not prevent JAR scanning.
It merely states that the metadata is complete, and should not be modified, as a result of scanning for other metadata sources (like web fragments, class annotations, etc.)
However, there are other features of the Servlet Spec that are not metadata related, and require jar/class scanning to even function. See javax.servlet.ServletContainerInitializer and its #HandlesTypes annotation for an example.
If you were using Jetty 9, then you could control the list of jars that are scanned.
Given a feature with a <configfile> and a <bundle>, how can I ensure that the file is deployed before the bundle? What I'm seeing is that my bundle gets started first and the file deployed second (even if <configfile> is the first tag).
I guess this is could be the <bundle> being considered a pre-requisite so it makes sense to start that before processing the rest of the <feature>?
Actually if you are doing it right, your bundles shouldn't care if the configuration is available or not. The service should either not be started or with a default setting in case no "external" configuration has been set. In case of a new configuration the service will be restarted with the new configuration.
My application supports running on many dbms and it requires user to configure dbms connection setting and also provide the jdbc jar file.
Now the application is to be packaged as OSGi bundle. There will be another main jar which lanches OSGi server and starts the application as bundle.
Can you please suggest how can I package the application as bundle and let user provide the jdbc jar file.
Will it require something like the main launcher jar specifying JDBC driver classes as FRAMEWORK_SYSTEMPACKAGES property?
Thanks in advance,
Aman
There are two ways of doing this:
1) Adding the driver.jar to the classpath of the main launcher and, like you say, expose its packages via the framework by specifying that property (or actually you can use the FRAMEWORK_SYSTEMPACKAGES_EXTRA property to just specify additional packages, instead of specifying all of them).
2) Manually wrapping the driver.jar as a bundle, or doing it dynamically at runtime. For example, you could try to wrap bundles that are copied to a certain folder (similar to what Apache Felix File Install does) by using Pax URL or some other tool that can create a bundle out of an ordinary jar file for you (see http://team.ops4j.org/wiki/display/paxurl/Pax+URL).
I'm deploying an ear with an EJB onto glassfish 3.1 which I want to call using the appclient script.
The EJB has a method with as parameter a model object which is defined in a separate library.
If I want to use the appclient script I have a Main class with a main method which calls the EJB.
This is also put into a separate jar which is also deployed onto glassfish.
As the model object is located in a separate library I need it in the client jar but also in the EJB.
So I need to reference it somehow in the client jar.
The client jar is a jar (duh) so I cannot add other jars. The Java EE 6 docs say that I should create an ear with the libs but if I do that it doesn't deploy because an ear needs at least an ejb or web module and my client lib has neither.
The solution I found is using the assembly plugin/jar-with-dependencies. This plugin creates a new jar which contains all classes of all dependencies.
This solution works but I'm wondering if this is the way to go or I'm missing something obvious because I cannot imagine this is required. EJB's usually have model objects as parameters so this situation will happen a lot.
So my question is: is there a way to tell glassfish to reference the shared libraries between the app client jar and the ejb jar.
The way I do this is like this:
Separate Maven project with the model. In my case that's a bunch of simple POJOs with JPA and JAX-B annotations, some constants, etc. In Maven, I define this as an OSGi bundle, by specifying <packaging>bundle</packaging>. I call this project MyAppInterface.
Separate Maven projects for other elements that need to deal with the model. In my case, I have one Java EE application with EJBs, Database facade, REST servlet; I have an Integration-Test project which only does tests; a GWT application; etc... In those projects I specify the dependency to the model:
<dependency>
<groupId>com.skalio</groupId>
<artifactId>MyAppInterface</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
When deploying MyAppInterface to Glassfish, I use the following syntax:
asadmin deploy --type osgi --name MyAppInterface /path/to/MyAppInterface-1.0-SNAPSHOT.jar
I understand it that this is placing the model on the classpath of Glassfish, similar to a mysql-connector, only OSGi-style.
I let all these projects be built by a central jenkins CI server, which deploys the artifacts to our internal maven repository. We then add the internal repository in pom.xml of each project. As a result, everyone automatically works with the latest stable MyAppInterface, even if they don't have the code checked out in NetBeans / Eclipse.
Let me know if you need more examples.
I have some problems regarding the EJB injection and I haven't been able to find a solution anywhere.
My situation is the following: I have an EAR file that includes a WAR and several JARs, all listed in the application.xml file. All is working fine for this part.
The problems come out when I try to add what we can call a “plugin system”.
I have a JAR with inside some .xhtml pages, backing beans and EJBs. This JAR, if needed, is inserted inside the EAR in a specific directory (let's call it “plugins”) and is detected from the application at startup.
When the JAR is detected it's path is added to the WAR class loader so all the pages and the backing bean are detected without problems. What is not working is the injection of the EJBs (I tried to use the notation #EJB, #Inject, the lookup...). I can't inject any of the EJBs that is inside the JAR plugin.
My guess is that the application server treats the JAR as a simple library module and doesn't look for any EJB inside it, so they are inside the JAR but not usable from the application.
My question is: there's a way of having this working? I tried to add the JAR in the EAR's MANIFEST.MF but nothing changed...
the application server i'm using is glassfish 3.0. About the application.xml: there's no reference in it about the JARs that are part of what i called "plugin system". This because i detect them when i deploy (or i restart) the application in the application server, so they may or may not be inside the system and i don't really know that before the system is started.
Each plugin JAR is a "collection" of pages and functionalities that can be added or removed from the system dynamically (more less like a real plugin system).
My EAR structure is the following:
MyApp.EAR
META-INF
lib
plugins
plugin1.JAR
app.WAR
logic1.JAR
logic2.JAR
for example: in the application.xml i have the references for app.WAR, logic1.JAR and logic2.JAR (they are always inside the system), at startup the application looks inside the folder "plugins" for any plugin (specific JARs) to be added to the system.
I hope i've been more clear about what i'm trying to do...
It seems that the EJB are not even registered in the JNDI tree of the server. Which application server are you using? You can have a look to this JNDI tree to see if the EJBs are there, but the way to do this depends on the specific server.
How are you declaring the JAR that contains the EJBs in the EAR application.xml?
It should be someting lide this:
<application>
....
<module>
<ejb>nameOfTheJarFile.jar</ejb>
</module>
</application>
The Jar should be in a the "/lib" directory of the EAR.
I hope this helps.