Configure JDBC driver in JBoss 7 - as a deployment OR as a module? - deployment

As mentioned in the article https://community.jboss.org/wiki/DataSourceConfigurationInAS7 JBoss 7 provides 2 main ways to configure a data source.
What is the BEST practice of configuring a data source in JBoss 7 AS ? Is it
As a module?
As a deployment?
(The same question has been asked in the thread https://community.jboss.org/thread/198023, but no one has provided an acceptable answer yet.)

The guide JBoss AS7 DS configuration says the recommended way is to configure the datasource by deployment
But according to discussion on the link Jboss 7 DS configuration JBoss Community Discussion on page 54 of the guide it mentions that the recommended way to deploy JDBC driver is to use modular approach
But I personally say that the better(not the best) approach to configure JDBC driver would be to use modules because of 3 reasons
JDBC driver will generally not change.
Re-usability : You can use the same module across various applications and not deploy the jar along with each application, this prevents duplicacy
Space Effective : Using the module approach lets you reduce the size of your EAR/WAR as you do not need to supply the jar with the package
Hence I would argue that the better of the two approaches is via modules

#Mukul Goel
It's not necessary to include it the EAR of your application it's sufficient to put the .jar inside the deployments folder so:
no need to embed in ear
no need to create a module
Jist deploy in deployments folder or via admin console

Related

CDI and User Defined Functions (UDF) in Teiid / Wildfly

Recently I began working with Teiid and Wildfly. I have a user defined function (UDF) that adds custom functionality to Teiid, and it works as expected. However, I need to modify it further and would like to use CDI to inject a bean from the Wildfly app server. I know that the UDF isn't managed by the container (it is a Wildfly module with an associated module.xml file deployed as a jar), so I've added (what seemed to be) necessary dependencies to module.xml but it doesn't work.
Is it possible to use CDI in a UDF with Teiid / Wildfly, and if so, how?
No, it is not possible. although Teiid is a resident of WildFly it is using the infrastructure of WildFly for a variety of features like transactions, security, data sources, administration etc. It is not part of JEE or anything, so there is no direct way to do this. If you want to explain what you are trying to accomplish, maybe we can offer any further guidance on alternatives.

How do I see what a JBoss deployment uses?

In a JBoss environment (specifically EAP 6) with several JARs deployed, several data sources, a lot of system properties, etc. How can I find what a particular JAR users?
For example, is there anyway I can see that "deployment-1.jar" uses "datasource-1" "system-property-2" and "system-property-5"?
What about the reverse? Eg finding out which deployments use a particular datasource?
Note: I'm looking at this from the perspective of an App Admin, maintaining a production system without necessarily having access to the source code.

Standalone example on jberet (jsr352)

Is there anyway to use jberet as standalone module to execute Batch Jobs?
All the time getting samples on using along with WildFly.
Surprised to see it looks for container to load implementations while trying some samples.
Any insights on why/why not would be helpful
Here is a tutorial how to use jberet in a standalone application:
http://www.mastertheboss.com/batch-api/running-batch-jobs-in-j2se-applications
You'll need to include various jboss dependencies for it to work.
Furthermore you need to configure jberet with a separate jberet.properties.
I've build a (hopefully) minimal example application according to the tutorial.
You can find it here: https://github.com/kaape/jberet-standalone-example
More information can be found in the jberet github repository:
https://github.com/jberet
I created a similar example but uses JDBC chunk oriented processing. https://github.com/lbtc-xxx/jberet-se-example
JBeret project test-apps sub-module (https://github.com/jberet/jsr352/tree/master/test-apps) contains various test apps that are structured as standalone Java SE applications (except restAPI where WildFly appserver is needed).
For JBeret + WildFly samples, please check out JBeret project wildfly-jberet-samples module:
https://github.com/jberet/jsr352/tree/master/wildfly-jberet-samples

Determining version of jboss programmatically between jboss 5 and 7

I'm trying to find the best way to grammatically determine if my program is running on Jboss 5 or Jboss 7 (eap-6.1). The ways I've been finding so far are jboss 5 or jboss 7 specific, which doesn't work because the code has to work in both. Tried both solutions from here: How do I programmatically obtain the version in JBoss AS 5.1? and they didn't work. One complained about org.jboss.Main not existing in jboss 7, the other complained aobut not finidng "jmx/rmi/RMIAdaptor".
The only way I can see is to do Class.forName to look for "org.jboss.Version" (should be found if jboss 5) and if that fails, do Class.forName "org.jboss.util.xml.catalog.Version" (jboss 7). But that seems like a terrible idea.
The reason I need to know if the war is running on jboss 5 or 7 is because there are some custom files that are located in different places in both. So it's like "if jboss 5, execute this piece of code, if jboss 7 execute the other.
Ok i just saw what the problem is.
I would suggest you to think about design issues/refactoring of your software.
If you want to provide your software within different environments, seperate your logic from
technology dependencies.
Build facedes and interfaces to meet environmental requironments.
In my oppionen thats much better as to think we must support all integration platforms and support all there versions. This is completely impossible.
So decouple your business logic and offer specific interfaces. These interfaces (adapters) are much simplier to implement and to maintain.
Hope it helps.
UPDATE DUE TO COMMENT.
I think a solution is for servers 4 to 6 is to use
the MBean Server of JBoss to lookup the registered web application
which is associated to the deployed WarFile.
I suggest first to lookup the registered MBean of the web application manually using the JBoss jmx-console. The name of the WebApplication should be found under the capital "web" or "web-deployment" within the jmx-console.
If you found that name you can implement an own jmx based lookup mechanism
to check for that name.
Here is an Tutorial: pretty old but i think it gives you an idea how to do.
There must be more tutorials for this problem:
http://www.theserverside.com/news/1364648/Using-JMX-to-Manage-Web-Applications
Within JBoss 7 i just can give you the hint that its architecture is based on OSGI. So to lookup for other services you should have a look to this mechanism.
In any case you don't have direct access to the file system and the deployment directory
from an application which is deployed within a JEE container, except of
using the mechanisms provided by the container. JNDI Lookup, JMX ManagedBean mechanism, Java Connector Archicture (JCA) (makes no sense in your case)
It's not an answer just an suggestions since the implementations are completely different
One way could be to use the "interceptors" which are executed during bootstrap and before any ejb invocation and there you have access to the invocation context in other words ejb container.
I can't give you any example but this would be an access point to start.
Another accesspoint is to check for system wide JMX Beans by looking through the
Adminstratore console of the JBoss Server.
You can inject JMX Bean state into your application through the Context Mechansim.
Take a look from Version 4 to 6 at the JMX Managed Bean mechanism. The JMX Achitecture is the main concept of JBoss 3 to 6, so at this point you can influence and maintain the JBoss behaviour.
Aditionally i think you have differences from 4 to 6.x version and 7.0 because since
7 it's a completely new architecture. Since 7.0 the JMX architecture doens't exists anymore.

Difference between jboss 6 and jboss 7 standalone server?

I was using Jboss 6 . I am wondering to see jboss 7 which does not have many folders that jboss 6 had. It will be helpful if someone explains the difference between the jboss 7 stand alone server and the previous versions.
AS7 is different in a lot of respects to its predecessors AS6,5. So it wont be possible to list down all the differences here.
to list supported technology related differences, refer to below table.
Some Major Differences: (Thanks for #Jyore for additions)
Modular (on-demand) class-loading
Addition of domain managed nodes (multiple JVM management)
All configuration is done in Standalone.xml for standalone mode and domain.xml for domain mode.
About the new DIRECTORY Structure
configuration : Configuration files for the standalone server that runs off of this installation. All configuration information for the running server is located here and is the single place for configuration modifications for the standalone server.
data :Persistent information written by the server to survive a restart of the server
deployments: End user deployment content can be placed in this directory for automatic detection and deployment of that content into the server's runtime.
NOTE: The server's management API is recommended for installing deployment content. File system based deployment scanning capabilities remain for developer convenience.
lib/ext : Location for installed library jars referenced by applications using the Extension-List mechanism
log : standalone server log files
tmp : location for temporary files written by the server
Apart from that I really dont want to duplicate information on web
There is a migration guide from AS5,AS6 to AS7. This can help you understand what are the config changes that are generally required to switch to AS7. it also points out what has significantly changed, highly recommend going through it.
Also You can read Getting Started with AS7, to know AS7 better