[jBPM Development] - test phase
by amine mkacher
amine mkacher [http://community.jboss.org/people/aminou] created the discussion
"test phase"
To view the discussion, visit: http://community.jboss.org/message/570097#570097
--------------------------------------------------------------
during the test phase i had some errors is it dangerous
and how can i correct this error ( is theire a place in wich we can ask question ... ).
can I skip this phase ??
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/570097#570097]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 1 month
- 1
- 0
[JBoss Web Development] - Automatic login after identification
by Philippe Leménager
Philippe Leménager [http://community.jboss.org/people/cinephil] created the discussion
"Automatic login after identification"
To view the discussion, visit: http://community.jboss.org/message/570046#570046
--------------------------------------------------------------
Hello Seamians !
I'm developping my first Seam app.
This app will be open to a restricted list of studients registered in the database of the app.
For the authentication of the users, I use the Authenticator.java automaticaly generated by New Seam Web Project, adapted by myself.
Login page works fine, redirect to the page I want in relation to the type of the user and the link "Logout" appears at the top right of the page, meaning that the app recognize the user connected.
I've added to the Login page a link to an Identification page for the studients never connected to the app. It's inspired from Authnticator.java and works fine, redirect to the good page when the studient is found in the database but there is still "Login" instead of "Logout" at the top-right of the page.
What can I do to log in automaticaly the studient found in the database ?
My adapted Authenticator.java :
@Name("authenticator")
public class Authenticator
{
@Logger private Log log;
@In Identity identity;
@In Credentials credentials;
@In EntityManager entityManager;
private String pageSuivante = "/home.xhtml";
public String getPageSuivante()
{
return this.pageSuivante;
}
public void setPageSuivante(String page)
{
this.pageSuivante = page;
}
public boolean authenticate()
{
try
{
log.info("authenticating {0}", credentials.getUsername());
Query query = entityManager.createQuery(
"FROM ThUtilisateurUti u " +
"WHERE u.utiLogin = :username " +
"AND u.utiMotPasse = :password");
query.setParameter("username", credentials.getUsername());
query.setParameter("password", ThUtilisateurUti.generateMD5(credentials.getPassword()));
ThUtilisateurUti user = (ThUtilisateurUti) query.getSingleResult();
int typeUtilisateur = user.getTeTypeUtilisateurTu().getTuId();
identity.addRole(user.getTeTypeUtilisateurTu().getTuLibelle());
switch (typeUtilisateur)
{
case 1 : // Administrateur
setPageSuivante("/home.xhtml");
return true;
case 2 : // Étudiant
setPageSuivante("/accueilEtudiant.xhtml");
return true;
case 3 : // Gestionnaire
}
setPageSuivante("/login.xhtml");
//return true;
return false;
}
catch (NoResultException ex)
{
//setPageSuivante("/login.xhtml");
return false;
}
}
}
My Identification.java in its actual state :
@Scope(EVENT)
@Name("identification")
public class Identification
{
@Logger private Log log;
@In EntityManager entityManager;
@In StatusMessages statusMessages;
//@In private TePersonnePrs personne;
//@In private ThEtudiantEtu etudiant;
private String nom;
private String prenom;
private Date dateNaissance;
private String pageSuivante = "/home.xhtml";
public String getPageSuivante()
{
return this.pageSuivante;
}
public void setPageSuivante(String page)
{
this.pageSuivante = page;
}
public boolean identifier()
{
try
{
log.info("identification.identifier() "
+ "Tentative d'identification avec les paramètres suivants : "
+ "#{identification.nom}, #{identification.prenom}, #{identification.dateNaissance}");
Query query = entityManager.createQuery(
"from ThEtudiantEtu e " +
"where e.prsNom = :nom " +
"and e.prsPrenom = :prenom " +
"and e.etuDateNaissance = :dateNaissance ");
query.setParameter("nom", this.getNom());
query.setParameter("prenom", this.getPrenom());
query.setParameter("dateNaissance", this.getDateNaissance());
ThEtudiantEtu etudiant = (ThEtudiantEtu) query.getSingleResult();
setPageSuivante("/accueilEtudiant.xhtml");
return true;
}
catch (NoResultException ex)
{
return false;
}
}
// add additional action methods
@Length(max = 30)
public String getNom()
{
return nom;
}
public void setNom(String nom)
{
this.nom = nom;
}
@Length(max = 30)
public void setPrenom(String prenom) {
this.prenom = prenom;
}
public String getPrenom() {
return prenom;
}
public void setDateNaissance(Date dateNaissance) {
this.dateNaissance = dateNaissance;
}
public Date getDateNaissance() {
return dateNaissance;
}
}
I've tried to add role in identity, like in Authenticator.java but it doesn't work.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/570046#570046]
Start a new discussion in JBoss Web Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 1 month
- 1
- 0
[JBoss Web Services Development] - Re: Error while using Wise Soap Client
by Giovanni Marigi
Giovanni Marigi [http://community.jboss.org/people/hifly81] created the discussion
"Re: Error while using Wise Soap Client"
To view the discussion, visit: http://community.jboss.org/message/569946#569946
--------------------------------------------------------------
I was facing the same problem! thanks Ashwin for the solution
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/569946#569946]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 1 month
- 1
- 0
[jBPM Development] - Task Instance Not Ending
by shiva shankar
shiva shankar [http://community.jboss.org/people/shivashankar.p] created the discussion
"Task Instance Not Ending"
To view the discussion, visit: http://community.jboss.org/message/569927#569927
--------------------------------------------------------------
Hi,
I have following process definition.
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="simple">
<start-state name="start">
<transition name="Start" to="Step1"></transition>
</start-state>
<end-state name="end"></end-state>
<task-node name="Step1">
<task name="Step1">
<assignment class="com.sample.SimpleAssignmentHandler"></assignment>
</task>
<transition name="Step2" to="Step2"></transition>
</task-node>
<task-node name="Step2">
<task name="Step2"></task>
<transition name="End" to="end"></transition>
</task-node>
</process-definition>
i had deployed the process definition using below code.
JbpmContext jbpmContext = JbpmConfiguration.getInstance().createJbpmContext();
String businessKey="";
FileInputStream fis=new FileInputStream("D:/java_pro/simple.zip");
ZipInputStream zis=new ZipInputStream(new BufferedInputStream(fis));
ProcessDefinition processDefinition=ProcessDefinition.parseParZipInputStream(zis);
GraphSession gs=jbpmContext.getGraphSession();
gs.deployProcessDefinition(processDefinition);
for(int i=0;i<=5;i++){
ProcessInstance processInstance=jbpmContext.newProcessInstance(processDefinition.getName());
businessKey="KEY15102010"+i;
processInstance.setKey(businessKey);
//processInstance=jbpmContext.getProcessInstance(processInstance.getId());
Token token=processInstance.getRootToken();
Transition transition=(Transition)token.getAvailableTransitions().iterator().next();
token.signal(transition);
//jbpmContext.save(processInstance);
}
jbpmContext.close();
and i have writen the following code to end a process instance
JbpmContext jbpmContext = JbpmConfiguration.getInstance().createJbpmContext();
TaskInstance taskInstance=jbpmContext.getTaskInstance(2900);
ProcessInstance processInstance=taskInstance.getProcessInstance();
taskInstance.start();
Token token=taskInstance.getToken();
Transition transition=(Transition)token.getAvailableTransitions().iterator().next();
token.signal(transition);
taskInstance.end(transition);
jbpmContext.close();
but i am getting the following error if i am trying to execute above program.
22:58:40,656 [main] DEBUG GraphElement : event 'task-start' on 'Task(Step1)' for 'Token(/)'
22:58:41,562 [main] DEBUG GraphElement : event 'before-signal' on 'TaskNode(Step1)' for 'Token(/)'
22:58:41,609 [main] DEBUG GraphElement : event 'node-leave' on 'TaskNode(Step1)' for 'Token(/)'
22:58:41,609 [main] DEBUG GraphElement : event 'transition' on 'Transition(Step2)' for 'Token(/)'
22:58:41,734 [main] DEBUG GraphElement : event 'node-enter' on 'TaskNode(Step2)' for 'Token(/)'
22:58:41,796 [main] WARN StatefulPersistenceContext : Narrowing proxy to class org.jbpm.graph.node.TaskNode - this operation breaks ==
org.jbpm.persistence.JbpmPersistenceException: couldn't assign id to TaskInstance[Step2]
22:58:42,828 [main] WARN JDBCExceptionReporter : SQL Error: 1400, SQLState: 23000
22:58:42,828 [main] ERROR JDBCExceptionReporter : ORA-01400: cannot insert NULL into ("WORKFLOW"."JBPM_TASKINSTANCE"."ID_")
at org.jbpm.persistence.db.DbPersistenceService.assignId(DbPersistenceService.java:333)
at org.jbpm.svc.Services.assignId(Services.java:257)
at org.jbpm.taskmgmt.exe.TaskMgmtInstance.createTaskInstance(TaskMgmtInstance.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
at org.jbpm.taskmgmt.exe.TaskMgmtInstance$$EnhancerByCGLIB$$2c2b22b2.createTaskInstance(<generated>)
at org.jbpm.graph.node.TaskNode.execute(TaskNode.java:168)
at org.jbpm.graph.def.Node.enter(Node.java:319)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$d655f97c.enter(<generated>)
at org.jbpm.graph.def.Transition.take(Transition.java:151)
at org.jbpm.graph.def.Node.leave(Node.java:394)
at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:209)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$109befc6.leave(<generated>)
at org.jbpm.graph.exe.Token.signal(Token.java:195)
at org.jbpm.graph.exe.Token.signal(Token.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$82e4a010.signal(<generated>)
at com.leavemanagement.TestFlow.main(TestFlow.java:28)
Caused by: org.hibernate.exception.ConstraintViolationException: could not insert: [org.jbpm.taskmgmt.exe.TaskInstance]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:40)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2158)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2638)
at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:48)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:298)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:181)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:107)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:187)
at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:535)
at org.hibernate.impl.SessionImpl.save(SessionImpl.java:523)
at org.hibernate.impl.SessionImpl.save(SessionImpl.java:519)
at org.jbpm.persistence.db.DbPersistenceService.assignId(DbPersistenceService.java:330)
... 34 more
Caused by: java.sql.SQLException: ORA-01400: cannot insert NULL into ("WORKFLOW"."JBPM_TASKINSTANCE"."ID_")
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:955)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1169)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3285)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3368)
at org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.executeAndExtract(IdentityGenerator.java:73)
at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:33)
... 50 more
*Note:* i am able to end a task instance if there is only one task node.
Please suggest a solution.thanks.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/569927#569927]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 1 month
- 1
- 0
[JBoss AS7 Development] - JBoss AS7 User Guide
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"JBoss AS7 User Guide"
To view the document, visit: http://community.jboss.org/docs/DOC-16068
--------------------------------------------------------------
This is a brief guide intended to help users who wish to experiment with JBoss AS 7 as it undergoes development. Feedback on its content is most appreciated, either via comments on this page, via forum posts in this "JBoss AS7 Development" section of the wiki, or by posts to the https://lists.jboss.org/mailman/listinfo/jboss-development jboss-develoment mailing list.
AS 7 is currently in "Alpha" status, so users should not expect all (or even most) of the capabilities of more stable AS 5 and 6 releases to be present. Users should also be aware that significant changes may be made from one alpha release to another.
h2. Getting JBoss AS 7
AS 7 is available from the http://www.jboss.org/jbossas/downloads.html jboss.org download page. As in earlier JBoss AS releases, installation consists of unzipping the release distribution.
Users are encouraged to check out the AS 7 source and build it themselves. This is quite quick and painless once git is installed on your system, and getting git set up is also quite easy to do. See the http://community.jboss.org/docs/DOC-15596 Hacking On JBoss AS 7 wiki page for more details on working with the AS 7 source.
h2. Quick Start
Once you have the distribution unzipped, you need to decide whether you want to work in "domain mode" or "standalone mode". See XXX for more on what those choices mean.
If you want to work in domain mode, open terminal and cd into the distribution's bin directory, and run the "domain" launch script:
$ cd bin
$ ./domain.sh
On Windows:
> cd bin
> domain.bat
This will launch a total of 5 processes on your system: three JBoss AS server instances; a Domain Controller process that acts as a central management point for all servers that belong to the same "domain"; and a lightweight ProcessManager process that is responsibility for spawning the other 4 processes and monitoring their lifecycle.
If you want to work in standalone mode, open terminal and cd into the distribution's bin directory, and run the "standalone" launch script:
$ cd bin
$ ./standalone.sh
On Windows:
> cd bin
> standalone.bat
This will launch a single process on your system, a standalone JBoss AS server instance.
If you have the AS 7 source checked out, there are a number of demos that can be run from the source checkout's demos module. See below for details.
h2. Domain Mode vs. Standalone Mode
One of the primary new features of AS 7 is the ability to manage multiple AS instances from a single control point. A collection of such servers are referred to as members of a "domain", with a single Domain Controller process acting as the management control point. Domains can span multiple physical (or virtual) machines, with all AS instances on a given host under the control of a Server Manager process. The Server Managers interact with the Domain Controller to control the lifecycle of the AS instances running on that host and to assist the Domain Controller in managing them.
When you launch JBoss AS in "domain mode" (via the domain.sh or domain.bat launch scripts) your intent is to launch a DomainController, a Server Manager and usually at least one AS instance.
For more on running servers in domain mode, a roughly 20 minute video is available online (divided in two pieces):
http://www.youtube.com/watch?v=phV3QiKQf2E http://www.youtube.com/watch?v=phV3QiKQf2E
http://www.youtube.com/watch?v=gCeQ2KIO0qc http://www.youtube.com/watch?v=gCeQ2KIO0qc
For many use cases, the centralized managment capability available via domain mode is not necessary. For these use cases, the AS can also be run in "standalone mode". In standalone mode each AS instance is an independent process, much like an AS 3, 4, 5, or 6 instance is. Standalone instances can be launched via the standalone.sh or standalone.bat launch scripts.
If more than one standalone instance is launched and multi-server management is desired, it is the user's responsibility to coordinate management across the servers.
The current AS 7 alpha release does not support HA functionality. However, it's important to understand that once HA functionality is added, it will be orthogonal to "domain mode" vs. "standalone mode". That is, a group of servers running in standalone mode will be able to be configured to form an HA cluster. The domain and standalone modes determine how the servers are managed, not what capabilities they provide.
A given server instance cannot be switched between domain mode and standalone mode; i.e. you cannot launch domain.sh, stop the processes, and then launch standalone.sh and expect any relationship between what was running. The configurations are separate. We may in future releases include some tooling to ease the task of translating a given server configuration from domain mode to standalone mode.
h2. Contents of the AS 7 Distribution
The AS 7 distribution includes the following directories:
*bin* -- location of the launch scripts
*docs* -- license files, documentation, schemas, examples, etc. The amount of content in this directory will increase as development continues.
*modules* -- AS 7 is based on a modular classloading architecture. The various modules used in the server are stored here. Generally speaking, this is not an area that would be modified by end users.
*domain* -- only relevant when domain mode is used. Configuration files, deployment content, and writeable areas used by the domain mode processes that run off of this installation. See below for further details.
*standalone* -- only relevant when standalone mode is used. Configuration files, deployment content, and writeable areas used by the single standalone server that runs off this installation. See below for further details.
h3. Contents of the "domain" Directory
Only relevant when domain mode is used.
*configuration* -- configuration files for the domain and for the Server Manager and any servers running off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*content* -- an internal working area for the Server Manager that controls this installation. This is where it internally stores deployment content. This directory is not meant to be manipulated by end users.
*log* -- location where the Process Manager and Server Manager write their log files.
*servers* -- writeable area used by each AS instance. Each AS instance will have its own subdirectory, created when the server is first started. In each server's subdirectory there will be the following subdirectories:
data -- information written by the server that needs to survive a restart of the server
log -- the server's log files
tmp -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide.
h3. Contents of the "standalone" Directory
Only relevant when standalone mode is used.
*configuration* -- configuration files for the standalone server that runs off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*data* -- information written by the server that needs to survive a restart of the server
*deployments* -- an area where end user deployment content can be placed if automatic detection and deployment of that content into the server's runtime is desired. The server's management API exposes other means for installing deployment content, and use of that API in preference to the deployments directory is preferred. We realize however, that at this early stage in AS 7's development the tooling around the deployment API is in its infancy, so many users will utilizes the deployments directory to deploy content. Note that "domain mode" does not support deploying content based on scanning a filesystem.
*log* -- the server's log files
*tmp* -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide.
h2. "Domain Mode" Configuration Files
Located in the *domain/configuration* directory.
*domain.xml* -- primary configuration file for the domain. Among other things, includes the configuration of the various "profiles" that AS instances can be configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. and embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Includes the definition of groups of sockets that those subsystems may open. And includes definition of "server groups", to which a profile, a group of socket definitions and zero or more deployments are mapped. Each individual server will be mapped (in host.xml, see below) to a server group; the configuration of that server group largely defines the configuration of the individual server.
A domain.xml file must be located in the domain/configuration directory of an installation that's meant to run the Domain Controller. It does not need to be present in installations that are not meant to run a Domain Controller; i.e. those whose Server Manager is configured to contact a remote Domain Controller. The presence of a domain.xml file on such a server does no harm; it will be ignored.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <host> element, to learn more about configuration of an AS Server Manager.
*host.xml* -- configuration file for the Server Manager that runs off of this particular installation. Each installation must have a host.xml file. Contains configuration information that is specific to the particular installation. Primarily:
* the listing of the names of the actual AS server instances that are meant to run off of this installation, along with the server group they belong to.
* configuration of how the Server Manager is to contact the Domain Controller to register itself and access the domain configuration. This may either be configuration of how to find and contact a remote Domain Controller, or a configuration telling the Server Manager to itself act as the Domain Controller.
* configuration of items that are specific to the local physical installation. For example, named interface definitions declared in domain.xml can be mapped to an actual machine-specific IP address in host.xml. Abstract path names in domain.xml can be mapped to actual filesystem paths in host.xml.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <server> element, to learn more about configuration of a standalone AS instance.
*logging.properties* -- Contains the logging configuration for the Server Manager and Process Manager that run off of this installation. Also defines the initial bootstrap logging configuration for each individual AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the domain.xml file once the server boot has reached the point where that configuration is available.
h2. "Standalone Mode" Configuration Files
Located in the *standalone/configuration* directory.
*standalone.xml* -- primary configuration file for the AS instance. Among other things, includes the configuration of the "profile" that the AS instance is configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. and embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Also includes the definition of the sockets that those subsystems may open.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <server> element, to learn more about configuration of a standalone AS instance.
*logging.properties* -- Contains the initial bootstrap logging configuration for the AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the standalone.xml file once the server boot has reached the point where that configuration is available.
h2.
Available Subsystems
AS 7 is under active development. Not all capabilities present in more mature releases of the AS 5 and 6 series are available in AS 7 yet. Following is a brief listing of the subsystems available in the various AS 7 releases. Items listed below may not be entirely feature complete.
h4. 7.0.0.Alpha1
* logging -- configuration of logging appenders, categories, etc
* threads -- thread pool management
* sockets -- socket binding management
* naming -- local JNDI. Note that direct remote access to JNDI is not supported in Alpha1 (see the client.jms demo for an example of a clever hack to get remote access to JNDI via an MBeanServerConnection)
* transactions -- JTA
* jmx -- MBeanServer with remote access capability
* web -- basic servlet and JSP support
* messaging -- HornetQ server
* JMS -- JMS queues, topics and connection factories
* JCA connectors
* Datasources
* JCA resource adapter deployments
* osgi -- OSGI bundle deployment
* remoting -- JBoss Remoting 3 connectors
* managed beans -- EE 6 managed bean deployments
* SAR deployments -- both legacy mbean deployments and those based on the JDK 6 ServiceLoader concept. Note that not all legacy sar capabilities are supported
h2. Demos in the Source Checkout
The source checkout includes a "demos" module that includes a number of demos that can be run from maven. Building the module will output a usage note that explains how to run the demos:
usage:
[echo] To run an example:
[echo] 1) In a separate console window,start either a standalone JBoss AS instance or a JBoss AS domain
[echo] 2) Run mvn package -Dexample=<example.name> where "exammple.name is the name of the example
[echo]
[echo] Valid example names to run against a standalone JBoss AS instance are
[echo] sar - deploys mbeans packaged in a sar
[echo] managedbean - deploys a managed bean
[echo] serviceloader - deploys a serviceloader style service
[echo] messaging - deploys HornetQ native sender and receiver
[echo] jms - deploys HornetQ JMS sender and receiver
[echo] jms.client - Uses HornetQ JMS API from the client
[echo] rar - deploys a resource adapter
[echo] ds - deploys a test bean for data sources
[echo] war - deploys a simple servlet and connects to it
[echo] client.messaging - creates a HornetQ core queue using the management API
[echo] client.jms - creates a JMS queue using the management API
[echo] web.connector - creates and removes a jboss web connector
[echo]
[echo] Valid example names to run against a JBoss AS domain are
[echo] domain.configs - reads the domain config and any available server manager configs
[echo] domain.ds - deploys deploys a test bean for data sources
[echo] domain.messaging - deploys HornetQ native sender and receiver
[echo] domain.rar - deploys deploys a resource adapter
[echo] domain.servers - shows domain, server manager and server configs, starts/stops servers
The primary point of the demos is to look at the source code and see how they use the AS's management API to deploy content and/or alter the configuration of the running server(s). To see how an example works, look at the relevant demos/src/main/java/org/jboss/as/demos/<example.name>/runner.ExampleRunner.java file.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16068]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 1 month
- 1
- 0
[JBoss AS7 Development] - JBoss AS7 User Guide
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"JBoss AS7 User Guide"
To view the document, visit: http://community.jboss.org/docs/DOC-16068
--------------------------------------------------------------
This is a brief guide intended to help users who wish to experiment with JBoss AS 7 as it undergoes development. Feedback on its content is most appreciated, either via comments on this page, via forum posts in this "JBoss AS7 Development" section of the wiki, or by posts to the https://lists.jboss.org/mailman/listinfo/jboss-development jboss-develoment mailing list.
AS 7 is currently in "Alpha" status, so users should not expect all (or even most) of the capabilities of more stable AS 5 and 6 releases to be present. Users should also be aware that significant changes may be made from one alpha release to another.
h2. Getting JBoss AS 7
AS 7 is available from the http://www.jboss.org/jbossas/downloads.html jboss.org download page. As in earlier JBoss AS releases, installation consists of unzipping the release distribution.
Users are encouraged to check out the AS 7 source and build it themselves. This is quite quick and painless once git is installed on your system, and getting git set up is also quite easy to do. See the http://community.jboss.org/docs/DOC-15596 Hacking On JBoss AS 7 wiki page for more details on working with the AS 7 source.
h2. Quick Start
Once you have the distribution unzipped, you need to decide whether you want to work in "domain mode" or "standalone mode". See XXX for more on what those choices mean.
If you want to work in domain mode, open terminal and cd into the distribution's bin directory, and run the "domain" launch script:
$ cd bin
$ ./domain.sh
On Windows:
> cd bin
> domain.bat
This will launch a total of 5 processes on your system: three JBoss AS server instances; a Domain Controller process that acts as a central management point for all servers that belong to the same "domain"; and a lightweight ProcessManager process that is responsibility for spawning the other 4 processes and monitoring their lifecycle.
If you want to work in standalone mode, open terminal and cd into the distribution's bin directory, and run the "standalone" launch script:
$ cd bin
$ ./standalone.sh
On Windows:
> cd bin
> standalone.bat
This will launch a single process on your system, a standalone JBoss AS server instance.
If you have the AS 7 source checked out, there are a number of demos that can be run from the source checkout's demos module. See below for details.
h2. Domain Mode vs. Standalone Mode
One of the primary new features of AS 7 is the ability to manage multiple AS instances from a single control point. A collection of such servers are referred to as members of a "domain", with a single Domain Controller process acting as the management control point. Domains can span multiple physical (or virtual) machines, with all AS instances on a given host under the control of a Server Manager process. The Server Managers interact with the Domain Controller to control the lifecycle of the AS instances running on that host and to assist the Domain Controller in managing them.
When you launch JBoss AS in "domain mode" (via the domain.sh or domain.bat launch scripts) your intent is to launch a DomainController, a Server Manager and usually at least one AS instance.
For more on running servers in domain mode, a roughly 20 minute video is available online (divided in two pieces):
http://www.youtube.com/watch?v=phV3QiKQf2E http://www.youtube.com/watch?v=phV3QiKQf2E
http://www.youtube.com/watch?v=gCeQ2KIO0qc http://www.youtube.com/watch?v=gCeQ2KIO0qc
For many use cases, the centralized managment capability available via domain mode is not necessary. For these use cases, the AS can also be run in "standalone mode". In standalone mode each AS instance is an independent process, much like an AS 3, 4, 5, or 6 instance is. Standalone instances can be launched via the standalone.sh or standalone.bat launch scripts.
If more than one standalone instance is launched and multi-server management is desired, it is the user's responsibility to coordinate management across the servers.
The current AS 7 alpha release does not support HA functionality. However, it's important to understand that once HA functionality is added, it will be orthogonal to "domain mode" vs. "standalone mode". That is, a group of servers running in standalone mode will be able to be configured to form an HA cluster. The domain and standalone modes determine how the servers are managed, not what capabilities they provide.
A given server instance cannot be switched between domain mode and standalone mode; i.e. you cannot launch domain.sh, stop the processes, and then launch standalone.sh and expect any relationship between what was running. The configurations are separate. We may in future releases include some tooling to ease the task of translating a given server configuration from domain mode to standalone mode.
h2. Contents of the AS 7 Distribution
The AS 7 distribution includes the following directories:
*bin* -- location of the launch scripts
*docs* -- license files, documentation, schemas, examples, etc. The amount of content in this directory will increase as development continues.
*modules* -- AS 7 is based on a modular classloading architecture. The various modules used in the server are stored here. Generally speaking, this is not an area that would be modified by end users.
*domain* -- only relevant when domain mode is used. Configuration files, deployment content, and writeable areas used by the domain mode processes that run off of this installation. See below for further details.
*standalone* -- only relevant when standalone mode is used. Configuration files, deployment content, and writeable areas used by the single standalone server that runs off this installation. See below for further details.
h3. Contents of the "domain" Directory
Only relevant when domain mode is used.
*configuration* -- configuration files for the domain and for the Server Manager and any servers running off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*content* -- an internal working area for the Server Manager that controls this installation. This is where it internally stores deployment content. This directory is not meant to be manipulated by end users.
*log* -- location where the Process Manager and Server Manager write their log files.
*servers* -- writeable area used by each AS instance. Each AS instance will have its own subdirectory, created when the server is first started. In each server's subdirectory there will be the following subdirectories:
data -- information written by the server that needs to survive a restart of the server
log -- the server's log files
tmp -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide.
h3. Contents of the "standalone" Directory
Only relevant when standalone mode is used.
*configuration* -- configuration files for the standalone server that runs off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*data* -- information written by the server that needs to survive a restart of the server
*deployments* -- an area where end user deployment content can be placed if automatic detection and deployment of that content into the server's runtime is desired. The server's management API exposes other means for installing deployment content, and use of that API in preference to the deployments directory is preferred. We realize however, that at this early stage in AS 7's development the tooling around the deployment API is in its infancy, so many users will utilizes the deployments directory to deploy content. Note that "domain mode" does not support deploying content based on scanning a filesystem.
*log* -- the server's log files
*tmp* -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide.
h2. "Domain Mode" Configuration Files
Located in the *domain/configuration* directory.
*domain.xml* -- primary configuration file for the domain. Among other things, includes the configuration of the various "profiles" that AS instances can be configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. and embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Includes the definition of groups of sockets that those subsystems may open. And includes definition of "server groups", to which a profile, a group of socket definitions and zero or more deployments are mapped. Each individual server will be mapped (in host.xml, see below) to a server group; the configuration of that server group largely defines the configuration of the individual server.
A domain.xml file must be located in the domain/configuration directory of an installation that's meant to run the Domain Controller. It does not need to be present in installations that are not meant to run a Domain Controller; i.e. those whose Server Manager is configured to contact a remote Domain Controller. The presence of a domain.xml file on such a server does no harm; it will be ignored.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <host> element, to learn more about configuration of an AS Server Manager.
*host.xml* -- configuration file for the Server Manager that runs off of this particular installation. Each installation must have a host.xml file. Contains configuration information that is specific to the particular installation. Primarily:
* the listing of the names of the actual AS server instances that are meant to run off of this installation, along with the server group they belong to.
* configuration of how the Server Manager is to contact the Domain Controller to register itself and access the domain configuration. This may either be configuration of how to find and contact a remote Domain Controller, or a configuration telling the Server Manager to itself act as the Domain Controller.
* configuration of items that are specific to the local physical installation. For example, named interface definitions declared in domain.xml can be mapped to an actual machine-specific IP address in host.xml. Abstract path names in domain.xml can be mapped to actual filesystem paths in host.xml.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <server> element, to learn more about configuration of a standalone AS instance.
*logging.properties* -- Contains the logging configuration for the Server Manager and Process Manager that run off of this installation. Also defines the initial bootstrap logging configuration for each individual AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the domain.xml file once the server boot has reached the point where that configuration is available.
h2. "Standalone Mode" Configuration Files
Located in the *standalone/configuration* directory.
*standalone.xml* -- primary configuration file for the AS instance. Among other things, includes the configuration of the "profile" that the AS instance is configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. and embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Also includes the definition of the sockets that those subsystems may open.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <server> element, to learn more about configuration of a standalone AS instance.
*logging.properties* -- Contains the initial bootstrap logging configuration for the AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the standalone.xml file once the server boot has reached the point where that configuration is available.
h2. Demos in the Source Checkout
The source checkout includes a "demos" module that includes a number of demos that can be run from maven. Building the module will output a usage note that explains how to run the demos:
usage:
[echo] To run an example:
[echo] 1) In a separate console window,start either a standalone JBoss AS instance or a JBoss AS domain
[echo] 2) Run mvn package -Dexample=<example.name> where "exammple.name is the name of the example
[echo]
[echo] Valid example names to run against a standalone JBoss AS instance are
[echo] sar - deploys mbeans packaged in a sar
[echo] managedbean - deploys a managed bean
[echo] serviceloader - deploys a serviceloader style service
[echo] messaging - deploys HornetQ native sender and receiver
[echo] jms - deploys HornetQ JMS sender and receiver
[echo] jms.client - Uses HornetQ JMS API from the client
[echo] rar - deploys a resource adapter
[echo] ds - deploys a test bean for data sources
[echo] war - deploys a simple servlet and connects to it
[echo] client.messaging - creates a HornetQ core queue using the management API
[echo] client.jms - creates a JMS queue using the management API
[echo] web.connector - creates and removes a jboss web connector
[echo]
[echo] Valid example names to run against a JBoss AS domain are
[echo] domain.configs - reads the domain config and any available server manager configs
[echo] domain.ds - deploys deploys a test bean for data sources
[echo] domain.messaging - deploys HornetQ native sender and receiver
[echo] domain.rar - deploys deploys a resource adapter
[echo] domain.servers - shows domain, server manager and server configs, starts/stops servers
The primary point of the demos is to look at the source code and see how they use the AS's management API to deploy content and/or alter the configuration of the running server(s). To see how an example works, look at the relevant demos/src/main/java/org/jboss/as/demos/<example.name>/runner.ExampleRunner.java file.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16068]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 1 month
- 1
- 0
[JBoss AS7 Development] - Hacking on AS7
by Alessio Soldano
Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] modified the document:
"Hacking on AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-15596
--------------------------------------------------------------
h4. 1. Create a github account
http://github.com http://github.com
h4. 2. Fork jboss-as into your account
http://github.com/jbossas/jboss-as http://github.com/jbossas/jboss-as
h4. 3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/jboss-as.git
Initialized empty Git repository in /devel/jboss-as/.git/
remote: Counting objects: 2444, done.
remote: Compressing objects: 100% (705/705), done.
remote: Total 2444 (delta 938), reused 2444 (delta 938)
Receiving objects: 100% (2444/2444), 1.71 MiB | 205 KiB/s, done.
Resolving deltas: 100% (938/938), done.
$ cd jboss-as
h4. 4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/jbossas/jboss-as.git
h4. 5. Use maven (via build.sh) (make sure you use maven 3)
$ ./build.sh install
.....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: BOM ..................... SUCCESS [1.834s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [0.022s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [3.051s]
[INFO] JBoss Application Server: Server Manager .......... SUCCESS [0.204s]
[INFO] JBoss Application Server: Server .................. SUCCESS [0.283s]
[INFO] JBoss Application Server: Domain Controller ....... SUCCESS [0.084s]
[INFO] JBoss Application Server: Process Manager ......... SUCCESS [0.314s]
[INFO] JBoss Application Server: Remoting ................ SUCCESS [0.390s]
[INFO] JBoss Application Server: Build ................... SUCCESS [5.696s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
h4. 6. Pulling later updates from upstream
$ git pull --rebase upstream master
>From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
*(--rebase will automatically move your local commits, if you have any, on top of the latest branch you pull from, you can leave it off if you do not). Please note that --rebase is very important if you do have commits. What happens is that when git pull can't fast forward, it does a merge commit, and a merge commit puts the sucked in changes ON TOP of yours whereas a rebase puts them BELOW yours. In other words a merge commit makes the history a graph, and we prefer a cleaner, easier to follow linear history (hence the rebasing). Further once you do a merge commit it will be difficult to rebase the history before that commit (say you want to combine two commits to one later) as described in point 12.*
*One way to not forget --rebase the rebase option is you may want to create an alias*
$ git config --global alias.up "pull --rebase"
*and then just use the new alias instead of pull*
$ git up upstream master
*One last option, which some prefer, is to avoid using pull altogether, and just use fetch + rebase (this is of course more typing)*
*7. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)*
$ git push
Counting objects: 192, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (100/100), 10.67 KiB, done.
Total 100 (delta 47), reused 100 (delta 47)
To git@github.com:[your user]/jboss-as.git
3382570..1fa25df master -> master
*You might need to say -f to force the changes. Read the note on 12 though before you do it.*
h4. 8. Discuss your planned changes (if you want feedback)
* On the forums - http://community.jboss.org/en/jbossas/dev/jboss_as7_development http://community.jboss.org/en/jbossas/dev/jboss_as7_development
* On IRC - irc://irc.freenode.org/jboss-as7 or https://webchat.freenode.net/?channels=jboss-as7 (http://webchat.freenode.net/?channels=jboss-as7)
h4. 9. Make sure there is a JIRA somewhere for the enhancement/fix
http://jira.jboss.org http://jira.jboss.org
h4. 10. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
h6. Note: See tips section for how to use a nice git prompt for tracking what branch you are in!
h6. 11. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'JBAS-XXXX Frunubucate the Fromungulator'
git commit -m 'JBAS-YYYY Tripple Performance of Fromungulation'
git push my_cool_feature
+Note that git push references the branch you are pushing and defaults to master, *not your working branch*.+
h4. 12. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream
git rebase -i upstream/master
# if you have conflicts fix them and rerun rebase
# The -f, forces the push, alters history, see note below
git push -f my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that this alters history, which while great for making a clean patch, is unfriendly to anyone who has forked your branch. Therefore you want to make sure that you either work in a branch that you don't share, or if you do share it, tell them you are about to revise the branch history (and thus, they will then need to rebase on top of your branch once you push it out).
h4. 13. Get your changes merged into upstream
1. Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 12.
2. Email a pull request to mailto:jbossas-pull-requests@lists.jboss.org jbossas-pull-requests(a)lists.jboss.org (if I haven't subscribed the list, do it https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests here) with a link to your repo, a description of the changes, and who reviewed (if any)
3. After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
4. Don't forget to switch back to master and pull the updates1. git checkout master
git pull upstream master
h4. Appendix A. Adding a new external dependency
1. Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of *provided* scope).
2. Add your dependency to any AS modules that require it, but only with group/artifact.
3. Edit build/pom.xml and add your dependency with only group/artifact.
4. Create a directory in build/src/modules corresponding to the *module's* name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
5. Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
6. Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the *module* name. The group/artifact listed in the nested maven-resource element(s) refer to the *Maven* group/artifact name.
7. *Important:* Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix B. Adding a new AS submodule
1. Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
2. Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do *not* include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
3. Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
4. Add the new submodule to the modules section element of the top-level pom.xml
5. Add your submodule dependency to any AS modules that require it, but only with group/artifact.
6. Edit build/pom.xml and add the new submodule with only group/artifact.
7. Create a directory in build/src/modules corresponding to the submodule, with a version of "main", like this: "build/src/main/resources/modules/org/jboss/as/new-subsystem/main".
8. Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
9. Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix C. Profiling with JProfiler
Performance tuning is an important part of AS7 development. In order to use JProfiler on a standalone AS 7 instance, first you need to add the following to your standalone.conf file:
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=com.jprofiler -agentlib:jprofilerti -Xbootclasspath/a:/path/to/jprofiler/bin/agent.jar"
The "jboss.modules.system.pkgs" property tells JBoss Modules to allow the "com.profiler" classes to be found from any class loader, which is essential to allow the JProfiler agent to run.
It's easiest to then just set up your JProfiler session as "Remote", and start the server and the profiler in any order. That's it!
h4. Tips & Tricks!
h4. Creating a Git status prompt in your terminal
This makes it easy to not forget what branch you are working in and quickly tell if you have changes. The following will adjust the PS1 on unix (or cygwin on Windows). Note that it assumes a compiled version of git, which is also the case for the OSX packages. If you are using the bundled rpm version, change the completion path to "/etc/bash_completion.d/git"
GIT_COMPLETION_PATH="/usr/local/git/contrib/completion/git-completion.bash"
if [ -f "$GIT_COMPLETION_PATH" ]; then
GIT_PS1_SHOWDIRTYSTATE=true
. "$GIT_COMPLETION_PATH"
ADD_PS1='$(__git_ps1)'
fi
if [[ ${EUID} == 0 ]] ; then
PS1="\[\033[01;31m\]\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
else
PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
fi
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15596]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 1 month
- 1
- 0
[JBoss AS7 Development] - JBoss AS7 User Guide
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"JBoss AS7 User Guide"
To view the document, visit: http://community.jboss.org/docs/DOC-16068
--------------------------------------------------------------
This is a brief guide intended to help users who wish to experiment with JBoss AS 7 as it undergoes development. Feedback on its content is most appreciated, either via comments on this page, via forum posts in this "JBoss AS7 Development" section of the wiki, or by posts to the https://lists.jboss.org/mailman/listinfo/jboss-development jboss-develoment mailing list.
AS 7 is currently in "Alpha" status, so users should not expect all (or even most) of the capabilities of more stable AS 5 and 6 releases to be present. Users should also be aware that significant changes may be made from one alpha release to another.
h2. Getting JBoss AS 7
AS 7 is available from the http://www.jboss.org/jbossas/downloads.html jboss.org download page. As in earlier JBoss AS releases, installation consists of unzipping the release distribution.
Users are encouraged to check out the AS 7 source and build it themselves. This is quite quick and painless once git is installed on your system, and getting git set up is also quite easy to do. See the http://community.jboss.org/docs/DOC-15596 Hacking On JBoss AS 7 wiki page for more details on working with the AS 7 source.
h2. Quick Start
Once you have the distribution unzipped, you need to decide whether you want to work in "domain mode" or "standalone mode". See XXX for more on what those choices mean.
If you want to work in domain mode, open terminal and cd into the distribution's bin directory, and run the "domain" launch script:
$ cd bin
$ ./domain.sh
On Windows:
> cd bin
> domain.bat
This will launch a total of 5 processes on your system: three JBoss AS server instances; a Domain Controller process that acts as a central management point for all servers that belong to the same "domain"; and a lightweight ProcessManager process that is responsibility for spawning the other 4 processes and monitoring their lifecycle.
If you want to work in standalone mode, open terminal and cd into the distribution's bin directory, and run the "standalone" launch script:
$ cd bin
$ ./standalone.sh
On Windows:
> cd bin
> standalone.bat
This will launch a single process on your system, a standalone JBoss AS server instance.
If you have the AS 7 source checked out, there are a number of demos that can be run from the source checkout's demos module. See below for details.
h2. Domain Mode vs. Standalone Mode
One of the primary new features of AS 7 is the ability to manage multiple AS instances from a single control point. A collection of such servers are referred to as members of a "domain", with a single Domain Controller process acting as the management control point. Domains can span multiple physical (or virtual) machines, with all AS instances on a given host under the control of a Server Manager process. The Server Managers interact with the Domain Controller to control the lifecycle of the AS instances running on that host and to assist the Domain Controller in managing them.
When you launch JBoss AS in "domain mode" (via the domain.sh or domain.bat launch scripts) your intent is to launch a DomainController, a Server Manager and usually at least one AS instance.
For more on running servers in domain mode, a roughly 20 minute video is available online (divided in two pieces):
http://www.youtube.com/watch?v=phV3QiKQf2E http://www.youtube.com/watch?v=phV3QiKQf2E
http://www.youtube.com/watch?v=gCeQ2KIO0qc http://www.youtube.com/watch?v=gCeQ2KIO0qc
For many use cases, the centralized managment capability available via domain mode is not necessary. For these use cases, the AS can also be run in "standalone mode". In standalone mode each AS instance is an independent process, much like an AS 3, 4, 5, or 6 instance is. Standalone instances can be launched via the standalone.sh or standalone.bat launch scripts.
If more than one standalone instance is launched and multi-server management is desired, it is the user's responsibility to coordinate management across the servers.
The current AS 7 alpha release does not support HA functionality. However, it's important to understand that once HA functionality is added, it will be orthogonal to "domain mode" vs. "standalone mode". That is, a group of servers running in standalone mode will be able to be configured to form an HA cluster. The domain and standalone modes determine how the servers are managed, not what capabilities they provide.
A given server instance cannot be switched between domain mode and standalone mode; i.e. you can launch domain.sh, stop the processes, and then launch standalone.sh and expect any relationship between what was running. The configurations are separate. We may in future releases include some tooling to ease the task of translating a given server configuration from domain mode to standalone mode.
h2. Contents of the AS 7 Distribution
The AS 7 distribution includes the following directories:
*bin* -- location of the launch scripts
*docs* -- license files, documentation, schemas, examples, etc. The amount of content in this directory will increase as development continues.
*modules* -- AS 7 is based on a modular classloading architecture. The various modules used in the server are stored here. Generally speaking, this is not an area that would be modified by end users.
*domain* -- only relevant when domain mode is used. Configuration files, deployment content, and writeable areas used by the domain mode processes that run off of this installation. See below for further details.
*standalone* -- only relevant when standalone mode is used. Configuration files, deployment content, and writeable areas used by the single standalone server that runs off this installation. See below for further details.
h3. Contents of the "domain" Directory
Only relevant when domain mode is used.
*configuration* -- configuration files for the domain and for the Server Manager and any servers running off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*content* -- an internal working area for the Server Manager that controls this installation. This is where it internally stores deployment content. This directory is not meant to be manipulated by end users.
*log* -- location where the Process Manager and Server Manager write their log files.
*servers* -- writeable area used by each AS instance. Each AS instance will have its own subdirectory, created when the server is first started. In each server's subdirectory there will be the following subdirectories:
data -- information written by the server that needs to survive a restart of the server
log -- the server's log files
tmp -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide.
h3. Contents of the "standalone" Directory
Only relevant when standalone mode is used.
*configuration* -- configuration files for the standalone server that runs off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*data* -- information written by the server that needs to survive a restart of the server
*deployments* -- an area where end user deployment content can be placed if automatic detection and deployment of that content into the server's runtime is desired. The server's management API exposes other means for installing deployment content, and use of that API in preference to the deployments directory is preferred. We realize however, that at this early stage in AS 7's development the tooling around the deployment API is in its infancy, so many users will utilizes the deployments directory to deploy content. Note that "domain mode" does not support deploying content based on scanning a filesystem.
*log* -- the server's log files
*tmp* -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide.
h2. "Domain Mode" Configuration Files
Located in the *domain/configuration* directory.
*domain.xml* -- primary configuration file for the domain. Among other things, includes the configuration of the various "profiles" that AS instances can be configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. and embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Includes the definition of groups of sockets that those subsystems may open. And includes definition of "server groups", to which a profile, a group of socket definitions and zero or more deployments are mapped. Each individual server will be mapped (in host.xml, see below) to a server group; the configuration of that server group largely defines the configuration of the individual server.
A domain.xml file must be located in the domain/configuration directory of an installation that's meant to run the Domain Controller. It does not need to be present in installations that are not meant to run a Domain Controller; i.e. those whose Server Manager is configured to contact a remote Domain Controller. The presence of a domain.xml file on such a server does no harm; it will be ignored.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <host> element, to learn more about configuration of an AS Server Manager.
*host.xml* -- configuration file for the Server Manager that runs off of this particular installation. Each installation must have a host.xml file. Contains configuration information that is specific to the particular installation. Primarily:
* the listing of the names of the actual AS server instances that are meant to run off of this installation, along with the server group they belong to.
* configuration of how the Server Manager is to contact the Domain Controller to register itself and access the domain configuration. This may either be configuration of how to find and contact a remote Domain Controller, or a configuration telling the Server Manager to itself act as the Domain Controller.
* configuration of items that are specific to the local physical installation. For example, named interface definitions declared in domain.xml can be mapped to an actual machine-specific IP address in host.xml. Abstract path names in domain.xml can be mapped to actual filesystem paths in host.xml.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <server> element, to learn more about configuration of a standalone AS instance.
*logging.properties* -- Contains the logging configuration for the Server Manager and Process Manager that run off of this installation. Also defines the initial bootstrap logging configuration for each individual AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the domain.xml file once the server boot has reached the point where that configuration is available.
h2. "Standalone Mode" Configuration Files
Located in the *standalone/configuration* directory.
*standalone.xml* -- primary configuration file for the AS instance. Among other things, includes the configuration of the "profile" that the AS instance is configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. and embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Also includes the definition of the sockets that those subsystems may open.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <server> element, to learn more about configuration of a standalone AS instance.
*logging.properties* -- Contains the initial bootstrap logging configuration for the AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the standalone.xml file once the server boot has reached the point where that configuration is available.
h2. Demos in the Source Checkout
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16068]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 1 month
- 1
- 0
[JBoss AS7 Development] - Hacking on AS7
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] modified the document:
"Hacking on AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-15596
--------------------------------------------------------------
h4. 1. Create a github account
http://github.com http://github.com
h4. 2. Fork jboss-as into your account
http://github.com/jbossas/jboss-as http://github.com/jbossas/jboss-as
h4. 3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/jboss-as.git
Initialized empty Git repository in /devel/jboss-as/.git/
remote: Counting objects: 2444, done.
remote: Compressing objects: 100% (705/705), done.
remote: Total 2444 (delta 938), reused 2444 (delta 938)
Receiving objects: 100% (2444/2444), 1.71 MiB | 205 KiB/s, done.
Resolving deltas: 100% (938/938), done.
$ cd jboss-as
h4. 4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/jbossas/jboss-as.git
h4. 5. Use maven (via build.sh) (make sure you use maven 3)
$ ./build.sh install
.....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: BOM ..................... SUCCESS [1.834s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [0.022s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [3.051s]
[INFO] JBoss Application Server: Server Manager .......... SUCCESS [0.204s]
[INFO] JBoss Application Server: Server .................. SUCCESS [0.283s]
[INFO] JBoss Application Server: Domain Controller ....... SUCCESS [0.084s]
[INFO] JBoss Application Server: Process Manager ......... SUCCESS [0.314s]
[INFO] JBoss Application Server: Remoting ................ SUCCESS [0.390s]
[INFO] JBoss Application Server: Build ................... SUCCESS [5.696s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
h4. 6. Pulling later updates from upstream
$ git pull --rebase upstream master
>From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
*(--rebase will automatically move your local commits, if you have any, on top of the latest branch you pull from, you can leave it off if you do not). Please note that --rebase is very important if you do have commits. What happens is that when git pull can't fast forward, it does a merge commit, and a merge commit puts the sucked in changes ON TOP of yours whereas a rebase puts them BELOW yours. In other words a merge commit makes the history a graph, and we prefer a cleaner, easier to follow linear history (hence the rebasing). Further once you do a merge commit it will be difficult to rebase the history before that commit (say you want to combine two commits to one later) as described in point 12.*
*One way to not forget --rebase the rebase option is you may want to create an alias*
$ git config --global alias.up "pull --rebase"
*and then just use the new alias instead of pull*
$ git up upstream master
*One last option, which some prefer, is to avoid using pull altogether, and just use fetch + rebase (this is of course more typing)*
*7. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)*
$ git push
Counting objects: 192, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (100/100), 10.67 KiB, done.
Total 100 (delta 47), reused 100 (delta 47)
To git@github.com:[your user]/jboss-as.git
3382570..1fa25df master -> master
*You might need to say -f to force the changes. Read the note on 12 though before you do it.*
h4. 8. Discuss your planned changes (if you want feedback)
* On the forums - http://community.jboss.org/en/jbossas/dev/jboss_as7_development http://community.jboss.org/en/jbossas/dev/jboss_as7_development
* On IRC - irc://irc.freenode.org/jboss-as7 or https://webchat.freenode.net/?channels=jboss-as7 (http://webchat.freenode.net/?channels=jboss-as7)
h4. 9. Make sure there is a JIRA somewhere for the enhancement/fix
http://jira.jboss.org http://jira.jboss.org
h4. 10. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
h6. Note: See tips section for how to use a nice git prompt for tracking what branch you are in!
h6. 11. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'JBAS-XXXX Frunubucate the Fromungulator'
git commit -m 'JBAS-YYYY Tripple Performance of Fromungulation'
git push my_cool_feature
+Note that git push references the branch you are pushing and defaults to master, *not your working branch*.+
h4. 12. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream
git rebase -i upstream/master
# if you have conflicts fix them and rerun rebase
# The -f, forces the push, alters history, see note below
git push -f my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that this alters history, which while great for making a clean patch, is unfriendly to anyone who has forked your branch. Therefore you want to make sure that you either work in a branch that you don't share, or if you do share it, tell them you are about to revise the branch history (and thus, they will then need to rebase on top of your branch once you push it out).
h4. 13. Get your changes merged into upstream
1. Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 12.
2. Email a pull request to mailto:jbossas-pull-requests@lists.jboss.org jbossas-pull-requests(a)lists.jboss.org (if I haven't subscribed the list, do it https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests here) with a link to your repo, a description of the changes, and who reviewed (if any)
3. After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
4. Don't forget to switch back to master and pull the updates1. git checkout master
git pull upstream master
h4. Appendix A. Adding a new external dependency
1. Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of *provided* scope).
2. Add your dependency to any AS modules that require it, but only with group/artifact.
3. Edit build/pom.xml and add your dependency with only group/artifact.
4. Create a directory in build/src/modules corresponding to the *module's* name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
5. Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
6. Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the *module* name. The group/artifact listed in the nested maven-resource element(s) refer to the *Maven* group/artifact name.
7. *Important:* Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix B. Adding a new AS submodule
1. Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
2. Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do *not* include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
3. Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
4. Add your submodule dependency to any AS modules that require it, but only with group/artifact.
5. Edit build/pom.xml and add the new submodule with only group/artifact.
6. Create a directory in build/src/modules corresponding to the submodule, with a version of "main", like this: "build/src/modules/org/jboss/as/new-subsystem/main".
7. Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
8. Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix C. Profiling with JProfiler
Performance tuning is an important part of AS7 development. In order to use JProfiler on a standalone AS 7 instance, first you need to add the following to your standalone.conf file:
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=com.jprofiler -agentlib:jprofilerti -Xbootclasspath/a:/path/to/jprofiler/bin/agent.jar"
The "jboss.modules.system.pkgs" property tells JBoss Modules to allow the "com.profiler" classes to be found from any class loader, which is essential to allow the JProfiler agent to run.
It's easiest to then just set up your JProfiler session as "Remote", and start the server and the profiler in any order. That's it!
h4. Tips & Tricks!
h4. Creating a Git status prompt in your terminal
This makes it easy to not forget what branch you are working in and quickly tell if you have changes. The following will adjust the PS1 on unix (or cygwin on Windows). Note that it assumes a compiled version of git, which is also the case for the OSX packages. If you are using the bundled rpm version, change the completion path to "/etc/bash_completion.d/git"
GIT_COMPLETION_PATH="/usr/local/git/contrib/completion/git-completion.bash"
if [ -f "$GIT_COMPLETION_PATH" ]; then
GIT_PS1_SHOWDIRTYSTATE=true
. "$GIT_COMPLETION_PATH"
ADD_PS1='$(__git_ps1)'
fi
if [[ ${EUID} == 0 ]] ; then
PS1="\[\033[01;31m\]\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
else
PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
fi
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15596]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 1 month
- 1
- 0
[EJB3 Development] - Ejb 3.1 & JBoss AS 6 M5 User Authentifiaction and Autorisation
by Süleyman Vurucu
Süleyman Vurucu [http://community.jboss.org/people/suikast42] created the discussion
"Ejb 3.1 & JBoss AS 6 M5 User Authentifiaction and Autorisation"
To view the discussion, visit: http://community.jboss.org/message/569788#569788
--------------------------------------------------------------
Hi @ all,
My Environment:
Aplication Sevrer : jboss-6.0.0.20100911-M5 (default configuration without any changes)
IDE: Eclipse 3.6
Jboss Tools V 3.2
Java Version: JDK 1.6 U 20
OS: Windows Vista 32 Bit
My Problem:
I Create a test Application. It Contains only one Stateless Bean with local an remote interfaces:
package beans.stateless;
import interfaces.stateless.FirstStatelessBeanLocal;
import interfaces.stateless.FirstStatelessBeanRemote;
import javax.annotation.*;
import javax.annotation.security.*;
import javax.ejb.*;
import org.apache.commons.logging.*;
import org.jboss.aop.*;
import org.jboss.beans.metadata.api.annotations.*;
import org.jboss.security.annotation.*;
/**
* Session Bean implementation class FirstStatelessBean
*/
@Stateless
@SecurityDomain("JBossWS")
@RolesAllowed("{friend}")
public class FirstStatelessBean implements FirstStatelessBeanRemote, FirstStatelessBeanLocal {
/**
* Default constructor.
*/
private int pCounterLocal = 0;
private int pCounterRemote = 0;
@Resource
private SessionContext myCtx ;
public FirstStatelessBean() {
}
@PreDestroy
public void destroy() {
LogFactory.getLog( getClass() ).warn( "Destroy" );
pCounterLocal=0;
pCounterRemote=0;
}
@PostConstruct
public void create(){
LogFactory.getLog( getClass() ).warn( "Create" );
}
@Override
public String sayHelloLocal( String pMesssage ) {
String lMessage = "Hello Local to " + pMesssage + " " + ( ++pCounterLocal ) + " Times";
LogFactory.getLog( getClass() ).info( lMessage );
return lMessage;
}
@Override
public String sayHelloRemote( String pMesssage ) {
String lMessage = "Hello Remote to " + pMesssage + " " + ( ++pCounterRemote ) + " Times";
LogFactory.getLog( getClass() ).info( lMessage );
// LogFactory.getLog( getClass() ).info( myCtx.getCallerPrincipal() );
return lMessage;
}
@Override
@PrePassivate
public void passviate() {
LogFactory.getLog( getClass() ).warn( "Passivate" );
}
}
On The Client side I get the JNDI Refrence on the following way:
Properties p = new Properties();
p.put( Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory" );
p.put( Context.PROVIDER_URL, "jnp://" + pServerAddr + ":" + pServerPort );
InitialContext jndiContext = new InitialContext( p );
So my excpected behavior (when I call sayHelloRemote) is an Exception. But this request still works with worong user information.
So what I'm doing wrong ?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/569788#569788]
Start a new discussion in EJB3 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 1 month
- 1
- 1