steven peh

Greenhorn
+ Follow
since Sep 25, 2002
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 steven peh

The problem with EJB (or any J2EE) tutorials is that at one point or another, you will have to deal with the deployment to the container. This unfortunately is quite container specific. Sometimes, container specific jargon is hard (but not necessarily impossible) to avoid.

Also, to pickup EJBs there are other Java technologies involve, i.e. JNDI, RMI, etc. As such references to these technologies are hard to avoid.

Cheers
Actually last time we did this sort of thing on tomcat, we had problems as well (dont remember the specific exception). But we found out that the dll have to be placed somewhere in tomcat's folders. When running as standalone as long as the dll is in whatever folder your java.library.path System property (when you use the java command) is set to you're all set (in windows you can also dump it in the system32 folder), on an appserver its very different, you have to make sure the dll is placed in whatever is configured as the app server's java.library.path , since you are running within the app servers VM.

Cheers
19 years ago
alfred,

EJBs are not your typical java inheritance objects. The app server are not performing polymorphism on the remote interface to the ejb object implementation. In fact as you stated, the ejb does not implement the remote interface, so they are in fact not related from an inheritance point of view.

Now, i dont know if its in the J2EE spec, but most J2EE App Servers will inspect your EJB during deploy time and enforce the rule that all the methods in your remote interface are implemented in your ejb class (and, as some one pointed out, make sure your dont throw RemoteExceptions). So during runtime, the J2EE App server will match the methods being called on the remote interface to the ejb. How it does this, I wouldnt know, there are many ways, one quick and dirty way would probably be using introspection.

Cheers
Its seems to a lot of ppl are confused and seem to think that BMP means EJB + handwritten SQLs. It does not.

BMP just means EJB + manual persistence, whether i handwrite the SQL or use an OR Mapping tool (hibernate, ibatis, custom made, etc). If you use hibernate from your EJB, then you still get CMT provided by the app server plus the nifty OR Map provided by hibernate, so its a win win.

Here's where we typically apply the DAO pattern. So if one day you feel like switching from hibernate to handwritten SQLs or some other OR solution, just implement a new DAO to wrap that and plug it in. Your EJBs working on the DAO interface wont even know you switched implementation and the container could care less, it calls your EJBs with whatever txn attribute you declared and commit/rollback/resume/etc the txn after your ejb method completes.

Cheers.
19 years ago
Sounds like you need to create a multi-threaded server, where the server spawns a new thread passing the socket it accepted to the new thread.
Coding a multi-threaded server is fairly simple depending on what your needs are. If your operations are exclusive and independant of one another (i.e. you applets are sending table updates to the server and is not dependant on the operation of other applets), then it should be pretty straightforward, if not then it'll require more work to synchronize the threads.