Camilo Morales

Ranch Hand
+ Follow
since Jul 14, 2007
Merit badge: grant badges
For More
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 Camilo Morales

Hey Guys, quick question: I want to get a Web based certification but I'm not sure wether to go for the Web component developer Expert (which is already for EE 6) or for the Web Component Professional (which still is for EE5).

Question is Expert in EE6 or Professional in EE5? What would you recommend?

Thanks in advance!
Camilo

SCJP 5, SCBCD 5
You can use the @PostConstruct lifecycle interceptor method to initialize any Statefull Session instance attribute.

This paragraph of Enterprise JavaBeans 3.0 (O'Reilly), Chapter 11.5. "The Life Cycle of a Stateful Session Bean", might be useful:


When a client invokes the first method on the stateful session bean reference, the bean's life cycle begins. The container invokes newInstance( ) on the bean class, creating a new instance of the bean. Next, the container injects any dependencies into the bean instance. At this point, the bean instance is assigned to the client referencing it. Finally, just like stateless session beans, the container invokes any @PostConstruct callbacks if there is a method in the bean class that has this annotation applied. Once @PostConstruct has completed, the container continues with the actual method call.



Regards,

Originally posted by Mirko Bonasorte:
Hi to everybody,
I've started studying EJB 3.0 and I have a doubt about stateless SessionBean pool: why should I have a lot of SessionBean instances even if they are stateless? Could not proxies invoke an unique SessionBean?

Thanks in advances



The reason is that the beans EJBContext carry information about the client that is requesting the service (method), and because each Session instance have its own EJBContext, the container need one session instance per client request.

This paragraph of "Enterprise Javabeans 3.0, O'Reilly, Chapter 3.1. Resource Management", might be useful:

When a bean instance is servicing a request, the EJBContext takes on new meaning. The EJBContext provides information about the client that is using the bean. It also provides the instance with access to its own EJB stub proxy, which is useful when the bean needs to pass references to itself or to other enterprise beans. So the EJBContext is not a static class; it is an interface to the container.



Hope this helps,
It's kinda difficult to give you a hierarchy of topics. The certification give you a list of objectives. I would recommend you to go objective by objective (just like Mikalai Zaikin notes do). Mikalai Zaikin Notes

Its also very helpful to read about the experiences of people that already passed the test. Wall of Fame

Anyway, the following is a VERY VERY little list of topics that should help you to start studying:

1- Enterprise JavaBeans: Session Beans (Stateless, Stateful) - Message-Driven Beans. (They are components, they can not live outside of the container)

2- JPA (Object-Relational mapping): Entity Beans (They are POJO's, they can live outside of the container). Entity Beans lifecycle management: Entity Managers, Persistence Contexts (Transaction-scope, Extended).

3- Interceptors.
4- Transactions.
5- Exception handling.
6- Security.

This is just like an overview of topics, there are SOME MANY subjects missing here that you'll be finding in your study path (Roles, EJB 2.x Interoperability, Restrictions, Requirements, etc etc etc.). This is just to help you start.

Regards,
There are 3 files of the EJB 3 Specification:

1- EJB 3 Core Spec.
2- Persistence Spec.
3- Simplified Spec.

Both links show you the SAME 3 files. (Core is 2.9 MB, Persistence is 1.44 MB and Simplified is 273.08 KB)

Regards,
Hey ranchers,

Could someone throw some light here ... Im trying to create a web service which recieves as a parameter a binary file (i.e. .jar) ... Whats the best way to make this work ? ... I'm guessing serializing the binary file into an XML file ?

Thanks in advance,
16 years ago
Take a look at the stories and experience sharing (in the WALL OF FAME) of the people who already passed any of the 2 versions of the test. Here is the link:

Wall of Fame

Regards,

Originally posted by Vahan Harput:
Hi all,

I have a question regarding the allowed operations in the lifecycle callback methods of stateful session beans:

On the page 80/81 of the EJB 3.0 core specification, it is specified that the PostConstruct/PreDestroy/PrePassivate/PostActivate lifecycle callback methods run in an unspecified transaction and security context. It is also specified that in such methods it is not allowed to access resource managers and other enterprise beans.

At the same time however, in the table 1 of page 79 accessing resource managers and enterprise beans is allowed for these lifecycle callback methods.

This seems to be a contradiction. Is this an error in the specification or am I missing something?

Best regards



Hey,

I can't find where does the spec say that methods with an unspecified transaction and security context can not acces resource managers. In page 350, regarding "13.6.5 Handling of Methods that Run with �an unspecified transaction context�", the spec say this:

The EJB specification does not prescribe how the container should manage the execution of a method with an unspecified transaction context�the transaction semantics are left to the container implementation.
Some techniques for how the container may choose to implement the execution of a method with an unspecified transaction context are as follows (the list is not inclusive of all possible strategies):

� The container may execute the method and access the underlying resource managers without a transaction context.
� The container may treat each call of an instance to a resource manager as a single transaction (e.g. the container may set the auto-commit option on a JDBC connection).
� The container may merge multiple calls of an instance to a resource manager into a single transaction.
� The container may merge multiple calls of an instance to multiple resource managers into a single transaction.
� If an instance invokes methods on other enterprise beans, and the invoked methods are also designated to run with an unspecified transaction context, the container may merge the resource manager calls from the multiple instances into a single transaction.
� Any combination of the above.



For what I know, lifecycle methods like PostConstruct/PreDestroy/PrePassivate/PostActivate (specially PrePassivate/PostActivate) are intended specially to give the Bean Provider the oportunity to close/re-open any resource connections opened manually at any time of the Bean lifetime. So, it wouldn't make any sense if these methods couldnt access resource managers, because you must have access in order to close-re-open the connections.

Please correct me if I'm wrong,

Regards,

Originally posted by Kalyana Sundaram:
How to provide both Remote and local views to the same Session Bean?

There will be two different interfaces for Remote and Local client views. Do I need to add implements clause in my Bean class for both of these interfaces?

How to make use of annotations in this case?

Thanks in Advance !!!



Yes, your Session Bean must implement (or not if the bean's business interfaces are is especified in the deployment descriptor) an inteterface with a @Local annotation (or deployment descriptor tag) and ANOTHER interface with the @Remote annotation (or deployment descriptor tag). One session may have more than 1 Local interface and more than 1 Remote interface. One interface CAN NOT BE Local AND Remote, or in other words, @Local and @Remote annotations can not be used in the same interface.

There is a special case where you dont have to use any @Local or @Remote annotations: If your Session beans implements one interface, and this interface do not have any annotations (Local nor Remote), this interface is assumed to be the LOCAL business interface of the bean.

Here are some fragments of the Specification (EJBCore - page 94-95) which may be a lot more clear about what I'm saying:


A bean class is permitted to have more than one interface. If a bean class has more than one interface�excluding the interfaces listed below (java.io.Serializable; java.io.Externalizable; any of the interfaces defined by the javax.ejb package)�any business interface of the bean class must be explicitly designated as a business interface of the bean by means of the Local or Remote annotation on the bean class or interface or in the deployment descriptor.




The bean class must implement the interface or the interface must be designated as a local or remote business interface of the bean by means of the Local or Remote annotation or in the deployment descriptor.




While it is expected that the bean class will typically implement its business interface(s), if the bean class uses annotations or the deployment descriptor to designate its business interface(s), it is not required that the bean class also be specified as implementing the interface(s).




If bean class implements a single interface, that interface is assumed to be the business interface of the bean. This business interface will be a local interface unless the interface is designated as a remote business interface by use of the Remote annotation on the bean class or interface or by means of the deployment descriptor.




The same business interface cannot be both a local and a remote business interface of the bean.



Regards,
Hey Shoaib,

You may find many more mock questions and links to other mock examn in our study group. It would also be great if you could share your questions with us there, maybe as a text/doc/pdf file.

Here is the link:

[Christophe: Removed]

Regards,
[ September 13, 2007: Message edited by: Christophe Verre ]
Thank you both for your replies.

Yeah, with JBoss I just deleted the resource-ref from the web.xml and change the lookup to java:/DefaultDS and it works perfectly. Anyway, it was mission imposible to make it run in Glassfish ... I guess Im still on the beginning of the learning curve for this product.

Regards,
16 years ago
JSF
Hey ranchers,

I'm kinda new in this technology and thats why Im reading this great book. I'm in chapter 5 and trying to run the Database example, but Glassfish keeps telling me that he can not find the Database that the CustomerBeans is looking up. I am VERY VERY noob in glassfish (how I miss you JBoss) but since all the examples are made to work with Netbeans and Glassfish, I thought that this was a great opportunity to get to know this two products. (I normally work with Eclipse and JBoss).

Anyway ... when I saw the lookup to the databse in the CustomerBean class, I thought (I hoped) that this database was like HiperSonic in JBoss, I mean, that it comes inside the AS, but the NameNotBound exception is telling that Glassfish can not find the database.

Here is the lookup I'm telling you:

DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/mydb");



Could anyone tell me if I have to deploy the DB descriptor (and install a DB in my pc), and if so ,,, where should I put the descriptor (where is the JBoss_Root\server\default\deploy directory in Glassfish ??) ??

Thanks ranchers,
16 years ago
JSF