Jim Janssens

Ranch Hand
+ Follow
since Sep 24, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Jim Janssens

As far as I can see this is all normal.
When the setting in your schema 'elementFormDefault' is set to 'unqualified' your elements in the resulting XML document may :

a) NOT have a prefix (besides the root element)
b) NOT be in a default namespace (as that would make them qualified as well)

This example validates to 'unqualified':



This example validates as 'qualified':



and is equivalent to a different notation with a default namespace:


So if you do not want prefixes, use qualified and work with a default namespace.
Of course, if you use other 'components' from schema's in a different namespace, you will have to declare a namespace with prefix and these parts will be fully prefixed when used in your xml
(you could get away with overriding the default namespace though, but that is just a big NO NO)
Ok, I passed the upgrade today with 85% today.
I can confirm that the pass score is 60% and NOT 70%, so the SUN site contains wrong information (this was cleary indicated on the exam result paper)
So I hope this helps future upgrade takers !

Ok, passed the upgrade today with 85%.

I can confirm that the pass score is 60% and NOT 70% (is cearly printed on the exam result paper)
So its as to be expected the same pass score as for the normal part I

Good luck to all future upgrade takers!
Next monday I'm taking the SCEA5 upgrade exam.
However, while reading the SUN certification site I got confused when looking at the pass scores.

The pass score for the normal part I (so 310-052) is 57%
http://www.sun.com/training/catalog/courses/CX-310-052.xml states: Pass score: 57% (37 out of 64 questions)
Thats all good, if you calculate the percentage, you will see that 37 out of 64 is indeed 57% (rounded)

The exam I'm taking is another exam, since its the upgrade so its: 310-053
http://www.sun.com/training/catalog/courses/CX-310-053.xml states this: Pass score: 70% (29 of 48 questions)

First : why is the pass score for the upgrade exam that high compared to the normal part I?
And most importantly: what is going on with that percentage? ---> 29 out of 48 is 60% and NOT 70%

60% seems more reasonable and more close to the normal part I
It seems that there is a higher chance that their is a typo in the percentage on their site (so 60% instead of 70%) then a typo in the number of correct questions: if you take 39 out of 48 you get 81%.
I was thinking it could had something to do with the individual weigth of the questions or so, but then again, if you check the percentage of the normal part I , its correct: 37 out of 64 is indeed 57% (while 39 out of 48 is not 70%)

Can anyone confirm that it is indeed 60% rather then 70% ?
Is it correct to say that:

@DeclareRoles maps to the security-role-ref element of the deployment descriptor.
If you use the role 'super_user' in your bean, you annotate it with the @DeclareRoles("super_user")
Next, you use the isCallerInRole("super_user").
However, if the actual role is admin, but not super_user, you can use the role-link to link "super_user" to "admin".
This way isCallerInRole("super_user") will return true if the actual role is "admin".

Now, this is in contrast with the @RolesAllowed annotation, since, if I'm correct, mapps directly the the "security-role".
So, if I would have annotated my bean method as : @RolesAllowed("super_user") there is no way to map it to "admin", right ?



^^ I will never be able to execute 'myMethod' with role 'admin' since the RolesAllowed asks for a "super_user" role.

The only way I see to "fix" this is to create another role in the deployment descriptor "admin" and give specific method permissions:



This way the descriptor overrides the @RolesAllowed for the "myMethod", also allowing the "admin" role to access the method.
Does this make any sense ?

Rahul Babbar wrote:Persistence Exception is a runtime exception, and hence a system exception. Hence the EJB instance will be discarded for sure...so C is correct..
and since the client had started the transaction, he'll get "EJBTransactionRolledbackException", which is a subclass of EJBException..
So in a way, even B is correct...

Rahul Babbar



Hmm, I overlooked the transaction thing.

This might as well be the solution to the problem, since EJBTransactionRolledbackException is only thrown if the client is local
For a remote client the javax.transaction.TransactionRolledbackException is thrown.

You cannot distinguish if this session bean has a local or remote interface.
It looks like you can, since the bean has no remote/local annotation and only implements one interface -> default to the single interface being local
However you cannot be sure that the interface itself has no remote annotation...

So considering this, option B might be correct but there is not enough information.

The only valid solution is then indeed C
I see what you mean, but you must look at it as being the container.
The question states "what action will the container do".

So, if you say A), it would mean the containers re-throws the PersistenceException and that is NOT the case. The container wraps the persistence exception and then throws a EJBException to which this persistenceexception is chained (so its not retrhowing the same PersistenceException as thrown from the business code)

Anway, the correct answer was ONLY C). There were only radio buttons, no checkboxes. I got this question from the free sun assesment questions on SCBCD. I find it weird since the solution to this question should be C) AND B)

I tested on JBOSS and my client does get a EJBException with the PersistenceException chained. So option B) is also correct stating that the container will wrapp the original PersistenceException in an EJBException that is then thrown to the client.

EDIT

Now that I think of it, maybe its in the small details here.
B) does not say anything about 'wrapping' the PersistenceException with a EJBException. So its probably not 100% complete and thereby not valid as answer. The container does throw an EJBException, but wrapping the original PersistenceException and that is not mentioned in the answer. Anyway, I hope the real exam is more clear on these kind of things
[ December 30, 2008: Message edited by: Jim Janssens ]


It has no descriptor. A client makes a call to oops, which runs in the context of the client's transaction. What action would you expect the container to perform, if any, after this transaction is thrown?

A) The exception is rethrown.
B) An EJBException is thrown by the container to the client.
C) It discards the instance of the session bean.
D) It performs some actions and eventually executes the slashstar method.
E) It is the responsibility of the bean provider to properly catch and handle such exceptions.

Besides the fact that the question is somewhat weird (I don't think you can "throw" a transaction ) the answer is to be said "C" (there is only one answer correct)

Now, as far as I know the PersistenceException is a normal RuntimeException, so its considered to be a System Exception and is therefore wrapped with an EJBException... but B) is not correct. Is there something I'm missing here ?
Your mapped named is 'DefaultDS', that is the resource that the container is going to bind to the resource ref you made using annotations. So the container is going to create a local resource ref with name 'test' and he is going to bind 'DefaultDS' to that local ref.

Anywhere, starting from your bean, you can now do a manual lookup of 'test' but it will always map to 'DefaultDS'. JBOSS automatically deploys an HSQL db under that JNDI name (DefuaultDS). So you are indeed getting a successful connection, but to the in memory database started by JBOSS instead of your oracle database.

You should probably supply the correct mapped name to which the oracle connection is made available under (probably 'test' if I look at your configuration at the bottom)
I'm sorry, but there is nowhere a line that says that you must not define an EJB reference in the web.xml ?

According to me this has nothing to do with patterns either. Regardless how you communicatie with the EJB, using a business delegate, looking it up via a service locator etc, its ALWAYS good practise to define references tho those resources (in this case an EJB) in the web.xml...

However, you could also skip that, and use the global JNDI name of the resource, but you'll loose an extra layer of indirection. Supose the global name changes once on the production env, you have to adapt your code. Using a resource ref the deployer could simply alter the descriptor. And there are other advantages as well.

Secondly; if you are looking up an EJB from a servlet and you are on a J2EE 5 container, you might want to use DI with annotations. Just put an @EJB on the instance field.
EJB2.1: if you explictily call remove on the EJBObject, the corresponding ejbRemove() method of the session bean is executed prior to removing the actual bean instance.

EJB3: You have to mark a business method explicitly with the @Remove annotation. This will serve as a trigger for the container; after this method has executed, the container will remove the bean instance. The container will execute a method marked with @PreDestroy prior removing the instance.

So, @Remove is the trigger (like calling remove() on the EJBOBject with EJB2.1) and @PreDestory is the logic to execute upon removal (like the ejbRemove with 2.1). Also, if your session bean implements the session bean interface, you can only annotate the ejbRemove method with @PreDestroy (its not mandatory to annotate it, but you must not annotate any other method).

Btw; the @Remove can only be specified on SFSB's. As far as I know there is no way to explictly remove SLSB's from a client side perspective in 3.0 (unless you export an EJBOBject for a 2.1 and call remove, which is also valid on SLSB's) someone an idea about this ?
An MDB does not have to run inside a container transaction.

When an MDB is running inside a container transaction, the ack mode is indeed ignored since the acknowldgement of the message will depend on the success of the container transaction.

When an MDB does NOT run inside a container transaction, (tx attribute is NOT_SUPPORTED for example) the reception of messages happens in a local transaction. You can influence the acknowledgement by supplying an extra parameter.

For example; if you specify AUTO_ACK, the container will acknowledge every message if the onMessage() executes successfully. If you supply DUPS_OK the container will acknowledge them in batch. This means that if you already processed message 5 till 10, and the application crashes before the acknowledgement has been done, those messages will be re-delivered. So, you gain performance (less acknowledgements) but your application must be prepared to handle duplicates.

According to me, the difference between a local transaction with AUTO_ACK and a container transaction (REQUIRED for example) is that if you call another resource from the MDB it will not participate in that transaction (there is no 2PC).

So if you have:

onMessage()
{
//1.do some processing
//2.save some data to database
//3.do some processing
}


If at step 3 a runtime exception would be thrown, the message receipt will be rolledback as expected. However, step 2 (the database interaction) would already be commited, by either using a local transaction itself or starting a JTA transaction. Either way, it did not participate in the local transaction started by the message receipt, so its work is already done and commited and will not be rolledback if exceptions occur later in the MDB local transaction. If you expect that the database interaction also rolls back, you should probably use a container/jta transaction (thus specifying REQUIRED)

EDIT:

I have checked the (core ejb3) spec on this. The spec does indeed mention (13.3.5) that you should not specify the ACK mode as the session is transactional and managed by the container. I think this is what you are refering too.

However, its my guess that this is for sending and/or receiving messages not within an MDB.
Its also my guess that this is only true if there is currently a JTA transaction going on (either CMT or BMT).
If there is no transaction, then these arguments will not be ignored.
If you specifiy transacted = true (the second parameter is then ignored), you can control the commit/rollback by calling commit()/rollback() on the JMS session.
If you specified false, the second parameter will tell the session how the acknowledgement should be controlled (either automatically, or either client by calling acknowledge() on the message)

Note that the later is only the case when NOT in a JTA transaction. When creating a session in a bean running in a JTA transaction the ack mode parameter will be ignored.

Now, for the second part (MDB) my explanation above is not entirely correct.

If you look at the spec 5.4.14 (or 6.3 : http://www.huihoo.org/jfox/jfoxmq/jms_tutorial/jmsj2ee.html) then this is the whole story;

When using an MDB the ACK_MODE is never ignored. That is, the ACK_MODE you configure your MDB with (not dealing with JMS API objects directly for receiving in an MDB)

When using ACK_MODE 'AUTO' in combination with CMT, the messages are acknowledgement by the container when the transaction is successfull.
If the transaction is rolledback, the message is redelivered.
When the transaction attribute is not_supported, the outcome is unclear. However, its my guess that the BMT semantics apply in that case (no runtimeexception = message acknowledged, redelivery otherwise)


When using ACK_MODE 'AUTO' in combination with BMT, the MDB has no control over the transaction in which the message is received. When the bean starts a new transaction (using the UserTransaction) and rolls its back, it will have no influence on redelivery of the message (the reception of the message happens in a separate transaction in the BMT case). The only way a message is redeliverd is by throwing a RuntimeException from the onMessage method.

When you use 'DUPS_OK' instead of 'AUTO' the same semantics apply, with the difference that the container will acknowledge messages in batch and thus duplicates can occur.
[ December 18, 2008: Message edited by: Jim Janssens ]
Timers can only be used from SLSB or MDB's, not from SFSB. This makes sense if you think about it; both SLSB and MDB have stateless behaviour. If you would make a timer that calls back within 2 days, it will just fire up a method ready instance from the SLSB pool, it doesn't matter which one since there is no state retention anyways.

If you would be allowed to do this on a SFSB, chances are (very) high that the SFSB in questions (the instance from which you created the timer callback) has already been removed, so the state is already gone. Point is that you cannot count on the state of the given SFSB being there when the timeout has expires, therefore (and probably for other reasons as well) you cannot create a timer callback from a SFSB.

For your second part; yes, you must invoke the timer service method for each callback you want to make. You SLSB can at most have one 'timeout' method that will be called by the timer server once the timeout expires. If you register multiple timers for the same bean, the timeout method will be invoked multiple times.
Well, IMHO, there is only one book for this : RMH
I really enjoyed reading it, it reads smoothly, is very complete, pays a lot of attention to the BP and has lots of examples to illustrate the matter.
It is certainly one of the better books I have seen/read !

I also have the SUN book (j2ee platform web services), it is worthless in terms for the exam. Even in general terms, I do not like it.
If you read the blue prints and some architectural considerations you gain more.

IMHO, the best approach for the exam, and to improve your skills (which is more important than the exam) is to start reading RMH.
I do agree that besides the RMH you need something more focused on the exam too. For this the MZ notes are perfect. Not that the RMH doesn't cover it, but you are never sure that what you read is an exam objective.

So, after RMH you read the notes, and for each objective you use the RMH to clarify/re-read it so you are sure you remember/understand all the important points for the exam. This way you have all the knowledge/understanding and as a bonus you are prepared for the exam as well. After that, you do some mocks to fine tune you exam preparation and to dig up some points that you do not completely understand.

If you find the RMH book to complicated, then you are either not qualified for this matter or you do not have enough experience to begin with this.

BTW; there is no HF book for this (thank god) I got the HF book for the SCBCD, to be honest I threw it away. I kept with the spec and the free mastering EJB2 (I did use the mock questions from HF however....)
18 years ago
Did the exam friday 26 jan (went on vacation afterwards, so could not make this post earlier). My prep time was about 3 weeks, of which only one week intensively. I have been working with XML for over 3 years and with WS for 2 years.

Litrature:

-RMH: read it once completely, but refreshed several topics afterwards
-MZ notes: read them once and quickly re-read them before the exam
-Sun blue prints: read several chapters multiple times

Mocks:

- Sun free trial (20 questions or so ?)
- Whizlabs free trial
- xyzws mock
- MZ's quiz

To me the exam was easy. Did not get many questions on UDDI or JAXR. Most questions make sense if you studied for this exam.

MZ: your guide is really helpful thanks! However, is it possible to separate the answers from the questions in the quiz ? For instance:

PDF 1: Contains the questions only. Each question gets a unique number
PDF 2: Contains the questions, the answer and a written solution
PDF 3: Contains a table with "Question number - Correct answer" for a quick check up

I think this would improve the quality of the quiz.

Edit:

I also want to add that for me this was the exam of which I felt I was learning the most compared to the other exames (besides this I also did SCJP, SCJD, SCBCD, SCEA). So I really advice it to all of you still in doubt for this exam
[ February 05, 2007: Message edited by: Jim Janssens ]
18 years ago