[JBoss AS7 Development] - Java EE Implementation Technical Requirements
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] modified the document:
"Java EE Implementation Technical Requirements"
To view the document, visit: http://community.jboss.org/docs/DOC-16195
--------------------------------------------------------------
h5. Purpose
The purpose of this document is to specify the ways in which JBoss AS integrates with the implementations of various Java EE specifications. It does not specify details of the implementations themselves unless the correct behavior in JBoss AS depends on the specific behavior of the corresponding EE specification implementation.
h5. JNDI
h6. Services
1. Each JNDI binding into the "java:" space shall have a corresponding MSC service. +This includes programmatic bindings.+1. Services corresponding to bindings in the "java:app" space shall be named "jboss.naming.context.java.app.binding.+appname+.+contextname+", where +appname+ is the EE application name and +contextname+ is the full JNDI context name, sans the leading "app/".
2. Services corresponding to bindings in the "java:module" space shall be named "jboss.naming.context.java.module.binding.+appname+.+modulename+.+contextname+", where +appname+ is the EE application name, +modulename+ is the EE module name, and +contextname+ is the full JNDI context name, sans the leading "module/".
3. Services corresponding to bindings in the "java:comp" space shall be named "jboss.naming.context.java.comp.binding.+appname+.+modulename+.+componentname+.+contextname+", where +appname+ is the EE application name, +modulename+ is the EE module name, +componentname+ is the EE component name, and +contextname+ is the full JNDI context name, sans the leading "comp/".
4. Services corresponding to bindings in the "java:global" or any other space shall be named "jboss.naming.context.java.global.binding.+contextname+" where +contextname+ is the full JNDI context name (including the leading "global/" if present).
5. In cases like the WAR case where one or more of these namespaces are aliased, the most general namespace is used. For example, in a WAR deployment the "java:comp" namespace and the "java:module" namespace are equivalent, so bindings into "java:comp" should be aliased into the "java:module" area with the service named as if the binding had gone into the "java:module" area.
6. In cases where an EE deployment unit is added outside of an application deployment (EAR), the application name is considered to be equal to the module name; in this case the preceding aliasing rule does not apply.
2. Any binding service created from within, or on behalf of, a deployment unit shall have a dependency upon that deployment unit's "install" phase service, and shall be removed (with the corresponding bindings undone) with the deployment unit when the "install" phase service is removed. In this way, all bindings which were established on behalf of a deployment unit will be removed when the deployment unit is undeployed.
h5. Interceptors
1. System-wide EJB interceptors should be specified in the domain configuration, except as specified below.
2. By default, our standard interceptors should be enabled, however each standard interceptor will have a corresponding domain element which can be used to disable that interceptor if so desired.
3. Custom interceptors can be specified in the appropriate subsystem by a combination of module name and class name.
h5. Managed Beans and Java EE (non-CDI) Injection
h6. Services
1. Each Managed Bean has a service which represents the availability of that Managed Bean.1. The service value is, or allows access to, a factory which produces proxy instances which access instances of that managed bean as defined in the EE and Managed Bean specifications.
2. The service shall be named "jboss.managed-bean.+appname+.+modulename+.+name+", where +appname+ is the EE application name, +modulename+ is the EE module name, and +name+ is the name of the managed bean.
2. The Managed Bean service depends on the JNDI binding service for its JNDI binding, if it is a named Managed Bean.
3. The Managed Bean service has a dependency upon the JNDI binding service corresponding to the mappedName (whether it is generated or specified) of each of its injected resources.
4. For unnamed (type-based) resource injections, a dependency is introduced from the injection's mappedName JNDI binding service to the service corresponding to the container-managed class (container-managed class is defined in *EE.5.2.5*).1. The class must be visible from the current module, including via a "Class-Path:" or modular dependency.
2. The list of visible container-managed classes is built and maintained during deployment on the deployment unit context, assembled from information collected from all immediate dependencies.
5. For named (JNDI-based) resource injections where the source name is in the "java:" JNDI protocol space, a dependency is introduced from the injection's mappedName JNDI binding service to the service corresponding to the JNDI binding of the resource.
6. Resources on any interceptor classes associated with the Managed Bean are treated as dependencies the same way as resources associated with the Managed Bean itself.
h6. Object Factory and Proxy
1. The object factory bound into JNDI shall only yield a valid instance if the corresponding Managed Bean service is UP. If the service is not UP, the object factory should block. If the service is failed, or if a dependency is failed or missing, then an exception should be thrown. A blocking object factory can be unblocked by a transition to either the UP state or a failed/missing state.
h5. EJB: Singleton Beans
h6. Services
1. Each Singleton EJB has a corresponding MSC service.1. The service value is, or allows access to, a factory which produces proxy instances to the singleton instance. (+TODO:+ does this return the same proxy every time or a new one every time?)
2. The service shall be named "jboss.ejb.singleton.+appname+.+modulename+.+beanname+" where +appname+ is the EE application name, +modulename+ is the EE module name, and +beanname+ is the name of the EJB.
2. If the singleton is an +eager+ singleton, the service shall have an implicit service dependency on all other EJB and Servlet components' services (with the exception of other +eager+ EJB singletons, which must be explicitly depended on). This is because +eager+ singletons presume to have immediate access to any other services bound into JNDI. (+Note+: perhaps we can somehow use lazy proxies to achieve this behavior instead, if this dependency becomes a problem)
3. Each Singleton EJB service shall have a dependency on services corresponding to the JNDI bindings of any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this EJB configuration.
4. +TODO: Determine what rules (if any) pertain to service dependencies of things injected via CDI+
5. +
+
h5. EJB: Stateless Session Beans
h6. Services
1. Each declared Stateless Session Bean has a corresponding MSC service.1. The service value is, or allows access to, a factory which produces proxy instances to an instance of this EJB, according to the rules of the EJB specification implementation.
2. The service shall be named "jboss.ejb.stateless.+appname+.+modulename+.+beanname+" where +appname+ is the EE application name, +modulename+ is the EE module name, and +beanname+ is the name of the EJB.
2. Each Stateless Session Bean EJB service shall have a dependency on services corresponding to the JNDI bindings of any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this EJB configuration.
3. The instance pools utilized by the Stateless Session Bean portion of the EJB subsystem(s) shall be configurable via the domain model.
h5. EJB: Stateful Session Beans
h6. Services
1. Each declared Stateful Session Bean has a corresponding MSC service.1. The service value is, or allows access to, a factory which produces proxy instances to an instance of this EJB, according to the rules of the EJB specification implementation.
2. The service shall be named "jboss.ejb.stateful.+appname+.+modulename+.+beanname+" where +appname+ is the EE application name, +modulename+ is the EE module name, and +beanname+ is the name of the EJB.
2. Each Stateful Session Bean EJB service shall have a dependency on services corresponding to the JNDI bindings of any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this EJB definition.
3. In order to meet the requirements for proper JPA integration, construction of stateful EJB instances shall happen at the time of the original lookup, as opposed to being constructed lazily.
4. In order to meet the requirements for proper CDI integration, the expiration policy or lifecycle of the EJB must be controllable externally in cases where CDI manages the overall session lifecycle.
5. When constructing a stateful EJB from any context, the transaction, persistence, and security context from the constructing thread must be propagating to the thread which is constructing +and+ initializing the EJB instance. This is most easily accomplished by reusing the same thread for this purpose.
6. The domain model for the Stateful Session Bean portion of the EJB subsystem(s) shall allow configuration of:1. Cache size
2. Default timeouts (idle and passivation)
3. Passivation (enable or disable)
h5. EJB: Message-Driven Beans (MDBs)
h6. Services
1. Each declared MDB has a corresponding MSC service.1. The service shall be named "jboss.ejb.mdb.+appname+.+modulename+.+beanname+" where +appname+ is the EE application name, +modulename+ is the EE module name, and +beanname+ is the name of the MDB.
2. When started, the service shall cause endpoint activation to occur on the resource adapter as well as initiating the management of MDB instances.
3. When stopped, the service shall cause endpoint deactivation to occur.
2. Each MDB service shall have a dependency upon the service that corresponds to the JCA Resource Adapter defined by the MDB configuration.
3. Each MDB service shall have a dependency upon services corresponding to any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this MDB definition.
h5. JCA: Message Inflow
h6. Services
1. Each JCA Resource Adapter (RA) shall have a corresponding MSC service.1. (service name req.)
2. Each JCA RA service shall have a dependency on services corresponding to the JNDI bindings of any resources injected via JNDI.
h5. Class Loading and Modularization of EE Deployments
h4. Important Note!
Please forward all questions and comments about this documentation to mailto:jboss-as7-dev@lists.jboss.org jboss-as7-dev(a)lists.jboss.org. Comments on this article have been disabled.
--------------------------------------------------------------
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 4 months
[jBPM Development] - Impossible to get group tasks paged and ordered
by Fabio Spiga
Fabio Spiga [http://community.jboss.org/people/Spiga] created the discussion
"Impossible to get group tasks paged and ordered"
To view the discussion, visit: http://community.jboss.org/message/566407#566407
--------------------------------------------------------------
Hi everybody,
I need to get the group tasks for which a user is candidate in a manner ORDERED e PAGED, so the API findGroupTasks is not sufficient.
Therefore, I have replaced findGroupTasks() with the following code:
+ taskList = getTaskService().createTaskQuery()
.candidate(filter.getUsername())
.orderDesc(TaskQuery.PROPERTY_CREATEDATE)
.page(startRow, maxResults)
.list();+
The problem is that the resulting list is not ordered.
By debugging jBPM sources, I've found that the problem is in the class org.jbpm.pvm.internal.query.TaskQueryImpl within the method
+public String hql()+
Here the ORDER BY clause is added only if I'm not searching for Candidate. The original code is the following:
+....
+
+if (candidate == null && !count)
appendOrderByClause(hql);+
+....+
Why in your opinion is there such a condition?
How can I do to obtain an ordered and paged list for a candidate user?
Thanks you in advance,
Fabio
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/566407#566407]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 4 months
[jBPM Development] - Create a flexible workflow and deploy it in JBPM on the fly
by Thee R
Thee R [http://community.jboss.org/people/thee] created the discussion
"Create a flexible workflow and deploy it in JBPM on the fly"
To view the discussion, visit: http://community.jboss.org/message/567144#567144
--------------------------------------------------------------
Hi Experts,
I'm a new JBPM starter and looking for a solution to create a flexible workflow. I've a requirement to use Spring platform connecting to JBPM.
User story: Tom wants to create a workflow which requires 1)John, 2)Mike and 3)David to approve a job respectively. Someday later, Tom want to add Mary to be a new approver parallel with Mike. Mary and Mike both have to approve before going to David. The new workflow is 1)John, 2) Mike and Mary and 3)David. All inprogress jobs, which David is reviewing and not submit yet, have to be sent back to be reviewed by Mary as well.
Limitation: Tom can edit the workflow on the fly without modifying Java code and restarting JBPM.
I know Anees advised how to create the workflow programmatically in http://aneesjavaee-osgi.blogspot.com/2008/08/creating-jbpm-workflow-progr... http://aneesjavaee-osgi.blogspot.com/2008/08/creating-jbpm-workflow-progr.... So I can create a workflow programmatically on the fly. However as I know, may be wrong, I have to stop JBPM and deploy the workflow.
Is there anybody has an experience with this kind of requirement? Please advise.
Thanks & Regards,
Thee
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/567144#567144]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 4 months
[JBoss AS7 Development] - Java EE Implementation Technical Requirements
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] modified the document:
"Java EE Implementation Technical Requirements"
To view the document, visit: http://community.jboss.org/docs/DOC-16195
--------------------------------------------------------------
h5. Purpose
The purpose of this document is to specify the ways in which JBoss AS integrates with the implementations of various Java EE specifications. It does not specify details of the implementations themselves unless the correct behavior in JBoss AS depends on the specific behavior of the corresponding EE specification implementation.
h5. JNDI
h6. Services
1. Each JNDI binding into the "java:" space shall have a corresponding MSC service. +This includes programmatic bindings.+1. Services corresponding to bindings in the "java:/app" space shall be named "jboss.naming.context.java.app.binding.+appname+.+contextname+", where +appname+ is the EE application name and +contextname+ is the full JNDI context name, sans the leading "/app".
2. Services corresponding to bindings in the "java:/module" space shall be named "jboss.naming.context.java.module.binding.+appname+.+modulename+.+contextname+", where +appname+ is the EE application name, +modulename+ is the EE module name, and +contextname+ is the full JNDI context name, sans the leading "/module".
3. Services corresponding to bindings in the "java:/comp" space shall be named "jboss.naming.context.java.comp.binding.+appname+.+modulename+.+componentname+.+contextname+", where +appname+ is the EE application name, +modulename+ is the EE module name, +componentname+ is the EE component name, and +contextname+ is the full JNDI context name, sans the leading "/comp".
4. Services corresponding to bindings in the "java:/global" or any other space shall be named "jboss.naming.context.java.global.binding.+contextname+" where +contextname+ is the full JNDI context name (including the leading "/global" if present).
5. In cases like the WAR case where one or more of these namespaces are aliased, the most general namespace is used. For example, in a WAR deployment the "java:/comp" namespace and the "java:/module" namespace are equivalent, so bindings into "java:/comp" should be aliased into the "java:/module" area with the service named as if the binding had gone into the "java:/module" area.
6. In cases where an EE deployment unit is added outside of an application deployment (EAR), the application name is considered to be equal to the module name; in this case the preceding aliasing rule does not apply.
2. Any binding service created from within, or on behalf of, a deployment unit shall have a dependency upon that deployment unit's "install" phase service, and shall be removed (with the corresponding bindings undone) with the deployment unit when the "install" phase service is removed.
h5. Managed Beans and Java EE (non-CDI) Injection
h6. Services
1. Each Managed Bean has a service which represents the availability of that Managed Bean.1. The service value is, or allows access to, a factory which produces proxy instances which access instances of that managed bean as defined in the EE and Managed Bean specifications.
2. The service shall be named "jboss.managed-bean.+appname+.+modulename+.+name+", where +appname+ is the EE application name, +modulename+ is the EE module name, and +name+ is the name of the managed bean.
2. The Managed Bean service depends on the JNDI binding service for its JNDI binding, if it is a named Managed Bean.
3. The Managed Bean service has a dependency upon the JNDI binding service corresponding to the mappedName (whether it is generated or specified) of each of its injected resources.
4. For unnamed (type-based) resource injections, a dependency is introduced from the injection's mappedName JNDI binding service to the service corresponding to the container-managed class (container-managed class is defined in *EE.5.2.5*).1. The class must be visible from the current module, including via a "Class-Path:" or modular dependency.
2. The list of visible container-managed classes is built and maintained during deployment on the deployment unit context, assembled from information collected from all immediate dependencies.
5. For named (JNDI-based) resource injections where the source name is in the "java:" JNDI protocol space, a dependency is introduced from the injection's mappedName JNDI binding service to the service corresponding to the JNDI binding of the resource.
6. Resources on any interceptor classes associated with the Managed Bean are treated as dependencies the same way as resources associated with the Managed Bean itself.
h6. Object Factory and Proxy
1. The object factory bound into JNDI shall only yield a valid instance if the corresponding Managed Bean service is UP. If the service is not UP, the object factory should block. If the service is failed, or if a dependency is failed or missing, then an exception should be thrown. A blocking object factory can be unblocked by a transition to either the UP state or a failed/missing state.
h5. EJB: Singleton Beans
h6. Services
1. Each Singleton EJB has a corresponding MSC service.1. The service value is, or allows access to, a factory which produces proxy instances to the singleton instance. (+TODO:+ does this return the same proxy every time or a new one every time?)
2. The service shall be named "jboss.ejb.singleton.+appname+.+modulename+.+beanname+" where +appname+ is the EE application name, +modulename+ is the EE module name, and +beanname+ is the name of the EJB.
2. If the singleton is an +eager+ singleton, the service shall have an implicit service dependency on all other EJB and Servlet components' services (with the exception of other +eager+ EJB singletons, which must be explicitly depended on). This is because +eager+ singletons presume to have immediate access to any other services bound into JNDI. (+Note+: perhaps we can somehow use lazy proxies to achieve this behavior instead, if this dependency becomes a problem)
3. Each Singleton EJB service shall have a dependency on services corresponding to any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this EJB configuration.
4. +TODO: Determine what rules (if any) pertain to service dependencies of things injected via CDI+
5. +
+
h5. EJB: Stateless Session Beans
h6. Services
1. Each declared Stateless Session Bean has a corresponding MSC service.1. The service value is, or allows access to, a factory which produces proxy instances to an instance of this EJB, according to the rules of the EJB specification implementation.
2. The service shall be named "jboss.ejb.stateless.+appname+.+modulename+.+beanname+" where +appname+ is the EE application name, +modulename+ is the EE module name, and +beanname+ is the name of the EJB.
2. Each Stateless Session Bean EJB service shall have a dependency on services corresponding to any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this EJB configuration.
3. The instance pools utilized by the Stateless Session Bean portion of the EJB subsystem(s) shall be configurable via the domain model.
h5. EJB: Stateful Session Beans
h6. Services
1. Each declared Stateful Session Bean has a corresponding MSC service.1. The service value is, or allows access to, a factory which produces proxy instances to an instance of this EJB, according to the rules of the EJB specification implementation.
2. The service shall be named "jboss.ejb.stateful.+appname+.+modulename+.+beanname+" where +appname+ is the EE application name, +modulename+ is the EE module name, and +beanname+ is the name of the EJB.
2. Each Stateful Session Bean EJB service shall have a dependency on services corresponding to any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this EJB definition.
3. In order to meet the requirements for proper JPA integration, construction of stateful EJB instances shall happen at the time of the original lookup, as opposed to being constructed lazily.
4. In order to meet the requirements for proper CDI integration, the expiration policy or lifecycle of the EJB must be controllable externally in cases where CDI manages the overall session lifecycle.
5. When constructing a stateful EJB from any context, the transaction, persistence, and security context from the constructing thread must be propagating to the thread which is constructing +and+ initializing the EJB instance. This is most easily accomplished by reusing the same thread for this purpose.
6. The domain model for the Stateful Session Bean portion of the EJB subsystem(s) shall allow configuration of:1. Cache size
2. Default timeouts (idle and passivation)
3. Passivation (enable or disable)
h5. EJB: Message-Driven Beans (MDBs)
h6. Services
1. Each declared MDB has a corresponding MSC service.1. The service shall be named "jboss.ejb.mdb.+appname+.+modulename+.+beanname+" where +appname+ is the EE application name, +modulename+ is the EE module name, and +beanname+ is the name of the MDB.
2. Each MDB service shall have a dependency upon the +endpoint activation+ service that corresponds to its configuration.
3. Each MDB service shall have a dependency upon services corresponding to any resources injected via JNDI, as well as any such resources injected into any interceptor associated with this MDB definition.
h5. Class Loading and Modularization of EE Deployments
h4. Important Note!
Please forward all questions and comments about this documentation to mailto:jboss-as7-dev@lists.jboss.org jboss-as7-dev(a)lists.jboss.org. Comments on this article have been disabled.
--------------------------------------------------------------
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 4 months
[JBoss ESB Development] - [HELP] Unable to consume reply message from MQ Queue
by Sheeraz Junejo
Sheeraz Junejo [http://community.jboss.org/people/sjunejo] created the discussion
"[HELP] Unable to consume reply message from MQ Queue"
To view the discussion, visit: http://community.jboss.org/message/574484#574484
--------------------------------------------------------------
| | Hi,
I am having problem consuming messages from MQ Server Queue. I am using WebSphere MQ Server 7 with my web application to put messages on IN Queue which will then Consume by my MDB deployed on jBoss and put reply back on OUT Queue.
My web application is deployed on jBoss 4.2.3 and I am using MQ Resource Adapter to connect to MQ Server.
I am able to successfully put message on IN Queue where MDB is listening which consume the messages, do some processing and put reply back on OUT Queue where my web application is waiting for a response but it get TIMED OUT. I mean I can see the response in MQ Explorer which is just sitting there waiting to be consumed but my web application can not recognize for some reason.
I have tried with simpler Co-relation ID like '1' but didn't work. I am using following code to do all of the above;
| *Code:* |
|
Connection connection = null;
Session session = null;
MessageProducer producer = null;
Destination reqQueue = null;
Destination repQueue = null;
try {
timeStart = System.currentTimeMillis();
InitialContext ctx = new InitialContext(); // Initial Context of type JMS Connection Factory
Object factoryObj = ctx.lookup(jmsCxFactory);
ConnectionFactory cxf = (ConnectionFactory)factoryObj;
connection = cxf.createConnection();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
connection.start();
_serviceLocator = new ServiceLocator(); // Look up queues
reqQueue = _serviceLocator.lookupDestination("queue/INQueue");
repQueue = _serviceLocator.lookupDestination("queue/OUTQueue");
producer = session.createProducer(reqQueue); // Register a producer
Message jmsMsg = session.createTextMessage(message); // Assign request to Message object so we can send it to Database Server later.
jmsMsg.setJMSReplyTo(repQueue); // Preparing a class to wait for a response on Response queue
producer.setDisableMessageID(false); // Make sure messages gets an id
String correlationId = "1"; // Get and set unique Correlation ID so we can receive correct messages
jmsMsg.setJMSCorrelationID(correlationId);
jmsMsg.setStringProperty("FORMAT", pingLevel); // Set the message format
producer.send(jmsMsg); // Put message on Queue
MessageConsumer receiver = session.createConsumer(repQueue, "JMSCorrelationID='" + correlationId + "'"); // Now receive message
long JMSConnectionTimeout = 5000L; // Set timeout value - Default 10 Sec.
Message reply = receiver.receive(JMSConnectionTimeout); // Now receive a response
if (reply instanceof TextMessage) {
String response = ((TextMessage)reply).getText();
passedReq++; // Increment in the passed request counter
} else {
finalResponse += "Request : Timed Out..."; <--- Always timed Out and control ends up here
failedReq++; // Increment in number of time out requests
}
}
catch (NamingException e) {
finalResponse += "Error Occured : Naming Exception - " + e.getMessage();
}
catch (JMSException e) {
finalResponse += "Error Occured : JMS Exception - " + e.getMessage();
}
catch (RuntimeException e) {
finalResponse += "Error Occured : Runtime Exception - " + e.getMessage();
}
finally {
closeResource(producer);
closeResource(connection);
closeResource(session);
}
|
Does anyone know what could be the reason and why its happening? Your help and comments will be appreciated.
Thanks
--
SJunejo |
|
|
| |
|
|
|
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/574484#574484]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 4 months
[JBoss Tools Development] - JBoss Tools Target Platform Provisioning (or, how to resolve missing dependencies when compiling JBoss Tools)
by Nick Boldt
Nick Boldt [http://community.jboss.org/people/nickboldt] modified the document:
"JBoss Tools Target Platform Provisioning (or, how to resolve missing dependencies when compiling JBoss Tools)"
To view the document, visit: http://community.jboss.org/docs/DOC-15755
--------------------------------------------------------------
*+This document is a work in progress and subject to change.+*
In order to build JBoss Tools in your workspace (or on your local machine, if not in Eclipse), you need to have its dependencies available. There are a number of ways to accomplish this, depending on your needs and how much manual effort you'd like to expend.
First, you'll need the JBoss Tools sources on disk. Fetch sources from trunk (or another branch) into ~/tru (or another location on disk).
svn co http://anonsvn.jboss.org/repos/jbosstools/trunk/ http://anonsvn.jboss.org/repos/jbosstools/trunk/ ~/tru
Next, you can either install the target platform update site into your Eclipse install, or simply let Tycho fetch all the dependencies into a local m2 cached repository.
*------------------------------*
*
*
*OPTION 1: Let Tycho Resolve Dependencies From Remote Repo Into Local Cache
*
In this case, you don't even need Eclipse installed - you just need the sources on disk.
You will of course need http://maven.apache.org/download.html Maven 3 installed.
a) Build parent + target platform poms (should only take a few mins; includes 18M of downloaded artifacts into your local Maven cache, eg., ~/.m2).
cd ~/tru/build; mvn3 clean install -f http://anonsvn.jboss.org/repos/jbosstools/trunk/build/parent/pom.xml parent/pom.xml
b) Build one or more components (when done, ~/.m2 will be 1.1G in size):
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+ *-P helios-remote-target*
*or*
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+** *-P helios-remote-target* *+-P seam-bootstrap+*
The 'helios-remote-target' will fetch the latest dependencies from this update site:
http://download.jboss.org/jbosstools/updates/target-platform/latest/ http://download.jboss.org/jbosstools/updates/target-platform/latest/
If you omit the 'helios-remote-target' profile, you will instead use http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/uni... unified.target to resolve specific versions of features/plugins, rather than the lastest available.
If you install http://m2eclipse.sonatype.org/ m2eclipse, you can also start mvn3 builds from within Eclipse.
*------------------------------*
*
*
*OPTION 2: Let Tycho Resolve Dependencies From Local Repo Into Local Cache*
*
*
** If have a local Target Platform repo already mirrored on disk (for example, you http://download.jboss.org/jbosstools/updates/target-platform/ downloaded a zip of the above update site and unpacked it somewhere, you can use the 'helios-local-target' profile.
You will of course need http://maven.apache.org/download.html Maven 3 installed.
a) Edit the http://anonsvn.jboss.org/repos/jbosstools/trunk/build/parent/pom.xml parent/pom.xml to point to the correct path on disk, and rebuild it. (The default path is the one that Hudson uses.)
vi parent/pom.xml # search for 'helios-local-target'
mvn3 clean install -f parent/pom.xml
b) Build using the 'helios-local-target' profile you modified to point to the correct location on your disk.
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+ *-P helios-local-target *
*or+
+*
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+ *-P helios-local-target +-P seam-bootstrap+*
This is how the Hudson builds run: compile the parent & target platform pom.xml files, then build the desired component(s) against a locally available update site.
If you omit the 'helios-local-target' profile, you will instead use http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/uni... unified.target to resolve specific versions of features/plugins, rather than the lastest available.
If you install http://m2eclipse.sonatype.org/ m2eclipse, you can also start mvn3 builds from within Eclipse.
*------------------------------*
*OPTION 3: (DEPRECATED) Install Target Platform Update Site into Eclipse*
Point the latest Eclipse 3.6.x build at the http://download.jboss.org/jbosstools/updates/target-platform/latest/ Target Platform update site (generated from this http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/e36... e361-wtp322.target file). Be sure to show uncategorized features, then install everything.
http://download.jboss.org/jbosstools/updates/target-platform/latest/ http://download.jboss.org/jbosstools/updates/target-platform/latest/
After restarting Eclipse, you should have all the dependencies installed to develop JBoss Tools; however, if you want to use this Eclipse as the target platform against which to build using Tycho, you need to also unzip the latest http://http//download.eclipse.org/eclipse/downloads/drops/R-3.6.1-2010090... deltapack (eg., eclipse-M20101020-0925-delta-pack.zip) into your Eclipse root folder. Once you've done that, you can use the following commands to tell Maven (and Tycho) to use that Eclipse instead of doing its own resolution.
You will of course need http://maven.apache.org/download.html Maven 3 installed.
a) Build parent + target platform poms (should only take a few mins; includes 18M of downloaded artifacts into your local Maven cache, eg., ~/.m2).
cd ~/tru/build; mvn3 clean install -f http://anonsvn.jboss.org/repos/jbosstools/trunk/build/parent/pom.xml parent/pom.xml
b) Build all components or use the bootstrap profiles in http://anonsvn.jboss.org/repos/jbosstools/trunk/build/pom.xml build/pom.xml to build a stack of components, such as Seam:
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+ *-Dtycho.targetPlatform=/path/to/your/eclipse*
*or*
cd ~/tru/build; mvn3 clean install +-U -B -e -fae -Dmaven.test.skip+ *-Dtycho.targetPlatform=/path/to/your/eclipse* *+-P seam-bootstrap+*
Note that if you install http://m2eclipse.sonatype.org/ m2eclipse, you can also start mvn3 builds from within Eclipse.
Note that the use of *-Dtycho.targetPlatform=* is *DEPRECATED* and is planned to be removed from a future release of Tycho.
*------------------------------*
*
*
For other ways to build, see http://community.jboss.org/docs/DOC-15513 http://community.jboss.org/wiki/HowtoBuildJBossToolswithMaven3
h2.
Checking the Target Platform To See What's There
There are three ways to see what's already in the Target Platform. (This can be useful if you're checking to see if something's already there or needs to be added.)
Option 1:
1. In Eclipse, go to Help->Install New Software...
2. Provide the URL: http://download.jboss.org/jbosstools/updates/target-platform/latest/ http://download.jboss.org/jbosstools/updates/target-platform/latest/
3. Click Add and give it a useful name such as "Current JBoss Tools Target Platform"
4. Browse the list of features. Note that you may have to uncheck the "Group Items By Category" checkbox.
Option 2:
Explore the file http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/mul... http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/mul... or http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/uni... http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/uni... in an XML editor or Eclipse's Target Platform editor
Option 3:
Explore the file http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/mul... http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/mul... or http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/uni... http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/uni.... This file is the same as its matching target file but as an Ant script. It does not contain feature/plugin versions, just repo URLs and a list of IUs (feature.group == feature + contained plugins). It is therefore instructions for how to download the contents of the .target file onto your local disk. You can run it using `ant -f multiple.target.p2mirror.xml` or using the http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/bui... build.xml script in the http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/ same folder.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15755]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 4 months
[JBoss ESB Development] - Re: JCRMessageStoreImpl store only message body?
by jack lista
jack lista [http://community.jboss.org/people/jackalista] created the discussion
"Re: JCRMessageStoreImpl store only message body?"
To view the discussion, visit: http://community.jboss.org/message/572331#572331
--------------------------------------------------------------
I am looking at the MessageStore and am interested in a browse-able, query-able interface for the store, and came across this and another thread talking about using JCR implemetations as either the store itself or as merely a way to provide JCR functionality with the message being stored elsewhere (I'm assuming the actual store would still be inm the DB in this case?).
I did find the JCRMessageStoreImpl class, I'm not familiar with the code per se but it looks like the payload is being extracted so I'd guess that the entire message is not being stored, is this correct? That also seems to be the status put forth by a few JIRA entries ( https://jira.jboss.org/browse/JBESB-1769 https://jira.jboss.org/browse/JBESB-1769, https://jira.jboss.org/browse/JBESB-2205 https://jira.jboss.org/browse/JBESB-2205, https://jira.jboss.org/browse/MODE-119 https://jira.jboss.org/browse/MODE-119 & https://jira.jboss.org/browse/MODE-280 https://jira.jboss.org/browse/MODE-280) and the consensus seems to be that the use of this JCR technology for the MessageStore will not be as useful as one might want without the entire message being stored.
Is this the current status of this stuff and am I understanding the situation correctly? So I'm guessing that this does not provide a way to browse and query a MessageStore? Long story short, I'm looking for an audit oriented MessageStore with as high level an API as possible, and not sure what functinality exists and where it's headed, I'd like to leverage the work you guys are doing if it makes sense but I am not sure what the best current thinking is on this and am searching this stuff to try to figure it out. It kind of looks like this stuff is either a dead end, or perhaps is slated for dev sometime in the future but I can't tell which.
Can anyone advise on the best currently available MessageStore functionality for browsing and querying the MessageStore and any other needed functionality to provide audit logging features? Or, if appropriate, can you share what road map exists so that we can use what's there now and remain properly positioned to be ready to take advanatage of further features as they come online? Thanks...
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572331#572331]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 4 months