Musab Al-Rawi

Hi,
the purpose is to disable scriptlets and REMIND developers not that they can't use them ... ignores scriptlets could be confusing, as you won't get what you expect.

Thanks all

Hi all,

After more than 6 months of preparation I passed the exam yesterday.
I read Manning book twice, the spec's twice as well. the first time I go through a book I highlight things and take general notes then the second time I read a book i refine my notes.
enthuware mock exams helped me understand the topic as those great people provide such a nice explanation for each question. I recommend buying their mock exam as they are the best really!

So thank God I passed with a nice score, although I was aiming for 90's but 86 isn't bad.

good luck all

How about having an interceptor for your MDB that throws an exception based on a criteria that can be captured from the DB or wherever.

Hi,
The first problem that I can spot is that you are creating threads from a session bean, you can't create threads from a session bean.

May I interrupt you guys, I would appreciate it if you allow me to help as well.
I would like to participate in a project.

Please anyone, even if partial answer.

Hello all,
the ejb3.0 specification says (chapter 60 page 241):
the jar file that contains the client should contain one of the following: • a reference to the ejb-client JAR file • a reference to the ejb-jar file that contains the client view classes • a copy of the client view classes
There is also an example on page 242:
In this example, the Bean Provider has chosen to package the enterprise bean client view classes in a separate jar file and to reference that jar file from the other jar files that need those classes. Those classes are needed both by ejb2.jar, packaged in the same application as ejb1.jar, and by ejb3.jar, packaged in a different application. Those classes are also needed by ejb1.jar itself because they define the remote interface of the enterprise beans in ejb1.jar, and the Bean Provider has chosen the by reference approach to making these classes available. The deployment descriptor for ejb1.jar names the client view jar file in the ejb-client-jar element. Because ejb2.jar requires these client view classes, it includes a Class-Path reference to ejb1_client.jar. The Class-Path mechanism must be used by components in app2.ear to reference the client view jar file that corresponds to the enterprise beans packaged in ejb1.jar of app1.ear. Those enterprise beans are referenced by enterprise beans in ejb3.jar. Note that the client view jar file must be included directly in the app2.ear file. app1.ear: META-INF/application.xml ejb1.jar Class-Path: ejb1_client.jar deployment descriptor contains: <ejb-client-jar>ejb1_client.jar</ejb-client-jar> ejb1_client.jar ejb2.jar Class-Path: ejb1_client.jar app2.ear: META-INF/application.xml ejb1_client.jar ejb3.jar Class-Path: ejb1_client.jar

Now finally my questions are:
1. Why did we need to include the ejb1_client.jar in app2.ear (or even in app1.ear), wasn't it enough to refer to it (using class-path in Manifest, or may be just by using <ejb-client-jar>) as the bullets quoted first suggest?
2. How come we didn't need to use <ejb-client-jar> for ejb2.jar
3. Since both of ejb1.jar and ejb2.jar are packaged in app1.ear couldn't we simply refer to the ejb1_client.jar in the Manifest file of app1.ear?

Please, I appreciate your input on this.

What about using MDB for operations that might take a long time?

Yes the container decides when to spaawn a new ejb but at the end when an ejb client invokes a method it will have to wait (block) until it's over.
When I said multi-threading i meant that the client won't have to wait, instead run the method in a seperate thread.

Hello All,

As we all know, we can't instantiate threads from within EJBs. But the question is:
Do we need threads, to perform operations faster may be, or to split a lengthy transaction?

Of course dealing with threads directly is tricky and probably that's one of the reasons why it is forbidden in EJB, but if there is a solution that provides the feeling of threading how far would you need it and use it?

Please think of this post as a think-out-loud post, so everyone's participation is highly appreciated.

Hello,

What do you mean with "the rest is skipped".
Are you using JSP's, JSF or servlets?
any Exception in the server's log?
when you try to insert a DVD, do you get the form, and dose DB change?

Elaborate more please

Sorry, nothing that I can think of.
Please give us hints on this topic if you find anything.

Thanks

Hello Ahmed,

I am brainstorming here so I am not sure if this would work, but what about using MDB the returns confirmation if sub-transactions succeed.
so the main EJB starts sending messages to different MDBs and check the confirmation of each.

but this sounds like your EJB will be doing a lot of management on its own, in other words you won't utilize services provided by the container properly like transactions. Don't you think?

mappedName attribute is used with Remote EJBs (not local ones).
It is used to give your EJB a "global" name, this name is added to the JNDI and it allows components that are outside your application to access it and use it.

name attribute on the other hand, is used to give EJB a local name, components the belong to the same application that declare the EJB will use this name, they can also use the mappedName if you provided one.

I hope that helped.