I'm building an OSGi application containing (at the moment) only business logic. Since I want my users to interact with my software via browser I'm thinking on trying to add an application server inside my application via commands like:
public void startApplicationServer();
public void stopApplciationServer();
public void deployApp(App appToDeploy);
public void undeployApp(App appToUndeploy);
After some thought, the application server I've chosen is "wildfly 10". However, I'm failing to find any resource allowing me to call wildfly programmatically. My question is do you know a procedure to follow or general steps in order to achieve my goal?
Some info you can find useful to help me:
I've chosen Wildfly becuase it fully support Java EE 7, run on JDK8 and it is released under LGPL (I preferred open source glassfish, but it was release under GPL, hence it would have been mandatory to make the source available. Since (in the future) I would like to make this software commercial, I was forced to discard it);
Maybe some of you may suggest to build my whole application on the application server itself. I prefer not to do so because the web interface may be only one possible User Interface of my application (who knows, maybe in the future I want to switch to another interface, like CLI or desktop-like);
I've look at several content, like wildfly-swarm or Arquillian: I know these projects targets are completely different from mine, but maybe they can be part of the solution? It's just my personal (and possible wrong) thought;
I'm a newbie in the whole "application server" world, so it's highly possible that I'm missing something.
Thanks for any kind reply.
You might want to have a look at WildFly Swarm.
While not documented, there is also the WildFly launcher API. You can see some examples of how it's used in the wildfly-maven-plugn.
Another option would be the application client. Though I'd probably lean towards WildFly Swarm for your use case.
I ended up embedding tomcat 8 within OSGi environment. I really wanted to use the same JVM process for both OSGi and application server (at least to me having 2 separate processes with all the ensuing overhead made no sense), hence embedding tomcat was perfect. Giving up Java EE 7 Full Profile wasn't a big loss since I only needed Web Profile (+ Jersey for web services).
I've written a guide on how to embed tomcat on OSGi here: in case the link will break down, I'll write down here the most important phases:
add to maven all the "tomcat embed" dependencies;
add "felix.service.urlhandlers=false" to config.properties;
Create a new JarScanner from StandardJarScanner where URIs like "http://.extensions:/" are ignored;
Use context.setJarScanner(JarScanner js) method for every context= tomcat.addWebApp(String, String) call;
Make the "tomcat bundle" a framework extension bundle (see OSGi R6 3.15 section);
Register the "tomcat bundle" service via an "extension bundle activator" via the normal ServiceRegistration procedure;
add the tomcat interface bundle package to "org.osgi.framework.system.packages.extra" config.properties (e.g. if the interface of "tomcat bundle" is inside com.acme.applicationserver package add "com.acme.applicationserver"
I won't mark this answer as the correct one simply because my question was related to wildfly. I consider this answer only as a workaround (even though for me this answer definitely solve my issue)
Related
Our company is currently using RAD to develop our Java apps, but we're looking to move to Eclipse with the WebSphere Developer Tools. The pilot for our transition is going pretty well, except we're running into a classloader policy issue for new applications that are originally created in Eclipse, not RAD. Our projects that were originally created by RAD are deployed with the correct classloader policy (PARENT_LAST) when published via Eclipse because we originally used the Deployment Descriptor Editor in RAD which set the proper classloader policy in /src/main/application/META-INF/ibmconfig/cells/defaultCell/applications/defaultApp/deployments/defaultApp/deployment.xml. But now with Eclipse & WebSphere Developer Tools, we no longer have the nice Deployment Descriptor Editor UI to create or modify this file for us (apparently it's not included with the WDT plugin).
So, my question then is what is the best way to go about setting this classloader policy? We still need some new apps to have the classloader policy of PARENT_LAST set when we deploy them to our local servers. Our team has though about this a bit and we can see 4 options at the moment.
Open the Admin Console after every publish and change it. This would be a huge pain, and is pretty much not even a real option.
Change the server profile setting to use a PARENT_LAST classloader policy for all apps. This however is not the case for all the apps at our company, and would not work for all groups.
Run a jython script after every publish to set the classloader policy. This is slightly better than option 1, but not by much.
Manually create a deployment.xml file in the same location as the other apps created by RAD with the same structure as the deployment.xml files created by RAD, and modify it as necessary for each app.
Option 4 seems to be the best of the bunch, but it's still a manual process and somewhat error prone. Even if most of our developers can grok this approach for new apps, it would be most ideal if this were a simple one button click type process.
So given the fact that IBM has omitted the Deployment Descriptor Editor from the WDT plugin it would seem as if option 4 is our only hope, but I'll ask once more, is there any other better way to set a WebSphere classloader policy to PARENT_LAST for an app when that app is created in Eclipse? Any help is appreciated, thanks.
Well, Eclipse is free, while Rational Application Developer costs about $5,000 per year (per developer). The nice Deployment Editor (which wasn't that nice. It tends to include all sorts of things that aren't needed. Who needs that Derby DataSource defined there, anyway?) is one of the things you have to give up for saving tons of cash on an annual basis.
I'm digressing.
Option (1) is a complete no-no. You don't want to rely on manual steps for deployments; you should strive to automate deployments to the extent possible.
Option (2) might do. I am not sure which flavour of WebSphere you're using, but if you're using the Network Deployment edition, then you can design a WebSphere topology that consists of multiple servers and clusters. You could, theoretically, come up with such a topology whereby PARENT_LAST applications run on a specific server (or cluster) and PARENT_FIRST applications run on another server (or cluster).
You may be able to combine option (2) with a technical initiative to have all of your applications work with PARENT_LAST. This is the recommended approach if your application is using popular third-party libraries that WebSphere happens to use as well (for its own internal purposes). For example, if you're using Commons Lang, then you're already recommended to switch to PARENT_LAST because WebSphere uses its own internal copy of Commons Lang that might conflict with yours.
Option (3) - it's of course better than option (1) but isn't necessarily worse than option (2) if you can get your WebSphere topology right.
Option (4) is harder to implement but I believe it's the best approach overall:
It's a one-time setup effort for each EAR (and for each WAR that exists within the EAR).
Once it's done, deployment can easily be automated as no extra steps are needed.
If you're working with a local test environment to test your code, and you're rapidly publishing applications from your workspace into your local test environment, then this approach is the only approach (other than option (2)) that will work for you without extra manual work.
If none works... consider paying $5,000 per year (per user) and get option (5) - use IBM's editor. Or, better off... hire someone to design an Eclipse plugin that will do that for you. Shouldn't take more than a week or two to develop.
um nether answer is useful.
Go into WAS console and pick your application; example:
Enterprise Applications > my_application_ear > Class loader AND change the "class loader order and WAR class loader policy"
Open the admin console within eclipse click server >> your server >> scroll down and under server infrastructure >> java process management select class loader >> select new you can change it here
I'd like to use something like the Filtering Classloader to prevent specific packages from creeping into the application context and becoming visible to Spring.
Changing the classloader order causes all sorts of nasty problems so I´d like to try this route.
Is it possible to achieve this with Websphere 6? If not, can I replace my own application classolader and implement the filter myself?
There is no such filtering mechanism in WebSphere, and there is no way to replace the application class loader. You'll have to use PARENT_LAST to override classes, sorry.
bkail's answer is right, WAS doesn't have such feature even in its latest public version (8.5.5).
I just created a RFE requesting such feature so whoever is interested in this, please vote for it which may increase the possibility of this being implemented:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=43936
(IBM ID required)
In the meantime, you may use isolated shared libraries to override any particular classes (the above mentioned class loading order control - like parent_last - is too rough as it affects the class loading order of the whole application or module)
Create a shared library with desired jars on the classpath, configure it as isolated shared library, reference it from the deployed application (or module).
See here for complete documentation
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.base.doc/ae/tcws_sharedlib.html
I was just about to post the same question. But the answer was quite unsatisfying. I however checked the request from Petr H at the IBM developerworks and IBM did implement this feature (Huge thanks Petr!):
"WebSphere Application Server V8.5.5.7 (=Fixpack 7) gained the ability to prevent packages from the server classloader being visible to applications. This was delivered in the document "ISOLATE DEPLOYED ARTIFACTS FROM OSS PACKAGES" and is documented in 'Isolating open source software packages'.
The supplied links describe the mechanism by configuring always-protected packages. You basically have to do the following:
Under Server Infrastructure on the server settings page in the administrative console, click Java and process management > Process definition.
Select Java virtual machine.
Define the following system properties in the JVM generic arguments section as follows:
-Dcom.ibm.ws.classloader.server.alwaysProtectedPackages=org.bouncycastle.
Please not that the final dot "." is really important otherwise everything will be ignored! Several packages can be added by comma ","
Click Apply, OK and save the changes. Make sure that a file synchronization is done before you restart the servers. Restart WebSphere Application Server for the changes to take effect.
Examine the native_stdout.log and find the system properties that are previously defined. For example, when you specify always-protected package org.bouncycastle., statements such as the following might appear:
ProtectionMetaData.clinit: system property: com.ibm.ws.classloader.server.alwaysProtectedPackages=org.bouncycastle.
UPDATE: See my blog post on this topic about a year after this was written: http://blog.ringerc.id.au/2012/07/java-ee-7-needs-improvements-in-app.html
... for references to the Java EE 7 planning discussion on this topic.
I've mostly finished writing a small Java EE 6 application, and am in the process of replacing the hard-coded preferences with a proper dynamic configuration interface.
I'm not sure how - or, more specifically, where - to store settings. There must be some obvious, "standard" way to do this that's expected to "just work" across various frameworks and containers, but for the life of me I cannot find it.
What I want is a simple way to load and store settings, one that works across different app servers and OSes, doesn't require any confguration by the user, and actually works properly. The Java Preferences API would be ideal - but seems broken under Glassfish 3.1.
Options for storing configuration would theoretically include:
Using context-parameters from the container environment
Storing them using the Java Preferences API
Reading/writing a properties file ... somewhere
Using JPA to store them in a JavaDB provided by the container
Putting it in a properties file that's loaded off the classpath
Using system properties to set configuration options, or path to a .properties file
This would seem to be a basic requirement that'd be well catered for in an environment where the container supposedly provides you with all the core services you might need - but all these approaches have issues.
A bug in glassfish renders (1) unworkable, and in any case the Glassfish web admin user interface lacks any way to configure context parameters, so you have to use `asadmin' and some less than lovely command line syntax to do it. Context parameters can only be accessed via the ServletContext - which isn't accessible in a consistent way between frameworks like JSF2, JAX-RS, and raw servlets - but at least Seam Servlet handles that.
What appears to be another bug in glassfish was a library version conflict between the deployed app and Glassfish breaks (2). The preferences backend fails to flush preferences to disk, so the stored preferences data is lost when the application server is restarted. The Java Preferences API also seems to be considered a J2SE/desktop thing, despite its inclusion in the Java EE 6 specs.
(3) might work - but there's no way to know where your app has read/write access on the file system and where it should look. You can't make this configurable, as it becomes a chicken-and-egg problem then. Various platform-specific guesses could be applied, but would break in the presence of a SecurityManager.
(4) would work, but it's nuking a fly. It requires that a JavaDB service be running and forces the user to make sure the JDBC and pool resources in the app server are configured properly. It's big and complicated for a simple job, and entity modelling isn't a lovely fit for preferences storage anyway, as it'll mostly land up being key/value structured.
(5) would work, but requires users to know where to put the config file where it'll be found under various different app servers. It also makes it hard for the app to provide any kind of configuration UI because it can't necessarily find the local path to the config file or open it for writing, especially in the presence of a SecurityManager.
(6) would also work, but forces the user to configure the configuration system before they can configure the application. Needless to say, that doesn't excite me, given how relatively complicated deploying the app and creating the resources already is for users who don't already know Glassfish/EE.
So ... how are you handling configuration and storage of options? Have you found a way that lets you "just do it" without the user having to configure anything to allow your app to store its configuration?
The problem with the preferences API was caused by the inclusion of jaxb and stax implementation jars on in the application's war, pulled in by jersey-json . With these excluded (as they're provided by the app server anyway) the preferences API resumed functioning correctly.
It looks like the prefs API with custom UI for setup appears to be the best way to go.
Though not the environment you spoke about: http://www.osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
Using JAVA framework i want to achieve the following task.
hot code(jar) deployment which will perform certain task in an environment
At any time if i update that jar file it should automatically unload old code and load new code
I want to schedule that deployed jar file to perform tasks.
Currently i see Apache karaf/Felix fulfill this requirement but less help available and difficult to manage.
Any alternate framwork i can use instead of using karaf/felix ?
If you aren't going to go the OSGi route, which you basically implied by forgoing Karaf / Felix (and Karaf uses Equinox, by default) then about the best thing I can suggest for you to consider is LiveRebel when it comes out. #Daniel's answer mentioned JRebel, which is outstanding for hot deployment during development but it is not meant as a tool for production systems. Instead you should check out LiveRebel, also made by Zero Turnaround, might be able to fulfill of your needs. Please note that this is a commercial product but they are offering a private beta right now.
[Edit]
Idiotically, I forgot to mention that there's also Knoplerfish, another OSGI runtime which has a BSD style license. Perhaps give that a shot?
Give JRebel a try. It is a great tool.
Note sure what environment you mean (eg. web, desktop, server-side, etc), but...
Working backwards:
3: Scheduled Tasks
You can achieve this in any Java container with the Quartz Scheduler library. This allows you to schedule events in a CRON like fashion.
1-2: Hot Deployment
Then it's a question of where you want to deploy and how to handle hot deployment. Other answers have mentioned JRebel and OSGI which will work. If you want some super quick deployment (eg. save the code and it's available) and have it hosted in a web container ,then use the Play Framework. It uses Quartz do implement Scheduled Jobs in a very nice way.
For example (from the Play docs) :
#Every("1h")
public class Bootstrap extends Job {
public void doJob() {
List<User> newUsers = User.find("newAccount = true").fetch();
for(User user : newUsers) {
Notifier.sayWelcome(user);
}
}
}
JBoss has the hot deploy feature that your describing. However, I'm guessing it's as complicated to configure Karaf. It may be possible to find out how JBoss is achieving it and use the libraries yourself though.
hot code(jar) deployment which will perform certain task in an
environment
At any time if i update that jar file it should automatically unload
old code and load new code
I want to schedule that deployed jar file to perform tasks.
In a nutshell, hot deploy/redeploy is done like that
Use a classloader (java.net.URLClassLoader is a good start), load the jar(s), actually copy the jar somewhere (temp) before loading it
You need some interface implementation, instantiate the class implementing the interface (META-INF in the jar, custom xml, whatever), configure it (props/xml, whatever)
call start() and perform the tasks.
Monitor the jar: some thread to check it each second and compare the last modified time/size
If changed - call stop() and undeploy, may need to wait for threads, etc, start over
There are a lot of frameworks that allow dynamic deploy
The hotdeploy feature of most web containers (like Tomcat or Jetty) allow you to have the behaviour you want, on web applications.
Such an application can be very simple, and essentially just contain your jar.
What is it you need your application to do?
I am looking for something very close to an application server with these features:
it should handle a series of threads/daemons, allowing the user to start-stop-reload each one without affecting the others
it should keep libraries separated between different threads/daemons
it should allow to share some libraries
Currently we have some legacy code reinventing the wheel... and not a perflectly round-shaped one at that!
I thought to use Tomcat, but I don't need a web server, except maybe for the simple backoffice user interface (/manager/html).
Any suggestion? Is there a non-web application server, or is there a better alternative to Tomcat (more lightweight, for example, or easier to configure)? Thanks in advance.
Have you looked at OSGi ? You can load/unload bundles (basically .jar files with metadata) independently of each other, and optionally define dependencies between these (with a software lifecycle defined such that bundles are aware of other bundles being loaded/unloaded).
I have found the Jetty "contexts" concept very useful in handling applications (packaged as WAR's and with servlet context listeners), where the xml-file placed in contexts/ describe fully what you want to have started. When you remove the xml-file again, the thing described is stopped.
If you do not start a server connector you will just have a start-stop thing which sounds like what you are looking for.
Jetty can be made very small so the overhead is not bad.
You could consider Spring dmServer. It's a rather non-traditional appserver, with a very lightweight OSGi core (the web container is optional, for example), but it gives you classloader isolation and basic container services. It's not a JavaEE container, but comes with plug-in modules that are.
You're stlll going to have to do a lot of work yourself, but the basics of dmServer are very sound.
No one stops you from sending binary and text data instead of HTML-pages using http protocol. That is whats servlets are for. So I would use the tomcat server.