Need an instance that will stay resident. - Complex Event Processing

I closed out my previous thread, and started a new one since I was getting off topic.
I bascially took the HelloWorld application, which starts with 3 java programs:
HelloWorldBeanThis runs just find, then I added a JMS inbound to replace the HelloWorldAdapter
I replaced the HelloWorldBean with the JMS outbound.
That left me with just a HelloWorlldEvent.
So a message comes in, starts an instance of HelloWorldEvent, the instance ends, and a message is possible sent to the JMS outbound via the EPL statement.
So the event is invoked and then dies every time a message comes in from WebLogic.
I placed my JNDI lookup, Connection and Prepared Statements into the HelloWorldEvent java program.
So I need to create an instance that will not die after the message leaves, in order to hold the #Resource injection referenced on the other thread
On a previous thread you mentioned that
You might be able to speed things up a bit by using resource injection or moving the JNDI lookup into a Spring lifecycle method like afterPropertiesSet (),
How would I be able to use the Spring lifecycle method, or #Resource in my current code
What should I change, and could you post an example ?

Here is a suggestion that might make sense. Create an event-bean that is wired up as a listener to your inbound adapter and make your processor a listener on the event-bean (the event bean sits between the adapter and processor in your EPN, essentially). You will need to write a Java class to implement the event-bean and move the JDBC code into the onInsertEvent () of the event-bean. Here is a partial code example:
public class YourEventBean implements InitializingBean, StreamSource, StreamSink {   
private StreamSender streamSender;
public YourEventBean () {
public void setEventSender(StreamSender streamSender) {
this.streamSender = streamSender;
public void afterPropertiesSet () {
// JNDI code goes here (or use resource injection)
public void onInsertEvent(Object event) throws EventRejectedException {
// JDBC code goes here
streamSender.sendInsertEvent(event); // forward event to the processor
<wlevs:event-bean id="yourEventBean" class="">     
     <wlevs:listener ref="yourProcessor"/>

How would you do this in 10g ? Would there be any negative issues in doing this in 10g ?

user10747262 wrote:
How would you do this in 10g ? Would there be any negative issues in doing this in 10g ?I don't quite understand what you mean by "stay resident". All EPN elements are persistent while the application is active. They are not destroyed per event - unless you are referring to the event instance itself? If you are, I don't think its a good idea to put code in there, its really just a data structure to handle interactions between your code and the EPL/CQL engine. If you want code elsewhere then insert an additional bean/adapter wherever you need it in the EPN - adapters can be both inbound and outbound. So you might have:
Inbound JMS -> Processor -> Your bean / Adapter -> Outbound JMS.
In 10g you need to use EventSink / Event Source and initialize the resource either by implementing the InitializingBean or ResumableBean interfaces.


Coherence ProcessingPattern and CoherenceSpringIntegration

We've been investigating using the coherence processing pattern in our application, which is spring based. Someone noticed that we'd been using the SpringAwareCacheFactory as well and wondered if there was way to wire the two together so that ResumableTask could come out of the grid spring-o-magically dependency injected. It seems there should be a way to do it but we're having some difficulties figuring out exactly how.
Thanks in advance.
-Liam Seamus Coughlin 
Yes, spring and coherence combination is magical and also programming model is very simple (i.e. pojo driven). I will broadly, tell you, how to achieve the magic (how I achieved it).
Aim_ Springify the coherence processing pattern that is, bean configured in the spring are executed on the grid in a manner described in the coherence processing pattern. Hence all the features provide by the coherence processing pattern can be leveraged by the spring beans.
1.     Create a bean scope “griddified”_ ie griddified scoped spring bean. The griddified scope in spring can be created as shown below and should be registered with spring bean factory.
public class GriddifiedScope implements Scope {
public Object get(String beanId, ObjectFactory objectFactory) {
*// Create the proxy around the bean scoped "griddified" so that spring + coherence magic begans*. Create a proxy for each call
     public String getConversationId() {
          return null;
     public void registerDestructionCallback(String beanId, Runnable runnable) {
     public Object remove(String beanId) {
*// remove the griddified scoped bean from the spring bean factory*
          return null
}2.     Define the GridTask contract (some interface) i.e grid task take request and give response.
public interface GridTask<Request,Response> extends Serializable { // _GridTask has to be serializable._ For better performance, it's recommended that GridTask also implement *ExternalizableLite & PortableObject*
     public Response execute(Request request);
public <T extends SubmissionOutcomeListener> void addListener(T listener); *// Handle to life cycle execution of the GridTask+*
public void setTaskTimeout(TimeUnit timeUnit); *// configure timeout of the Grid Task*
public TimeUnit getTaskTimeout();
public void setTasktype(TaskTypeEnum enum); *// Task can be Callable (java util),Runnable,Restratable etc....*
public TaskTypeEnum getTaskType();
}This grid task is wrapped in a CallableAdapter and submitted to the Coherence Processing Pattern session_*.  This handover is done by the cglib proxy described in 4 The CallableAdapter looks like
NOTE :- For task type Runnable create RunnableAdapter and similarly for the other types of grid tasks.+_ The cblib proxy will decide based on the grid task type, what xxAdapter will be created (also the executor service) and passed onto the coherence processing pattern framework. The developer is not aware of the xxAdapter, developer only create bean which implement GridTask
public class CallableAdapter<Request, Response> implements Callable<Response>, ExternalizableLite, PortableObject_ {
     private Request req;
private GridTask<Request, Response> grid task;
public CallableAdapter(Request req, GridTask<Request, Response> grid task) {
this.req = req;
this.grid task = grid task;
public CallableAdapter() {
     public Response call() throws Exception {
          return grid task.execute(req);
----- -----
}The creation of GridTask interface will enable the developer to work with interface GridTask, whose scope is griddified. Since the executor service requires Callable, a CallableAdapter wraps the GridTask and pass it on to the Coherence's Processing Pattern framework. Hence the Coherence APIs + java.util.concurrent.Callable is totally abstracted out from the developer.
*Note - Based on the task type set in the grid task, cglib proxy is created
3.     The griddified scoped spring bean should implement GridTask contract.
4.     In the bean post processor phase create a cglib proxy around the griddified scoped bean. I could have used dynamic proxy also as my GridTask contract (interface) is fixed.
5.     The proxy does the actual calling to coherence processing pattern and hand over the outcome.
The spring configuration looks like
<bean id="myTask" class = "com.mycompany.grid task.MyTask" scope="griddified"/>The MyTask is a simple grid task that convert's Integer to String*
     public class MyTask implements GridTask<Integer, String> {
          public String execute(Integer request) {
               return "*Executed on the grid*" + + request.toString();
     }This bean can be injected into any service and can be used as
private MyTask myTask
Integer request = new Integer(1);
String str = myTask.execute(request); // this will be execute in GRID
System.err.println("##### " + str);Expect the following logging coming out coherence processing pattern framework
Submission started
##### Executed on the grid1
Submission doneFor those who dont have spring based application the same concept can be used
GridTask gridTask = GridTaskAwareProxyFactory.getGriddifiedTask(new MyTask()); // getGriddifiedTask create a CGLIB proxy and MyTask is a simple POJO agnostic of the coherence APIs
System.err.println("Outcome " + gridTask.execute(new Integer(2)));Hence, developers only code pojos. I hope it helps you.
1.     The coherence-processing jar should be in the class path along with its coherence configs + coherence dependent jars.
2.     The coherence processing jar contain all the goodies like JMX and hence will be automatically available
3. SpringAwareCacheFactory (extends DefaultConfigurableCacheFactory) is used to implement cache store i.e. the cache store/load bean can be picked up from the spring's bean factory.
The cache store bean is always configured prototype and but there life cycle is controlled by coherence. The same concept can be extended further and backing map/listeners can be
picked up from the spring. When coherence listeners are configured in spring it provide simple mechanism to transmit coherence events to the jvm (via spring application events) -
spring beans which implements ApplicationListener
<!-- Cache Factory configuration-->
     <bean id="cacheFactory"
          <constructor-arg index="0"
               value="/META-INF/spring/coherence-cache-config.xml" />
<!- Cache store configuration-->
     <bean id="entityCacheStore"
Coherence config - cache loader
-- ---
-- ---     Coherence config - Listeners
-- ---     
-- ---Good luck

Problem with PersistentProxy

I'm trying to make use of an org.apache.commons.math.fraction.Fraction in a Persistent class, and so went about creating a PersistentProxy as follows:
import org.apache.commons.math.fraction.Fraction; // relevant import
public class FractionProxy implements PersistentProxy<Fraction> {
    private int numerator, denominator;
    private FractionProxy () { }
    public void initializeProxy (Fraction fraction) {
        numerator = fraction.getNumerator();
        denominator = fraction.getDenominator();
    public Fraction convertProxy () {
        return new Fraction(numerator, denominator);
}From searching around, I couldn't see what else needed to be done (in the documentation, it states that the proxy "must be explicitly registered by calling EntityModel.registerClass(java.lang.Class) before opening the store", but this is done automatically after loading the annotated class, right?) -- when I try to insert an instance of the Persistent container class (marked as an Entity) into an index, however, I receive the following error:
Exception in thread "main" java.lang.IllegalArgumentException: Class is not persistent:
...Any help would be much appreciated.
Hello Michael,
From searching around, I couldn't see what else
needed to be done (in the documentation, it states
that the proxy "must be explicitly registered by
calling EntityModel.registerClass(java.lang.Class)
before opening the store", but this is done
automatically after loading the annotated class,
right?)Yes, you need to explicitly register the proxy class before opening the store -- did you try that? The FractionProxy class is not known to the DPL via normal class loading -- only the Fraction class is know, since it is a Fraction instance, not FractionProxy, that appears in the persistent objects. This is why you have to register proxy class.
-- when I try to insert an instance of the
Persistent container class (marked as an Entity) into
an index, however, I receive the following error:This error should be resolved by registering the proxy class. Please let us know if that doesn't fix it.
Thanks for the quick response, Mark.
So I got it to work by creating an AnnotationModel and registering the Proxy class through it (then setting the EntityStore's model to the AnnotationModel). Is that the prescribed route?
- Michael 
Thanks for the quick response, Mark.You're welcome.
So I got it to work by creating an AnnotationModel
and registering the Proxy class through it (then
setting the EntityStore's model to the
AnnotationModel). Is that the prescribed route?Yes, that's correct.

XQRLUserException: User defined function already defined

A likely bug in the XQuery engine of WLI 8.1.3 manifests itself as follows: an XQuery, which uses an external Java method, causes an "XQRLUserException: User defined function ... already defined" when invoked. This occurs only with <i>some</i> external Java methods, others work just fine. I apologize for not having any automated unit or integration test for this.
Some analysis of the bug: The ExternalFunction instance's bind() is first called to bind a runtime implementation class for the instance. Then later on, for some reason, runtime implementation class is again tried to bind in the same instance. Before this, instance method isBound() is called to ensure that there's no previous binding. However, because there already is, an XQRLUserException is thrown.
The following class manipulations fix the situation by lowering the strictness a little bit: rebinding of a runtime implementation class is allowed as long as the new implementation class name is equal to the implementation class name that is currently bound.
I have not checked whether this is fixed in newer fix packs. However, here's a description of a fix I'm using just in case you face the same bug and can't change fixpacks for some reasons. You can use it but, of course, then "you also assume full responsibility and risk of loss resulting from the use of this information".
The following files are modified. You can extract them from xqrl.jar, decompile them, copy'n'paste the decompiled Java code into new Java files in your IDE and fix things up. You only need xqrl.jar in the compiler classpath.
<li>Add the following to</li>
4517=Function {0} has already been bound to runtime implementation class {1}, but rebinding was attempted to class {2}.
<li>Add the following method to ExternalFunction</li>
public String boundToClassName() {
if (iterator != null) {
return iterator.getName();
} else {
return null;
<li>Add the following method to XqueryPreparedStatement</li>
private void checkBinding(ExternalFunction extFunc, String runtimeImplName) throws XQRLUserException {
String currentlyBoundTo = extFunc.boundToClassName();
if (currentlyBoundTo != null && !currentlyBoundTo.equals(runtimeImplName)) {
throw new XQRLUserException(4517 /* new error message */, extFunc.getName(), currentlyBoundTo,
<li>Replace the two places in XqueryPreparedStatement and its inner class where isBound() { throw new XQRLUserException.. } is previously done, by calling the checkBinding instead
Best regards, Jussi 
This looks like CR176882 that was fixed on 11/04/04

JpdProxy object reuse

Good day,
We are looking at using an MDB to invoke a JPD and I wanted to see if you could store a JpdProxy object as a member variable in the MDB to be reused across invocations. So something along the lines of:
public class MyJpdMDB implements MessageDrivenBean, MessageListener {
private MyJpdProxy myJpdProxy;
public void ejbCreate() throws CreateException {
myJpdProxy = (MyJpdProxy)JpdProxy.create(MyJpdProxy.class, "/MyJpd.jpd");
public void onMessage(Message msg) {
Will this work or does the JpdProxyImpl store context that means it cannot be used for different invocations?
Can you use a JMS Event Generator. The JMS Event Generator is internally an MDB which would invoke the WLI Process. 
Hey there,
No, there are other things we want to do with the message within the MDB and the EG is too restrictive.
Hello Sean,
A JPD Proxy is an RMI client to a business process. I am quite confident that you could use singleton design pattern to reuse the same single instance of the JPD Proxy. Never tried it though
Please follow below procedure for creating process control.
     Instantiating ServiceControl in a POJO/Normal java class
import org.apache.beehive.controls.api.bean.ControlReferences;
import org.apache.beehive.controls.api.bean.Controls;
public class SecurityDelegationEventListener implements ServletContextListener,MessageListener,Serializable{
GetEntityInformationServiceControlBean myAdminCtrl=(GetEntityInformationServiceControlBean)Controls.instantiate(Thread.currentThread().getContextClassLoader(), "dk.skat.tse.controls.ip.GetEntityInformationServiceControlBean", null);
return myAdminCtrl.getEntityInformation(getAdminEntityInformationInputDocument);

Sending a JMS message inside a PostPersist entity listener method

Hi to all,
I have an entity called "Batch" that I want to persist. After the persist, I want to send a JMS message to notify batch insertion to the other clients.
So I created the "Batch" entity as following :
#Table(name = "batch")The "BatchServiceBean" is a session bean which persists the batch and sends the JMS notification message.
Inside this class we have the following method :
    private void sendInsertMessage(Batch insertedBatch) throws JMSException {
        AddBatchMessage message = new AddBatchMessage();
        try {
        } catch (Exception oups) {
    }In the previous code, I recuperate the inserted batch and the "messageSenderServiceBean" facade to send a refresh message.
My problem is that I can get the inserted batch, but the object "messageSenderServiceBean" is null knowing that I have the following annotation to get the "messageSenderServiceBean" facade.
    private MessageSenderServiceLocal                   messageSenderServiceBean;Whyhe object "messageSenderServiceBean" is null ??
Can any one help me ??
Thanks in advance. 
The BatchServiceBean instance used as an EnitityListener for JPA will not be server managed instance (it isn't obtained from the server), and so the server will be unable to inject resources into it. You will need to create an EntityListener method/class that looks up either the BatchServiceBean or the MessageSenderServiceLocal from the server directly.
Best regards,
Hi, thanks a lot for your help, but can you explain more your idea ?
Hi, I red your answer but I didn't understand your solution.
Did you mean that I have to create a new class or method invoked from server ??
Please, I'm in an urgent need for a solution and thanks in advance.
Injection only occurs on server managed objects, not JPA managed entities or other java objects such as the listeners registered with JPA. So your Listener class will need to look up the server objects or other resources directly from the context rather than rely on them being injected. I don't have any good examples handy, but similar to how you would look up an ejb/datasource etc before injection.
Best Regards,