Andreas Schaefer

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

Recent posts by Andreas Schaefer

Again and again and again

someone predicts the death of Java or here JEE. Like COBOL Java will stick around much longer than expected and so I am not worried. As long as there is not a technology available that can compete with JEE then JEE will not die. Sorry, but Spring and Hibernate is not going to replace JEE except for some plain and stupid web applications.

I am not happy with EJB3 but not because of the complexity. Writing Enterprise applications is complex because the business is and not because of the software. Gimme a customer than knows upfront what he wants and that JEE project will process smooth like glass. But unfortunately that is never the case and we have to deal with all the changes, inconsitencies and contradictions.
What I am missing from JEE and EJB3 is that again the design comitee was not able to come up with issues that would common problems like refeshing JDBC connections when DB bounces, stopping a MDB when a permanent failure trashed the application server through resending messages or give the EJB feedback about deployment so that the application can react on deployment/undeployment/redployment without using stupid hacks like Servlets to handle such things.

Unfortunately the comitee was more concerned with ease of use, as if that would apply in EJB development, than with solving real issues. Annotations will become a nightmare even when people now are excited about the alleged simplicity.

-Andy
First you should have posted the exception you get on the client.

You cannot use a Local Interface on the client side because it is only available to an EJB within its application otherwise a local interface would have made sense.
Just make sure that you use a Remote Interface and look that one up from the client.

-Andy

(Sorry Andy, had to do a small little clean up on aisle 5. Lunch on Friday talk to Matt - Mark)
[ July 20, 2006: Message edited by: Mark Spritzler ]
Yes, that is perfectly fine. You do not need to postpone the creation of your processing class to the ejbCreate() method but can do this even in the constructor. Only if you need any EJB resources like the MDB context etc. you need to place that code in the ejbCreate() method.

-Andy
I am not a Weblogic expert but I would think that you cannot enforce an ejb passivation because this is up to the app server and is only done when the need arise due to resource constraints.

-Andy
No, only one will be blocked temporarly and the reason is because static methods are locking on the Class (C.class). Actually it is completely irrelevant that you have two instances because T1(C,f1) and T2(C,f2) would lead to the same problem.
I cannot help you with the mapping but regarding the error I can help you. In case you want to see the exception then you need to add the pPstgreSQL classes to the client as well which you can do by just adding the JDBC archive of postgres into the clients classpath.

-Andy
Unfortunately there is no LIKE for interger. What you could do is to transform it into a string and then apply a LIKE on it but I am not sure how this would be done in EJBQL (I only would know it for Oracle).

-Andy
I am not quite sure what Jeroen means with standard because there is no standard. It strucks me that there is a need to use any custom stubs when there is a proven way to deal without using proxies. Stubs are not only a pain because they need to bundled with the client but quite often they are not made available until the application is deployed (see Sun's app server).

I agree with Jeroen that one should learn the basics which here means that when you deserialize objects that you need to make no only the interfaces available but also the implementing class(es).

-Andy
The stub the lookup returns will of a class that implements the remote interface but be of that type. A way to fix your ServiceLocator is to hand down the desired interface:


But your original code:

is actually referencing the remote interface (MYHome) and so you would have to provide the class anyhow so why not just using it for the narrow (you use it just left of it for the upcast.

-Andy
Just as a tip try using JBoss and you are never worrying about stubs anymore.

-Andy
Hi Yuan

I do not quite understand the anwser but I think they are saying that all classes of a EJB3 archives is loaded by the same class loader.

Again I would need to see your achive layout to know what is going on.

-Andy
Check out the log file (server.log) and see if there was an issue during the setup of the DataSource.

-Andy
Hi Yuan

I am not 100% shure but JBoss needs to deploy each EJB3 file in its own classloader otherwise you would not be able to redeploy and that works here. Because I do not know how you deployed the application it is hard to figure out how your code works.
In general you would not get a ClassNotFoundException but a NoClassDefFoundError because your EJB2 has the Calculator referenced in its code and if it would be missing then it would be a linkage error. So somehow the Calculator class must be made available to EJB2.

-Andy
Just a side note that JBoss does not have any stubs because it uses proxies and the stubs are included into the JBoss client JARs.

-Andy
Your code strucks me as quite odd. The narrow() needs the interface it needs to narrow to and for sure the obj.getClass() does not deliver the interface.
For example in JBoss that code would have failed too because the remote interface is of type ProxyXXX which is a generated class.

I would suggest that you try to read the spec. to understand what is required when you want to use any shortcuts otherwise it may blow up on you when you move to a newer version, different JDK or different app. server.

-Andy