[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World
by andy.miller@jboss.com
Brian,
Sure thing. I don't have any ejb-jar.xml or jboss.xml files at all. I tried to use all the defaults as well (convention over configuration) for everything that I could. So here is the class declaration:
| package services.ejb;
|
| import java.io.Serializable;
| import java.util.ArrayList;
| import java.util.List;
|
| import javax.ejb.Remove;
| import javax.ejb.Stateful;
| import javax.persistence.EntityManager;
| import javax.persistence.PersistenceContext;
|
| import org.jboss.annotation.ejb.Clustered;
| import services.entities.Order;
|
| @Clustered
| @Stateful
| public class OrderInquiryBean implements OrderInquiry, Serializable {
|
Here is the interface as well:
| package services.ejb;
|
| import java.util.List;
| import services.entities.Order;
|
| public interface OrderInquiry {
|
| public int getPaginationForInquiries();
|
| public List<Order> findOrdersByCustomer(long customerId);
|
| public void cancelSession();
|
| }
|
Like I said. I kept everything as simple as possible.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183957#4183957
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183957
16 years, 2 months
[Design of JBoss jBPM] - Analytical and operational dashboards
by heiko.braun@jboss.com
This refers to https://jira.jboss.org/jira/browse/JBPM-2.
(Don't laugh, some day I can tell my kids "... and I did JBPM-2, really'")
Ok ladies and gentlemen, no more talking about BI and BAM.
>From now on we talk about the analytical and the operational dashboard.
The former offers analytical insights, mostly based on historical data, i.e. the number of process executions compared to last month, while the later will help monitoring operations, i.e. alerting when a job cannot be executed after a number of retries.
To begin with I'll wrap up, what people posted to the JIRA:
anonymous wrote :
| 1. jBPM should store the duration and start date of a state/process in the logs
| 2. Write some detailed info on wiki
| 3. Show processinstance and data
| 4. day/week/month overviews
| 5. near realtime data per process
| 6. produce graphs of day/week/month overviews
|
| Some more ideas i got from a requirements document...
| - Number of cases processed in through a particular process definition
| - Number of cases flowing through a particular activity
| - Longest work item delay by activity
| - Workitems awaiting a particular task
| - Workitems in a specific worklist claimed and/or completed by a particular user
| - Longest end-to-end delay
| - Mean time to approve by activity by participant
| - Mean end-to-end completion time.
|
anonymous wrote :
| Before going full blown on statistics a simple extensible audit trail would be nice, pretty much every commercial workflow toolset has this available in
| one way or another in both their standard clients as well as in their api's. So to me a full blown graphical console doesnt add much to end-users. It is more important to make the jbpm data available through an easy to use api set then to build a console wich wont satisfy all users. The current api command fails in my view on this one as it only offers an all or nothing aproach to getting processlog instances on a process instance....
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183956#4183956
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183956
16 years, 2 months