[JBoss Web Development] - Authorization issue while implementing login module with DatabaseServerLoginModule
by sidd deo
sidd deo [http://community.jboss.org/people/c-ddhesh] created the discussion
"Authorization issue while implementing login module with DatabaseServerLoginModule"
To view the discussion, visit: http://community.jboss.org/message/586633#586633
--------------------------------------------------------------
Hi all
I am new to jboss. I am trying to implement form based authentication using DatabaseServerLoginModule using jboss (http://www.coderanch.com/forums/f-63/JBoss) 6.0
By referring guides and several tutorials I implemented and configured it. My application is working till authentication phase.
Authorization fails giving following errors in logs. Here are my logs
11:18:53,240 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] Obtained user password
11:18:53,240 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] resumeAnyTransaction
11:18:53,240 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] User'sidd' authenticated, loginOk=true
11:18:53,240 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] commit, loginOk=true
11:18:53,240 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] getRoleSets
using rolesQuery: SELECT Role, RoleGroup FROM Roles WHERE PrincipalID=?,username: sidd
11:18:53,256 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] suspendAnyTransaction
11:18:53,256 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] Excuting query:
SELECT Role, RoleGroup FROM Roles WHERE PrincipalID=?, with username: sidd
11:18:53,256 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] Assign user to role WebAppUser
11:18:53,256 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] resumeAnyTransaction
11:18:53,256 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.my-web] defaultLogin,
lc=javax.security.auth.login.LoginContext@1b7a59c, subject=Sub
ject(21185284).principals=org.jboss.security.SimplePrincipal(a)15004845(sidd)org.j
boss.security.SimpleGroup@24878804(WebAppUser(members:WebAppUser))
11:18:53,256 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.my-w
eb] updateCache, inputSubject=Subject(21185284).principals=org.jboss.security.Si
mplePrincipal@15004845(sidd)org.jboss.security.SimpleGroup(a)24878804(WebAppUser(m
embers:WebAppUser)), cacheSubject=Subject(16292112).principals=org.jboss.securit
y.SimplePrincipal@15004845(sidd)org.jboss.security.SimpleGroup(a)24878804(WebAppUs
er(members:WebAppUser))
11:18:53,256 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.my-w
eb] Inserted cache info: org.jboss.security.plugins.auth.JaasSecurityManagerBase
$DomainInfo(a)10908b5[Subject(16292112).principals=org.jboss.security.SimplePrinci
pal@15004845(sidd)org.jboss.security.SimpleGroup@24878804(WebAppUser(members:Web
AppUser)),credential.class=java.lang.String@13809944,expirationTime=129731868574
1]
11:18:53,256 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.my-w
eb] End isValid, true
11:18:53,256 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.my-w
eb] getPrincipal, cache info: org.jboss.security.plugins.auth.JaasSecurityManage
rBase$DomainInfo(a)10908b5[Subject(16292112).principals=org.jboss.security.SimpleP
rincipal@15004845(sidd)org.jboss.security.SimpleGroup(a)24878804(WebAppUser(member
s:WebAppUser)),credential.class=java.lang.String@13809944,expirationTime=1297318
685741]
11:18:53,272 TRACE [org.jboss.security.SecurityRolesAssociation] Setting threadl
ocal:null
11:18:53,272 TRACE [org.jboss.security.SecurityRolesAssociation] Setting threadl
ocal:{}
11:18:53,272 TRACE [org.jboss.security.plugins.authorization.JBossAuthorizationC
ontext] Control flag for entry:org.jboss.security.authorization.config.Authoriza
tionModuleEntry{org.jboss.security.authorization.modules.DelegatingAuthorization
Module:{}REQUIRED}is:[REQUIRED]
11:18:53,287 TRACE [org.jboss.security.SecurityRolesAssociation] Setting threadl
ocal:null
Here is my Databse called book having following structure
CREATE TABLE IF NOT EXISTS Principals (
PrincipalID varchar(30) NOT NULL PRIMARY KEY,
Password varchar(50) NOT NULL
) ENGINE=INNODB;
CREATE TABLE IF NOT EXISTS Roles (
PrincipalID varchar(30) NOT NULL,
INDEX (PrincipalID),
Role varchar(50) NOT NULL,
RoleGroup varchar(50) NULL,
PRIMARY KEY(PrincipalID, Role),
CONSTRAINT Roles_Principal_FK FOREIGN KEY (PrincipalID)
REFERENCES Principals (PrincipalID) ON DELETE CASCADE
) ENGINE=INNODB;
values of "PrincipalID" and "Password" are "sidd" and "pass".
values "PrincipalID" "Role" "RoleGroup" are "sidd" "WebAppUser" "WebAppUser"
My web.xml is as follows
<?xml version="1.0"?>
<web-app>
<description>A test app for security</description>
<security-constraint>
<web-resource-collection>
<web-resource-name>All resources</web-resource-name>
<description>Protects all resources</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>WebAppUser</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>WebAppUser</role-name>
</security-role>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/errors.html</form-error-page>
</form-login-config>
</login-config>
</web-app>
login-config.xml has following entry
<application-policy name="my-web">
<authentication>
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule"
flag="required">
<module-option name="dsJndiName">java:/MySqlDS</module-option>
<module-option name="principalsQuery">SELECT Password FROM Principals WHERE PrincipalID=?</module-option>
<module-option name="rolesQuery">SELECT Role, RoleGroup FROM Roles WHERE PrincipalID=?</module-option>
</login-module>
</authentication>
<authorization>
<policy-module code="org.jboss.security.authorization.modules.DelegatingAuthorizationModule" flag="required"/>
</authorization>
</application-policy>
jboss-web.xml has following text
<?xml version='1.0' encoding='UTF-8' ?>
<jboss-web>
<security-domain>java:/jaas/my-web</security-domain>
</jboss-web>
Even if I remove
<authorization>
<policy-module code="org.jboss.security.authorization.modules.DelegatingAuthorizationModule" flag="required"/>
</authorization>
from login-config.xml, I get the same error.
As per the logs, user "sidd" is getting authenticated successfully. But on GUI i see
HTTP Status 403 - Access to the requested resource has been denied
type Status report
message Access to the requested resource has been denied
description Access to the specified resource (Access to the requested resource has been denied) has been forbidden.
Am i missing on any flag or any configuration ?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/586633#586633]
Start a new discussion in JBoss Web Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years
[JBoss Messaging Development] - MESSAGE DRIVEN BEAN STOPS WORKING
by Rishi k
Rishi k [http://community.jboss.org/people/rishi321] created the discussion
"MESSAGE DRIVEN BEAN STOPS WORKING"
To view the discussion, visit: http://community.jboss.org/message/596668#596668
--------------------------------------------------------------
when the server starts up I can see it checking for messages, but for some times it doesn't try to grab messages any more. I haven't monitored it that closely to know the exact timing, but I know it's not even trying to check because I have it in debug mode and I don't see the message commands being executed at all and also messages are queued not grab by message driven.
here is my ejb-jar.xml
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar id="ejb-jar_ID" version="3.0" xmlns=" http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee"
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=" http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
<display-name>MessageEJB</display-name>
<enterprise-beans>
<message-driven>
<display-name>MessageBean</display-name>
<ejb-name>MessageBean</ejb-name>
<ejb-class>com.ecomm.ejb.mdb.MessageBean</ejb-class>
<messaging-type>javax.jms.MessageListener</messaging-type>
<transaction-type>Container</transaction-type>
<message-destination-type>javax.jms.Queue</message-destination-type>
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Queue</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>destination</activation-config-property-name>
<activation-config-property-value>/queue/ExpiryQueue</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
</enterprise-beans>
Here is my Jboss.xml
<?xml version="1.0"?>
<jboss>
<enterprise-beans>
<message-driven>
<ejb-name>MessageBean</ejb-name>
<destination-jndi-name>/queue/ExpiryQueue</destination-jndi-name>
<resource-ref>
<!-- <res-ref-name>jms/QCF</res-ref-name>
<jndi-name>ConnectionFactory</jndi-name>
-->
<res-ref-name>MessageBean</res-ref-name>
<jndi-name>/queue/ExpiryQueue</jndi-name>
</resource-ref>
</message-driven>
</enterprise-beans>
</jboss>
and ejb
/** * Message-Driven Bean implementation class for: MeaageBean * */@MessageDriven(mappedName = "/queue/ExpiryQueue", activationConfig = { @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")})public class MessageBean implements MessageListener {
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/596668#596668]
Start a new discussion in JBoss Messaging Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years
[EJB3 Development] - Problem keeping a user logged between threads
by Mario Bislick
Mario Bislick [http://community.jboss.org/people/kitome] created the discussion
"Problem keeping a user logged between threads"
To view the discussion, visit: http://community.jboss.org/message/596638#596638
--------------------------------------------------------------
Hey everyone! First of all I am new using JBoss and wasn't sure if this was the right place where to put my qustion so I apologize if it wasn't.
I have an application that is autheticating using JAAS against a database, the queries are fine and it actually authenticates the user using a setSimple(userLogin, pwd). The client has its domain defined and some of the class functions can only be accessed if the user has the appropiate roles. The problem is that once I authenticate the user in the main thread, it seems like if i have to authenticate again in each of the child threads of the client, calling it the function I use to authenticate with a null user and a null pasword (thus throwing an exception)
I think that theres gotta be someway for the server/client to remember that the user is actually authenticated so it wont be authenticated more than once in each thread of the application. Is that actually paussible? Or how do I prevent the server/client from doing it after I authenticated the user the first time?
There is no logout call in the code other than the one I use if the (userLogin, pwd) combination is invalid.
Hope anyone can help me with this.
Thanks.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/596638#596638]
Start a new discussion in EJB3 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 1 month
[IronJacamar Development] - IronJacamar Management
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] created the document:
"IronJacamar Management"
To view the document, visit: http://community.jboss.org/docs/DOC-16674
--------------------------------------------------------------
h1. IronJacamar management
The goal of this page is to describe the management features of the IronJacamar container, the design and key implementation classes.
*
#IronJacamar_management IronJacamar management
**
#Requirements Requirements
**
#Design Design
**
#Features Features
**
#Implementation Implementation
**
#Test_suite Test suite
**
#Related Related
h2. Requirements
The overall requirements are
* Show the configuration of deployed resource adapters and datasources
* Show statistics for resource adapters and datasources
* Apply changes to the configuration of deployed resource adapters and datasources
* Invoke operations on the deployed resource adapters and datasources
h2. Design
We should a central place where the management view of resource adapters and datasources are registered (ManagementRepository).
This repository provides access to classes (Connector / DataSource) that represent a single deployment of either a resource adapter or a datasource.
Each of these classes are split into a hierarchy where information about the deployment and references to the live objects are maintained. It must be a design goal that the management classes uses methods from the public API of the IronJacamar container.
ManagementRepository
|
|- Connector
| |
| |- Resource Adapter
| |
| |- Connection Factories
| |
| |- Admin Objects
|
|- DataSource
See a description of each class below.
h2. Features
h2.
Implementation
The implementation is located in the core module of the IronJacamar repository. The package is
org.jboss.jca.core.api.management
h2. Test suite
h2. Related
* JBoss Application Server 7
* http://community.jboss.org/docs/DOC-16378 RHQ platform
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16674]
Create a new document in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 1 month
[JBoss Tools Development] - How to Build JBoss Tools with Maven 3
by Andre Dietisheim
Andre Dietisheim [http://community.jboss.org/people/adietish] modified the document:
"How to Build JBoss Tools with Maven 3"
To view the document, visit: http://community.jboss.org/docs/DOC-16604
--------------------------------------------------------------
+*This article is a replacement for its precursor, http://community.jboss.org/docs/DOC-15513 How to Build JBoss Tools 3.2 with Maven 3.*+
h2. Prerequisites
1. Java 1.6 SDK
2. Maven 3
3. Ant 1.7.1 or later
4. About 6 GB of free disk space if you want to run all integration tests for (JBoss AS, Seam and Web Services Tools)
5. subversion client 1.6.X (should work with lower version as well)
h2. Environment Setup
h3. Maven and Java
Make sure your maven 3 is available by default and Java 1.6 is used.
mvn -version
should print out something like
*Apache Maven 3.0.2* (r1056850; 2011-01-08 19:58:10-0500)
*Java version: 1.6.0_20*, vendor: Sun Microsystems Inc.
*Java home: /usr/java/jdk1.6.0_20/jre*
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.32.23-170.fc12.i686", arch: "i386", family: "unix"
h2.
h2. Building Locally Via Commandline
To run a local build of JBoss Tools 3.3 against the new Eclipse 3.7-based Target Platform, I suggest a three-step approach:
a) build the parent & target platform poms (v0.0.3-SNAPSHOT) *[ONLY NEEDED WHEN THESE CHANGE]*
b) resolve the target platform to your local disk *[ONLY NEEDED WHEN THESE CHANGE]*
c) build against your local copy of the target platform [every time you change sources and want to rebuild]
Once (a) and (b) are done, you need only perform (c) iteratively until you're happy (that is, until everything compiles). This lets you test changes locally before committing back to SVN.
*(a) and (b) need only be done when the parent pom and Target Platform (TP) change.* Of course if we get these published to nexus then you may not need those first bootstrapping steps. Stay tuned - work in progress.
*a) build the parent & target platform poms (v0.0.3-SNAPSHOT)*
cd ~/
svn co http://svn.jboss.org/repos/jbosstools/branches/3.3.indigo/ http://svn.jboss.org/repos/jbosstools/branches/3.3.indigo/
cd ~/3.3.indigo/build/parent
mvn3 clean install
*b) resolve the target platform to your local disk*
There are two ways to do this:
i) Download and unpack the latest TP zip
ii) Resolve the TP using Maven or Ant
+i) Download and unpack the latest TP zip+
You can either download the TP as a zip [5] and unpack it into some folder on your disk. For convenience, you might want to unzip into ~/3.3.indigo/build/target-platform/REPO/, since that's where the Maven or Ant process will by default operate.
[5] http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/e... http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/e...
+ii) Resolve the TP using Maven or Ant+
cd ~/3.3.indigo/build/target-platform
mvn3 clean install -Pget.local.target
The get.local.target profile will resolve the target platform file, multiple.target, as a p2 repository on your local disk in ~/3.3.indigo/build/target-platform/REPO/. It may take a while, so you're better off from a speed point-of-view simply fetching the latest zip [5]. However, if you want to see what actually happens to create the TP (as done in Hudson) this is the approach to take.
Since the Maven profile is simply a wrapper call to Ant, you can also use Ant 1.7.1 or later directly:
cd ~/3.3.indigo/build/target-platform
ant
Should you want to build the JBDS target, do this:
cd ~/3.3.indigo/build/target-platform
ant jbds
Then you'll get a p2 repo in ~/3.3.indigo/build/target-platform/JBDS_REPO/.
*c) build against your local copy of the target platform*
*LINUX / MAC USERS*
cd ~/3.3.indigo/build
mvn3 clean install -U -B -fae -e -P local.site -Dlocal.site=file:/${HOME}/3.3.indigo/build/target-platform/REPO/ | tee build.all.log.txt
(tee is a program that pipes console output to BOTH console and a file so you can watch the build AND keep a log.)
*WINDOWS USERS*
cd c:\3.3.indigo\build
mvn3 clean install -U -B -fae -e -P local.site-Dlocal.site=file:///C:/3.3.indigo/build/target-platform/REPO/
or
mvn3 clean install -U -B -fae -e -Plocal.site-Dlocal.site=file:///C:/3.3.indigo/build/target-platform/REPO/ > build.all.log.txt
If you downloaded the zip and unpacked is somewhere else, use -Dlocal.site=file:/.../ to point at that folder instead.
If you would rather build a single component (or even just a single plugin), go into that folder and run Maven there:
cd ~/3.3.indigo/build/jmx
mvn3 clean install -U -B -fae -e -P local.site -Dlocal.site=file:/${HOME}/3.3.indigo/build/target-platform/REPO/ | tee build.jmx.log.txt
#
h2. Building Locally In Eclipse
First, you must have installed m2eclipse into your Eclipse (or JBDS). You can install the currently supported version from this update site:
http://download.jboss.org/jbosstools/updates/indigo/ http://download.jboss.org/jbosstools/updates/indigo/
Next, start up Eclipse or JBDS and do *File > Import* to import the project(s) you already checked out from SVN above into your workspace.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-9-1387... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-9-...
Browse to where you have the project(s) checked out, and select a folder to import pom projects. In this case, I'm importing the parent pom (which refers to the target platform pom). Optionally, you can add these new projects to a working set to collect them in your Package Explorer view.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-9-1387... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-9-...
Once the project(s) are imported, you'll want to build them. You can either do *CTRL-SHIFT-X,M (Run Maven Build),* or right-click the project and select *Run As > Maven Build*. The following screenshots show how to configure a build job.
First, on the *Main* tab, set a *Name*, *Goals*, *Profile*(s), and add a *Parameter*. Or, if you prefer, put everything in the *Goals* field for simplicity:
+clean install -U -B -fae -e -Plocal.site -Dlocal.site=file://home/nboldt/tmp/JBT_REPO_Indigo/+
Be sure to check *Resolve Workspace artifacts*, and, if you have a newer version of Maven installed, point your build at that *Maven Runtime* instead of the bundled one that ships with m2eclipse.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-9-1387... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-9-...
On the *JRE* tab, make sure you're using a 6.0 JDK.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-9-1387... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-9-...
On the *Refresh* tab, define which workspace resources you want to refresh when the build's done.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-9-1388... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-9-...
On the *Common* tab, you can store the output of the build in a log file in case it's particularly long and you need to refer back to it.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-9-1388... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-9-...
Click *Run* to run the build.
http://community.jboss.org/servlet/JiveServlet/showImage/102-16604-9-1388... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-16604-9-...
Now you can repeat the above step to build any other component or plugin or feature or update site from the JBoss Tools repo. Simply import the project(s) and build them as above.
h2. Tips an tricks for making BOTH PDE and Maven happy
It's fairly common to have plugins compiling in eclipse while tycho would not work. Basically you could say that tycho is far more picky compared to Eclipse PDE.
h3.
Check your build.properties
Check build.properties in your plugin. If it has warnings in Eclipse, you'll most likely end with tycho failing to compile your sources.
Especially check your build.properties to have entries for *source..* and *output..*
*
*
source.. = src/
output.. = bin/
h2.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16604]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 1 month
[JBoss AS7 Development] - Data Source Configuration in AS 7
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] modified the document:
"Data Source Configuration in AS 7"
To view the document, visit: http://community.jboss.org/docs/DOC-16657
--------------------------------------------------------------
*
#Using_DataSourceDefinition_to_configure_a_DataSource Using @DataSourceDefinition to configure a DataSource
*
#Defining_a_Managed_DataSource Defining a Managed DataSource
**
#Installing_the_JDBC_Driver Installing the JDBC Driver
***
#Installing_a_JDBC_driver_as_a_deployment Installing a JDBC driver as a deployment
****
#Modify_the_JAR Modify the JAR
****
#Deploy_the_JAR_with_an_overlay Deploy the JAR with an overlay
***
#Installing_a_JDBC_driver_as_a_module Installing a JDBC driver as a module
**
#Defining_the_DataSource_itself Defining the DataSource itself
In older versions of the application server, data source configuration was tied to a *-ds.xml file schema that you would deploy in the deploy directory of your configuration. In AS 7, the entire structure of the AS is different, and as you would expect, creating your own data sources is different as well.
h1. Using @DataSourceDefinition to configure a DataSource
Since Java EE6, the new annotation "@DataSourceDefinition" has existed to allow users to configure a data source directly from within their application. (Note that this annotation bypasses the management layer and as such it is recommended only for development and testing purposes.) This annotation requires that a data source implementation class (generally from a JDBC driver JAR) be present on the class path (either by including it in your application, or deploying it as a top-level JAR and referring to it via MANIFEST.MF's Class-Path attribute) and be named explicitly.
h1. Defining a Managed DataSource
In order for a data source to be managed by the application server (and thus take advantage of the management and connection pooling facilities it provides), you must perform two tasks. First, you must make the JDBC driver available to the application server; then you can configure the data source itself. Once you have performed these tasks you can use the data source via standard JNDI injection.
h2. Installing the JDBC Driver
The JDBC driver can be installed into the container in one of two ways: either as a deployment or as a core module. There are pros and cons to each approach, which will be outlined below.
h3. Installing a JDBC driver as a deployment
The recommended way to install a JDBC driver into the application server is to simply deploy it as a regular JAR deployment. The reason for this is that when you run your application server in domain mode, deployments are automatically propagated to all servers to which the deployment applies; thus distribution of the driver JAR is one less thing for administrators to worry about.
Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version. A JDBC JAR is identified using the Java service provider mechaism. Such JARs will contain a text a file named "META-INF/services/java.sql.Driver", which contains the name of the class(es) of the Drivers which exist in that JAR. If your JDBC driver JAR is not JDBC 4-compliant, it can be made deployable in one of a few ways.
h4. Modify the JAR
The most straightforward solution is to simply modify the JAR and add the missing file. You can do this from your command shell by:
1. Change to, or create, an empty temporary directory.
2. Create a "META-INF" subdirectory.
3. Create a "META-INF/services" subdirectory.
4. Create a "META-INF/services/java.sql.Driver" file which contains one line - the fully-qualified class name of the JDBC driver.
5. Use the "jar" command-line tool to update the JAR like this:
jar -uf jdbc-driver.jar META-INF/services/java.sql.Driver
h4. Deploy the JAR with an overlay
(TODO)
h3. Installing a JDBC driver as a module
Under the root directory of the application server, is a directory called modules (e.g. jboss-7.0.0.<release>/modules). In this example, I will create the MySQL module in the same tree as the H2 database. The H2 database, which comes preconfigured, like the old DefaultDS with Hypersonic, is under the com/h2database/h2 directory, under the modules directory. So, the first step is to create a directory structure simlar to that for MySQL. I created, under com, a mysql directory, plus a main directory. So, at this point it should like like the following:
jboss-7.0.0.<release>/modules/com/mysql/main
Under the main directory, you need to define your module with a module.xml file, and the actual jar file that contains your database driver. In my case, the mysql-connector-java-5.1.15.jar file. This is in contrast to putting the database driver jar file in the old lib directory under your configuration where you deployed your *-ds.xml file. Also, the jar file must have a META-INF/services/java.sql.Driver file. This is due to the way AS 7 will load the driver. Fortunately, the MySQL JDBC driver jar file has this. So, what's the content of the module.xml file.
It's fairly straightforward, and is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<!--
~ JBoss, Home of Professional Open Source.
~ Copyright 2010, Red Hat, Inc., and individual contributors
~ as indicated by the @author tags. See the copyright.txt file in the
~ distribution for a full listing of individual contributors.
~
~ This is free software; you can redistribute it and/or modify it
~ under the terms of the GNU Lesser General Public License as
~ published by the Free Software Foundation; either version 2.1 of
~ the License, or (at your option) any later version.
~
~ This software is distributed in the hope that it will be useful,
~ but WITHOUT ANY WARRANTY; without even the implied warranty of
~ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
~ Lesser General Public License for more details.
~
~ You should have received a copy of the GNU Lesser General Public
~ License along with this software; if not, write to the Free
~ Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
~ 02110-1301 USA, or see the FSF site: http://www.fsf.org.
-->
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
<resources>
<resource-root path="mysql-connector-java-5.1.15.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
</dependencies>
</module>
As you can see from above, we give the module name, which in this example is com.mysql, which matches the directory structure we had created under the modules directory. If we had followed exactly the way the H2 database module was created we would have created something like com/mysqldatabase/mysql, and in that case the module name would have been com.mysqldatabase.mysql. I chose a shorted name in this case, but its just a matter of personal preference.
Besides the module name, we need to tell it where the implementation is, which is the resource-root tag with the path element. In that path element, we simply put the jar name. The path appears to be relative, and default to the main directory under the directory structure you created, which of course is com/mysql in our case.
Finally, you define any dependencies you might have. In this case, as the case with all JDBC data sources, we would be dependent on the Java JDBC API's, which in this case in defined in another module called javax.api, which you can find under modules/javax/api/main as you would expect.
That's really all there is to creating the module, but it will not be started as a service by AS 7, unless its referenced in the configuration. Now, just like everything else in AS 7, configuration is now completely different. There are two main configurations.
(TODO: let's put the driver config stuff first, then put the data source config in a separate Header 2 section...)
h2. Defining the DataSource itself
The first configuration is called domain, and has a domain directory under the root directory of the AS 7 distribution. This is a configuration that is geared toward multiple server instances and multiple server installations. The second is standalone, which is geared for a single instance of the server running on a single server, as you would expect. In regards to data source configuration, there really is no difference, as the datasource schema definition is the same in both cases. So regardless of which one you may be using in your particular case, the configuration is the same. For reference you can see the data source information here:
http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/deployment.htm...
In either standalone.xml or domain.xml you add the reference to the MySQL module as follows:
<datasource jndi-name="java:/MySqlDS" pool-name="MySqlDS" enabled="true" use-java-context="true">
<connection-url>
jdbc:mysql://localhost:3306/EJB3
</connection-url>
<driver-class>
com.mysql.jdbc.Driver
</driver-class>
* <driver>*
* com.mysql.jdbc.Driver#5.1*
* </driver>*
<transaction-isolation>
TRANSACTION_READ_COMMITTED
</transaction-isolation>
<pool>
<min-pool-size>
200
</min-pool-size>
<max-pool-size>
300
</max-pool-size>
<prefill>
true
</prefill>
<use-strict-min>
false
</use-strict-min>
</pool>
<security>
<user-name>
test
</user-name>
<password>
test
</password>
</security>
<validation>
<validate-on-match>
false
</validate-on-match>
<background-validation>
false
</background-validation>
<useFastFail>
false
</useFastFail>
</validation>
<statement>
<prepared-statement-cache-size>
100
</prepared-statement-cache-size>
<share-prepared-statements/>
</statement>
</datasource>
As you can see from above this looks remarkable similar to the old *-ds.xml file, and in fact, I carried over all the attributes I had in my old data source definition. The thing to point out here, is that this is within an outer tag called <datasources>, so obviously there can be more than one, just like before, but unlike before, they are all included in the one configuration file, either standalone.xml or domain.xml depending on which you are using. In each case the directory structure is as follows:
jboss-7.0.0.<release>/domain/configuration/domain.xml or
jboss-7.0.0.<release>/standalone/configuration/standalone.xml
The other important things to point out, besides the standard JDBC parameters, is the module tag above, and a new section called drivers which is within the "datasources" subsystem in the schema, but below the data sources themselves.
In the module tag above, you should specify the fully qualtified name of the JDBC driver class, appended with a pound sign (#), with the major and minor version number. In my example above its 5.1, since I am using the 5.1.15 driver from MySQL. It does not support the micro version number, so if you are tempted, as I was, to add it, it will cause your module to fail loading, which will then cascade to your application using this data source. So, then the drivers tag.
<drivers>
<driver module="com.mysql"/>
</drivers>
As you can see, what we put in this is the actual module name we defined in module.xml under jboss-7.0.0.<release>/modules/com/mysql/main/module.xml.
That's all there is to it. I have also attached a zip archive of the MySQL module that I created, plus my standalone.xml file, that you can use to make your own. If you want to create a MySQL module and data source, you can simply unzip the com.mysql.tar.gz under the modules directory of your AS 7 distribution, and cut and past the datasource tag in standalone.xml into your configuration, and of course change the database you are connecting to, plus the username and password, and other relevant parameters to suit your needs, and you will have a working MySQL data source.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16657]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 1 month
[Javassist Development] - Newbie question: How do you modify class members?
by Jason Perrone
Jason Perrone [http://community.jboss.org/people/jasonperrone] created the discussion
"Newbie question: How do you modify class members?"
To view the discussion, visit: http://community.jboss.org/message/596347#596347
--------------------------------------------------------------
Ok, I understand how to modify a class. I've obtained my CtClass from the ClassPool and I added a new member. Great. What I don't understand is how to replace the old version of this class in this ClassPool with the new version. This may be a basic mis-understanding of the JVM on my part. My understanding is that once you load a class, whether from a file or a class you constructed in the application, that that's it. It's there and you can't get rid of it. So, if I have a class called Potato in the ClassPool, and I get Potato:
CtClass ctClass = cp.get("Potato")
And then I add a member to this class. .. ctClass.addField(f);
I don't understand how to get the changed version of the class into the classpool. After my change above, Potato in the classpool is not modified. I thought it would be. But in reading about Javassist, it seems that you have to make a new class from the change by calling toClass on CtClass, but I can't call toClass on the CtClass because a class of that same name already exists in the ClassPool. Actually, the exact instructions from JavaAssist are:
1) Get the class from the classpool
2) Modify it
3) Either use writeFile(not applicable to me) to call toByteCode to get the new class definition. Ok, so I call toByteCode and get my new class definition (Potato with the new field). I figured that I then need to call defineClass() on the ClassLoader with the new byteCode but once again, the error that I can't compile the class because a class of the same name already exists.
So, when it comes to modifying a class, are you ever actually modifying the original class that was loaded, or are you just creating a new class that is cloned from the original class and then applying some changes to it?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/596347#596347]
Start a new discussion in Javassist Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 1 month
[JBoss AS7 Development] - JBAS-9149, Disappearing log messages
by Scott Stark
Scott Stark [http://community.jboss.org/people/starksm64] created the discussion
"JBAS-9149, Disappearing log messages"
To view the discussion, visit: http://community.jboss.org/message/595755#595755
--------------------------------------------------------------
This issue is coming up frequently of testing non-standard configurations of the server since the errors are tending to happen early on, so it is something I need fixed. I looked at the RootLoggerService and followed the logging down to the LoggerNode.publish(ExtLogRecord) to get a quick idea of what the path from the log messaes to the handlers is.
What if the LoggerNode.clearHandlers() accepts a List<LogRecord> and this is populated with all log msgs that attempt to be published while the handlers are being cleared, and then the RootLoggerService republishes these to the server.log. I'm thinking that duplicates between the logs are ok if it simplifies how this is done. Right now I really don't know all that is involved to capture these msgs, so I'll start along this approach. If it is the wrong way to go, chime in!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/595755#595755]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 1 month
[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow] modified the document:
"EJB3/JPA 2.0 support for AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about the AS7 JPA layer and related concerns. Its a rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
4. Managed entities are detached at transaction end time.
2. No transaction invocation
1. Managed entities are detached at end of EntityManager call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. Managed entities continue to be managed at transaction commit time.
5. Managed entities are detached at transaction rollback time.
6. XPC is closed when dependent session bean(s) are closed (via @remove method).
7. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
4. If invoked without a JTA transaction and a transaction scoped persistence context is used, will throw TransactionRequiredException for any calls to entity manager remove/merge/persist/refresh.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
1. Determine the available persistence providers following JPA 9.3 1. http://download.oracle.com/javaee/6/api/javax/persistence/spi/Persistence... PersistenceProviderResolver
2. http://download.oracle.com/javaee/6/api/javax/persistence/spi/Persistence... PersistenceProviderResolverHolder
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with (Hibernate 4.0).
7. EJB Container interaction
8. Desires1. Maintainable code (a ten minute fix will take ten minutes :)
2. Would like to do a better job of showing what is going on at the EM level (e.g. logging the EM units of work grouped by transaction).
3. Consider any EM (container) extensions that make it easier to measure performance (perhaps based on Hibernate statistics). Its always nice to see how long each transaction took and the units of work within the transaction. It would be nice if we could do this with any persistence provider (for performance comparison).
4. Deal with the Hibernate persistence provider via the same way as we would interact with other persistence providers (via PersistenceProvider mentioned above).
5. It should be easy to switch to a new persistence provider.
6. If an application bundles a persistence provider that is referenced from their persistence unit(s), use the bundled persistence provider (even if its a different version of a JPA 2.0 provider that is also available to all applications). This should handle bundling a different version of Hibernate.
7. Peace.
9. Questions1. The JPA specification section 7.9.1 (Container Responsibilities) implies that only one (container managed) entity manager will be associated with the JTA transaction. However, what if someone injects multiple persistence contexts (different persistent units) in separate entity managers for the same bean. Should that be considered an application error or allowed behaviour (e.g. each separate entity manager is joined to the JTA transaction). *ANSWER: we will allow it and design for it.*
2. For a few different cases, we will need to know which EntityManager was injected into a component. One such case is for XPC inheritance. For example, SFSB1 (with extended persistence context) gets injected into a web component and SFSB2 (with extended persistence context) gets injected into SFSB1. SFSB2 should inherit the XPC from SFSB1. Open question is how we want to maintain the bookkeeping for this. The JPA layer could expose a SPI like BeanToEntityManager{ List<EntityManager> getEntityManagers(); } that can be passed in on other SPI calls (basically depending on the EJB container to track injected EntityMangers via other magic). Another solution would be to track the mapping in the JPA layer (might be a pretty big map with a lot of weak references that need to be considerate of GC/undeploy concerns). Or perhaps there will some other solution that will appear for this. :)
3. What about injecting a Hibernate session or session factory as mentioned http://bill.burkecentral.com/2007/07/06/co-existence-with-hibernate-jpa-a... here and http://docs.jboss.org/ejb3/docs/reference/build/reference/en/html/hiberna... here. Do we want to carry this into AS7? Is there another way to do this that we would want to implement for AS7? [Emmanuel] I think this is valuable and quite natural. An alternative approach would be to let all injection logic be handle by Seam 3 which does Session/SessionFactory injection already (it also inject FullTextEntityManager and FullTextSession form Hibernate Search for that matter).
4. Should the jboss-jpa project continue to have its own release cycle or should it live in the AS7 source repo? If anything outside AS7 wants to consume the JPA integration project, then jboss-jpa will need to have its own release cycle. One obvious case is the EJB container, if that continues lives in its own project, jboss-jpa will have to follow suit. I'm not aware of any other projects that desire that.
5. For the JPA EE container integration, should we integrate with a component level invocation context or purely with the containers directly? At this point, I'm assuming direct container integration but we might be able to refactor some of that to be more generic. This will make more sense soon. :) (http://docs.jboss.org/ejb3/docs/reference/build/reference/en/html/entityc...)
6. http://docs.jboss.org/ejb3/docs/reference/build/reference/en/html/entityc... Keep support for jboss.entity.manager.* properties? How about securing entity beans from same doc (4.5)?
7. What about existing code that might attempt casting a javax.persistence.Query to a Hibernate QueryImpl class (described here (http://http://docs.jboss.org/ejb3/docs/reference/build/reference/en/html/....
Illustration of how a stateful session bean (SFSB) named SFSB_XPC1 interacts with a stateless session bean (SLSB) named SLSB_PC2. Note that the extended persistence context (XPC) is injected into SFSB_XPC1 at bean creation time. Also note that the SFSB_XPC1 persistence context is bound to the JTA transaction and will be injected into the SLSB_PC2 by the EJB container as part of each invocation. The XPC1 will retain changes made by each invocation to SLSB_PC2 until the transaction commits.
|| *Action* || *Transaction* || *PersistenceContext
* ||
| SFSB_XPC1 created |
| XPC1 injected into SFSB_XPC1 |
| SFSB_XPC1.updateInventory | T1 started | XPC1 bound to T1 |
| SFSB_XPC1 calls SLSB_PC2 | T1 |
|
| SLSB_PC2.dowork | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity item1 | T1 | item1 is loaded |
| SLSB_PC2 persists new entity order1 | T1 | order1 will be saved at commit time |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 calls SLB_PC2 again | T1 |
|
| SLSB_PC2.morework | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity order1 | T1 | order1 is returned from XPC1 |
| SLSB_PC2 calls order1.increase(4) | T1 | change made in XPC1 held entity |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 returns | T1 commit | XPC1 changes are saved, item1 + order1 remain in XPC1 |
| SFSB_XPC1 removed |
| XPC1 is closed |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 1 month
