Manuel Alberto Quero

Ranch Hand
+ Follow
since Jul 17, 2009
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Manuel Alberto Quero

Hi,

It seems that the problem is that you are initializing customFacade before ctx is given the proper value by the EJB container (i.e. when ctx is still null).

You can try to initialize customFacade in the method's body or if you prefer you could add a method as follows:


Just remember that this solution is valid when the EJB is referencing to itself...

Hope this can solve your problem,

Manuel
Notice that if you want the EJB container to be aware of transactions annotations (actually, any method annotation), you must invoke the methods as follows:

1- You can use a reference to itself using Dependency Injection:


2- Or you can use the SessionContext interface:


If you use the "this" keyword, the container will ignore transaction annotations.

Hope this helps,

Manuel
If you run into this problem when an EJB is referencing to itself (which is an specific case of circular injection),
you can workaround this using the SessionContext interface (SessionContext.getBusinessObject()):

EjbExampleLocal refToMyself = sessionCtx.getBusinessObject(EjbExampleLocal.class)
refToMyself.otherMethod();

Hope this helps,

Manuel
Java EE design patterns are divided into the following based on the layer.

Presentation Layer:
-Front Controller Design Pattern
-Composite View Design Pattern
-View Helper Design Pattern
-Dispatcher View Design Pattern
-Service To Worker Design Pattern
-Intercepting Filter Design Pattern
-Context Object Design Pattern
-Application Controller Design Pattern
-Fast Lane Reader

Business Layer:
-Business Delegate Design Pattern
-Service Locator Design Pattern
-Session Façade Design Pattern
-T O Assembler Design Pattern
-Transfer Object Design Pattern
-Value List Handler Design Pattern
-Application Service Design Pattern
-Business Object Design Pattern
-Composite Entity Design Pattern

Integration Layer:
-Data Access Object Design Pattern
-Service Activator Design Pattern
-Domain Store Design Pattern
-Web Service Broker Design Pattern

Since you are interested in design patterns related to EJB 3.0, you should focus on Business and Integration Layer.
MVC is an architectural design pattern which involves the whole architecture.

Hope this helps,

Manuel
Hi Somesh Rathi,

In EJB 3.0, JNDI names depend on the Application Server.
Weblogic builds global JNDI names for EJB remote references as follows:

mappedName\#interfacepackage.CalculatorRemote

interfacepackage: the package of CalculatorRemote

You can check this out by accessing Weblogic Admin Console (search for something like: Environment->Server->View JNDI Tree)


The name of EJB local references is defined in deployment descriptors (web.xml and ejb-jar.xml).

Anyway, if you do not want to use lookup explicitly, you could use the @EJB annotation.


Hope this helps,

Manuel
Hello,

I've just started with Android platform. I'd like to use a proximity alert. My code is as follows:



I'm using telnet command to provide position parameters, but the receiver never gets called.

I have read that some other people have the same problem, is there any problem with the code or it is an emulator problem??

Thanks in advance,

Manuel
10 years ago
Hello David,

The web container and EJB container are separated, so yes: once the object is outside the EJB, it becomes detached.
Thats why you must be very careful with fetch(LAZY/EAGER) configuration for retrieving mapped data.

Hope this helps,

Manuel
Hi,

For EJB testing you may find interesting this framework (it is based on junit, and uses cargo to deal with application servers management):

http://jakarta.apache.org/cactus/writing/howto_ejb.html

The tests are executed "inside the application server" so you do not have problems related to application servers resources since you can use them while testing.

Hope this helps,

Manuel
Hi,

Since you shouldn't use I/O operations inside EJB methods, you should avoid using solutions like log4j inside EJB methods.

One approach could be use interceptors to log information before and after EJB method execution. You can get information about what happened inside the method from InvocationContext _ctx (Object executionResult = _ctx.proceed();).

Hope this helps,

Manuel
Hello azhar,

I think you are a litte bit wrong about EJB concepts. You are trying to use a Stateful Session Beans as a singleton (you want it to keep the state between calls from different clients). Stateful Session Beans are intended to keep the state between calls from the same client.

Given your scenario, I think you should use Stateless session beans. You should read about Entity Manager. It is the responsible for keeping synchronized your beans with database so you don't have to worry about that at all...

Hope this helps,

Manuel
Basically, what you need to know is if you need client-initiated transactions or not.

-You need client-initiated transactions if you need to keep a transaction between calls to ejb methods (assuming you are just using stateless session beans). In this case, you will need to initiate the transaction from the servlet by using the UserTransaction interface.

//client-side (servlet)
...
try
{
Context initialContext = new InitialContext();
UserTransaction utx = (javax.transaction.UserTransaction) initialContext.lookup("UserTransaction");
utx.begin();

//call ejb method1 (avoid REQUIRES_NEW transaction attribute)

//call ejb method2 (whithin the same transaction) (avoid REQUIRES_NEW transaction attribute)

if (success)
utx.commit();
else
utx.rollback();
}
catch (Exception e)
{
...
}
...

-If you don´t need to keep the transaction between ejb method calls, then do not use client-initiated transaction (i.e. don't need to use UseTransaction interface as long as you use CMT)

Hope this helps,

Manuel
Hello ram,

I think you gave a pretty good explanation, but i'd like to comment just a couple of things:

-I think we should include in the first case MANDATORY transaction attribute (besides supports and required), right?

-I the second case, if your second method throws a SystemException and the first method does not catch the exception, it willcause the rollback of the first transaction as well, right?

//initiates the first transaction
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
void method1() throws Exception {
...
...
sessionCtx.getBusinessObject(ExampleBean.class).method2(); //call second method

} //Rollback first transaction

//initiates the second transaction
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
void method2() throws Exception {

...
...
String a = null;
a.getBytes(); //throws Runtime exception

} //Rollback second transaction


Best regards,

Manuel
OK Lorand, thanks...

The I think that the answer to the question of Ravi Kiran V:
"Then is the jndi lookup is the appropiate way to call a Bean from Servlet ??"

Is yes (for stateful session beans), but without caching the reference. So every time you execute the servlet you need to perform:

ejb = (ExampleStatefulSession)ctx.lookup("EnterpriseApp/ExampleStatefulSession");

Regards
It looks pretty weird to me, because you are just rethrowing a runtime exception...

Have you tried to setRollbackOnly in your catch code??

...
@Resource
SessionContext sc;
...
...

} catch (Exception ex) {
sc.setRollbackOnly(); //<---
throw ex;
}

...

Regards,

Manuel