I have a main project used as a standalone batch that I want to move to the container using EJB timer (using WildFly 8.2). I thought building a WAR file with the timer class and the dependencies withing WEB-INF/lib, but doesn't sound an elegant solution because it isn't a web app, it doesn't need to bound a context. It's just a JAR, with an EJB inside and the dependencies (I'm using a fat jar) but the container throws an error when I deploy it. Should I use an EAR? Or do you guys think a WAR file is fine?
PS: I'm using Maven, so possible suggestions can take it in account.
You don't really need it in a WAR file if it's not a web application, although it doesn't harms. I would also put it in a JAR file, i don't like to add something that doesn't have a meaning...it can be confusing for others. But as #Bruno César pointed out, you need to package first the EJB(s). Have a look at this; you'll see the ways to package them as JAR, WAR, EAR.
EJB package is good solution if your standalone application has no any third party libraries. But if it has, then best solution would be EAR package type.
Related
We extensively use Java ServiceLoaders as a plugin infrastructure for our application components. We define interfaces, and then use the loader to load them at run time. Adding additional jars with extensions and service files are fine for our use cases.
However, i'm struggling to understand how we would be able to continue this approach while deploying an application within Wildfly. The intent is as stated above, the ability to add "extension" jars to the web-application class path without having to
Stop the server
Unzip the war
Add additional jar
Zip war
Start the server
In Tomcat, we could deploy web application folders instead of a war. So stopping the server, dropping in a jar, and starting the server worked fine. Within Wildfly (latest), it appears to not like the deployment of a folder vs war.
I've read about the modules approach, but have not been successful using this approach to get the deployed application to see the module from the service loader implementations.
Would like to know if there is an alternative solution or perhaps we are doing something wrong?
Thanks
WildFly supports exploded deployments with the deployment scanner or using the explode command with jboss-cli. Using the jboss-cli you can even update files remotely.
I have devloped a spring rest-api. packaging it as a war and deploying the same works fine. what has to be done if need to package it as jar. First of all is that correct, if yes, then how to do so. Please help.
If you are using Maven, just create another project module and move these REST-API classes to that module. The only difference between these classes and "regular" java classes is that they are annotated.
You can still throw the JAR to the classpath and set the package to the "component-scan" directive as a base-package.
You need to use this module together with the main application anyway I suppose.
I have a web application which consist of JSP pages, Servlet and Consumes Web Services.
It also references apache axis and excel libraries.
Now I want to deploy my application directly in Weblogic server
How do i do that.Whcih archive shud i make WAR or JAR??
ALso how to ensures that it covers all the referenced libraries.
I have made my application in Jdeveloper, but I dont want to deploy it using Jdevelper..
I would package my solution as a .war file, containing all dependent .jar files.
That way your solution is self-contained. You can deploy to an app server containing other apps with their own versions of your libraries (dependent or developed). If you put the dependent jars directly into the app server (as you can do), then you're forcing those versions on all applications deployed, and that could well cause you grief.
The downside is that your developed .war file can become sizable. It's not normally a major problem, and I wouldn't worry about it until it's identified as an issue.
A JAR-file cannot contain a JAR-file, so that option is out. Since you mention JSPs and servlets a WAR would seem the appropriate option, although an EAR with a WAR and several JARs could also be a way forward...
Cheers,
Consider a WAR with your JAR files in WEB-INF/lib. Or, create an EAR with APP-INF/lib folder.
As I know it's rule to locate servlets in webapplication module. So after packaging we'll have war archive.
But later I need servlets to use like library. So as we cannot use war file as library i need the jar.
The question: is it normall to refactor webmodule so that move servlets to other project(module) to package to jar archive and use it in webapp as dependency while compiling ?
It's pretty rare to have general purpose, reusable servlets (except if you're developing a framework). But if you have one, putting it in a jar to make it reusable by several webapps is the way to go.
It's not normal (or, indeed, recommended) to package servlets in a jar or to use them as "libraries". What you are supposed to do is extract and isolate any business-logic that is "common" and should be usable by others than the servlet. Those classes can then be packed in a jar that is included in the webapp war as well as any other clients/modules you have that need them.
I have a large OSGI package that I want to package and release as a single jar file. I'm trying to figure out what the best approach is for packaging multiple jars into a single large jar.
So far the best option I've seen appears to be one-jar project. However, the framework we are using pulls in jar files from a 'plugins' directory and one-jar appears to want/require all jar files to be stored only in the lib directory. There may be an easy way around this, I haven't looked fully into the architecture enough to know as I'm still trying to decide what approach is best.
any suggestions for other approaches to package the multiple OSGI bundles into one jar and/or how I would go about making it work in one-jar is appreciated.
Thanks
An alternative solution could be to run your bundles using PojoSR instead of running them in an OSGi framework. PojoSR in a nutshell implements the service layer of OSGi without the module layer. One of the side effects of that is that you can easily package your application as an executable JAR file. When you run that JAR it also does not need to create a bundle cache on disk.
For more information on PojoSR, go to:
http://code.google.com/p/pojosr/
http://luminis-technologies.com/?p=358
http://www.infoq.com/news/2011/10/pojosr
Using the Apache Felix Maven Bundle Plugin, I believe the option might accomplish what you are looking for. http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
Apache Sling's maven-launchpad-plugin generates a runnable jar (and optionally a war file and a Karaf descriptor) from a list of bundles, see http://sling.apache.org/site/maven-launchpad-plugin.html
The Sling installer can be used to load additional bundles from the filesystem or other sources, see http://sling.apache.org/site/jcr-installer-jcrjcrinstall-and-osgiinstaller.html