In the context of JBoss and Wildfly, what's the difference between a module and a subsystem?
Jboss modules is a class loading system:
JBoss Modules is a standalone implementation of a modular (non-hierarchical) class loading and execution environment for Java. In other words, rather than a single class loader which loads all JARs into a flat class path, each library becomes a module which only links against the exact modules it depends on, and nothing more. It implements a thread-safe, fast, and highly concurrent delegating class loader model, coupled to an extensible module resolution system, which combine to form a unique, simple and powerful system for application execution and distribution.
Guide for Class Loading in WildFly
Subsystems are the groups of customizable features of Jboss:
The EE subsystem provides common functionality in the Java EE platform, such as the EE Concurrency Utilities (JSR 236) and #Resource injection. The subsystem is also responsible for managing the lifecycle of Java EE application's deployments, that is, .ear files.
The EE subsystem configuration may be used to:
customise the deployment of Java EE applications,
create EE Concurrency Utilities instances,
define the default bindings
Guide for subsystem configuration
Related
I'm using:
Wildfly 21
Java 11
I've just went through the pain of modularizing (with Java 9 modules) an Jakarta EE EAR application of mine that runs on Wildfly 21. This application has a war jar, ejb jars, utility jars (all have a module-info.java now) and other third party libraries. The whole application compiles well, without errors.
But I noticed that when I run it in Wildfly, althought it runs without problems as before when it wasn't modular, it seems that the application server is not considering that it is now a modular application and is not using the modulepath to run the application, but the classpath. So, at runtime, the modular nature of the application is being ignored.
Is there a way to instruct the application server to run the application as a modular one, using the modulepath instead of the classpath?
It's a pity that we have to be locked by application servers like Wildfly blocking us from using such an important Java feature (modules) at runtime in our applications.
While Wildfly doesn't support running modular wars, you can take a look at Piranha Cloud.
The Piranha Server itself can run in the module path and can deploy WARs in a new JPMS layer, respecting the module-info.class provided.
https://piranha.cloud/blog/2021/20210128_Modular_applications_with_JPMS
PS: I'm a Piranha Cloud developer
Why Eclipse Glassfish does not support Eclipse Microprofile ?
And I am confused about Eclipse Microprofile Application,
Eclipse Microprofile Application can be a servlet application(war) nor ony a jar application?
I think servlet-api not nessary for Eclipse Microprofile Application.
I'll start with your last question and work backwards.
You are correct. The Servlet API is not part of Eclipse MicroProfile. So an implementation of the MicroProfile spec need not support servlet. If you take a look at the various MicroProfile implementations you'll see that some of them are derived from application servers, and some are not. Those that have roots in an application server might support servlet, but others might not.
The MicroProfile spec does not specify application packaging or deployment. Just the APIs that must be supported. So some MicroProfile implementations might support war files (likely those with roots in application servers) but others won't. Most of them will support some form of an executable jar and runtime dependency management so that you can create a self-contained, immutable Docker image of your application and its runtime dependencies. In this scenario the value of war packaging is questionable.
Eclipse GlassFish is a Jakarta EE implementation, and the focus has been to deliver a Jakarta EE 8 release. MicroProfile is part of Eclipse, but it is not part of Jakarta EE (at least not yet). So there is no requirement for Eclipse GlassFish to implement MicroProfile (at least not yet).
I have the following issue.
I have a dao library using the atomikos JTA transaction manager.
Also I have a web project that includes that dao library.
And although the tomcat lib folder includes all the required atomikos libraries, I still need to include the atomikos dependency (maven) with scope compile on the library (such that it is packaged along, or at least Eclipse knows it has to be packaged along).
If the library is not packaged along I get Class not found exceptions when deploying under eclipse/STS.
Since the Atomikos libraries are only required for development environments, I don't want these libraries to have scope compile (or runtime).
How can I change my tomcat eclipse setup such that I can set my atomikos dependencies with scope provided in my dao library.
Any suggestions?
i' ve some web applications developed using Seam Framework 2.3 + jBoss AS 7 + Hybernate.
Since i' ve been studying OSGI for a while, i was wondering if is possible to move my applications to the osgi world for modularizing everything; i' ve read a lot of blogs and these interesting discussions as well (how-to-modularize-an-enterprise-application-with-osgi-and-ee6 and how-to-modularize-a-jsf-facelets-spring-application-with-osgi) but honestly i still don't really know where i should start from, since i' ve never used OSGI before.
According to you
Is it possible (and useful) do such things?
According to your experience, what would be a good starting point?
Thanks for help
Approach
Possibly start with a toy application as a spike, a WAB (OSGi WAR) and single service bundle.
Definitely take an iterative approach. As far as I know JBoss supports the mixing of OSGi services and Java EE stuff, via JBoss modules/msc, this will allow you to try OSGi and migrate gradually.
I think you'll find some things are incredibly easy and others very hard, so pick easy battles while you're getting familiar. In the end you may stick with a hybrid approach.
Build
What's your build tool? Mostly like Maven or Ant, in which case have a look at maven-bundle-plugin
or bnd respectively. You'll need to ensure the OSGi metadata is present in each of your bundles (Bundle-SymbolicName, Import-Package, Export-Package, etc). If you're using Maven see this answer.
It can be tricky to divide a monolithic app into modules, but as a general rule when you migrate a reasonable sized module you should have separate bundles for API and implementation (which is good design anyway but has implications for the runtime too).
Interop
You can acquire OSGi services, access bundles etc using the low level framework APIs from an injected BundleContext, which will give you a low-level programmatic hook into OSGi. It should be as simple as:
#Resource
BundleContext context;
Unless your Java EE code is packaged as JBoss modules I don't think it will be easy for you to call the other way (e.g. OSGi service looking up Java EE service) without resorting to something like JNDI.
You should be able to install the webconsole and see what Java EE bits are registered in OSGi, and similarly check JNDI to see what's available OSGi for Java EE.
Migrating Services
While OSGi is a lot of fun, using the raw framework API results in quite a bit of boilerplate code and it's unlikely you'll need the power or want the coupling. You can use a number of dependency injection frameworks on top of OSGi; blueprint (Spring-like), Peaberry (Guice) and Declarative Services for example.
I'm biased but Declarative Services has a strong affinity to the OSGi µservice model and the implementations are lightweight.
CDI
I don't know much about Seam/CDI, but Pax CDI might help (though JBoss might already have covered this).
Web
Are you planning to have a highly modular UI with hot deploy of the various components? If not then probably best just to package the UI as a WAB. A WAB is a skinny WAR (i.e. it imports rather than embeds most dependencies). Even if you're after a highly modular, dynamic frontend, I would definitely do this for the first pass.
JPA
A word of warning - JPA implementations typically don't play well in OSGi environments, you may want to look at Apache Aries or Eclipse Gemini. Another option might be to leave the JPA stuff in Java EE space and access Java EE DAOs/Repositories as OSGi services. Again though you may experience some classloading issues.
Possibly useful examples https://docs.jboss.org/author/display/JBOSGI/Provided+Examples
I am planning to develop a medium to large size web application using JSF (plus PrimeFaces or other) for the view layer and EJB3 for business logic. The reason we've chosen EJB3 over more lightweight JSF beans that might only require a Servlet container (as opposed to an EJB3 container) is for additional EJB3 features like security. Since we are targeting deployment on JBoss AS I was wondering what IDE solution you would recommend. I've seen that both Eclipse and Netbeans support JBoss either out-of-the-box or with plugins.
Or even you can try IntelliJ Idea. All these IDEs has a support for all common servers (including JBoss) so that's really not a criterium for choosing IDE.
It just depends on what you are used to and if you have one of these IDEs already running (with Maven, Ant, SVN, Git or whatever you use for your project) then just go with it:-)