Kaxhif Khan

Hi,


Can anyone tell me about the course contents (Specification(s) or Books etc) required for Java certification exam (1z0-897) ?

Further, I was waiting for JEE-7 so how long may it take for oracle to make available Java EE 6 Web Services Developer exam ?

Frits Walraven wrote:
Be careful here, none of the JPA implementations I have come across so far have been strict on the JPA specifications. The fact that it works in this JPA implementation is perfectly possible but definitely not portable.

So what should we follow if we had any question on it in exam i) the specs/book ? or ii) practical findings ?

Tim Holloway wrote:You do not need to ORDER BY a selected column. You can not only order by a column not returned by the SELECT, you can order by complex relations.

GROUP BY, however, only works on columns selected for ORDER BY. Otherwise the results would likely contain random "groups" of single records.

Only having is working as expected so far for me. I tried the following hand made SQL with My SQL client and it ran successfully.

SELECT name FROM EMPLOYEE GROUP BY city ORDER BY postalCode

K. Tsang wrote:

Only expressions that are derived directly from expressions in the SELECT clause are allowed in the ORDER BY clause

Yet you got no errors is weird. Did you actually get results? Did you check the server log?

Results are correct ordered by postalCode in address(embeddable) object. I was expecting that query will break with "IllegalArgumentException" however i cross validated the server log which is clean).

I ran the following handmade query on My SQL client

select name from employee order by postalCode

and it also ran successfully producing output ordered by postalCode.

Hi, i am preparing for JPA exam where i found a few ambiguities ..

1) In Book (Pro JPA ) page 233 it is quoted as "If the SELECT clause of the query uses state field path expressions, the ORDER BY clause is limited
to the same path expressions used in the SELECT clause. For example, the following query is not legal:"

SELECT e.name FROM Employee e ORDER BY e.salary DESC

so technically it should give error but when i tried it practically i found the query working without error, here is the query i tried
SELECT e.name FROM Employee e ORDER BY e.address.postalCode

[e.name = String, e.address.postalCode = int where address is an "embeddable class" inside Employee object].

The same problem i found with GROUP BY clause as well. I may be doing something wrong because specification and book has said the same thing.
Kindly help me clear this ambiguity.

Thanks in advance

Yes, i do understand this but i have confusion regarding this in the context of pessimistic locks.

Let say we try to obtain pessimistic lock on "Department" object (from your example) i.e.

em.lock(dept, LockModeType.PESSIMISTIC_WRITE );

before we changed anything in it and calling lock method (as shown above) throws "LockTimeoutException" then what is the statement level rollback in this case ?

Hi,

i am preparing for JPA exams where i have some minor confusions.

1) PerssimisticLockException marks transaction mark transaction for rollback only if lock failure cause transaction level roll back, from this what i understand is that all operations within a transaction will roll back.

2) LockTimeoutException is thrown and only cause statement level roll back, what does this "statement level rollback" means exactly ?

Hi,


In EJB specification document section 14.3.1 (page number 384), table row 2 (system exception portion) said via note 'E' as

[E] If the business interface is a remote business interface that extends java.rmi.Remote, the java.rmi.RemoteException is thrown to the client, which will receive this exception.

Practically i found "com.sun.ejb.containers.InternalEJBContainerException" thrown to the client, here is the code

@Remote public interface BookServiceRemote extends java.rmi.Remote{ public void searchBook(); } @Stateless public class BookService implements BookServiceRemote { @Resource EJBContext ctx; private Employee emp; /** * Default constructor. */ public BookService() { // TODO Auto-generated constructor stub } @Override @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) public void searchBook() { throw new IllegalArgumentException(); } }

"searchBook" method of BookService is invoked from another EJB.

Is it a mistake in specs document or i am doing something wrong because of which i am not able to receive "java.rmi.RemoteException"?

Yes but why it is called two times ? Is it logically correct that we specify an interceptor and it is getting called twice ?

Glassfish mandates the objects like Employee to be serializable. But the spec does not mandate it.

That's the point, specification allowed containers to choose different implementation for e.g. glassfish gives an error but other containers may not.

If one got a question in exam like this, what answer he/she should choose ?

1) Whats difference between JEE6 and JEE7 ? Does EJB specification is also different for JEE6 and JEE7 ?
2) Here is second question with some code
public class AInterceptor { @AroundInvoke public Object doLog(InvocationContext context) throws Exception { System.out.println("LoggingInterceptor"); return context.proceed(); } } @Interceptor public class BInterceptor{ @AroundInvoke public Object doSecurityLog(InvocationContext context) throws Exception { System.out.println("SecurityInterceptor"); return context.proceed(); } } @Local public interface BookService { public void searchBookById(int id); } @Stateful(passivationCapable = true) public class BookServiceImpl implements BookService{ private SessionContext context; private Employee employee = new Employee("Azimuth"); @Resource public void setContext(SessionContext context) { this.context = context; } @Override @Interceptors({AInterceptor.class, BInterceptor.class, BookServiceImpl.class}) public void searchBookById(int id) { // TODO Auto-generated method stub System.out.println("Search Book by ID : " + id); String str = context.getInvokedBusinessInterface() + ":" + context.getContextData(); System.out.println(str); } @AroundInvoke public Object doLog(InvocationContext context) throws Exception { System.out.println("LoggingInterceptor"); return context.proceed(); } }
i) AInterceptor does not have 'Interceptor' annotation but still get called in normal order, does this mean that 'Interceptor' annotation is not important ?
ii) "doLog" method in BookServiceImpl got called 2 times ? Why ?

According to the spec, the container may be able to serialize some non-serializable objects. Or, the container will use externalization to serialize the non-serializable object.
Setting non-serializable object to null before the stateful bean passivated is just a good practice, but not a must.

Its getting confusing for me, here is what i have done

@Local public interface BookService { public void searchBookById(int id); } @Stateful(passivationCapable = true) public class BookServiceImpl implements BookService{ private SessionContext context; private Employee employee = new Employee("Azimuth"); @Resource public void setContext(SessionContext context) { this.context = context; } @Override public void searchBookById(int id) { // TODO Auto-generated method stub System.out.println("Search Book by ID : " + id); String str = context.getInvokedBusinessInterface() + ":" + context.getContextData(); System.out.println(str); } } public class Employee { private String empName; public Employee(String name) { empName = name; } public String getEmpName() { return empName; } public void setEmpName(String empName) { this.empName = empName; } }



Here is stack trace from the server log file

Caused by: java.io.IOException
at com.sun.ejb.EJBUtils.serializeObjectFields(EJBUtils.java:746)
at com.ejb._BookServiceImpl_Serializable.writeObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1495)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
at com.sun.ejb.base.io.IOUtils.serializeObject(IOUtils.java:95)
... 49 more
Caused by: java.io.NotSerializableException: com.domain.Employee
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1183)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
at com.sun.ejb.EJBUtils.serializeObjectFields(EJBUtils.java:744)
... 64 more

I got this behavior with GlassFish 3.1.2 but i was able to run same example correctly with GlassFish 4. I am a bit double minded which server to use.

Thanks Jeanne Boyarsky and Paul Anilprem

Hi,

It is said in "EJB 3 in Action (2nd Edition) by "Debu Panda et.al" that if you want loosely couple and reliable functionality choose message driven bean instead of asynchronous bean. The reason for the tight coupling of asynchronous bean is given as "the client has direct reference" to asynchounous bean.

In general MDB looks more tightly coupled to me than Asynch Bean as if JNDI name of connection factory is changed we have to update both client and MDB whereas Asyn Bean doesn't look like tightly coupled.


Why is it that Asynchronous bean is considered tightly coupled ?

Hi Himai,

If an object is not serializable then it will give exception. The best way to test it is to try it by keeping a non-serializable object in your stateful session bean and let it be passivated and destroyed. I tried it once and i was able to see exception in the server log file.


So technically it is a must to make non-serializable object to 'null'