Chapter 4 - O'Reilly: TravelAgentRemote Not Bound

[ezanih]

I am doing the same Exercise 4 of O'Reilly's EJB3.0 with Eclipse Europa, OracleXE and JBoss 4.2.2GA and I have deployed titan.jar successfully but I am getting errors at the client end.

I have gone through all 8 pages of this forum category and found many other posters facing the same problem but no proper solutions were given.

I have tried all the solutions on all 8 pages including renaming to :-

lookup("TravelAgentRemote") from lookup("TravelAgentBean/remote")

and creating the jboss.xml

and so on and so on but I'm still getting a client side error. It's still giving me the :-

"TravelAgentRemote not bound" error.


Please help. Is it an error in the book since so many other posters are facing exactly the same error as me with the same coding as mine?

[jwenting]

Exercise 4 what?
The sample program on page 58 should work correctly if you set up the JNDI lookup as detailed on page 59.

No jboss.xml is needed.

Mind I did set up my deployment a bit differently, having IntelliJ create an ear file which includes the Oracle driver jars and referencing those from the EJB jar.
When not doing this I got a ClassNotFoundException on the driver on deploying the entitybeans, possibly because of the settings I use in the persistence unit (need to experiment with that, I may have inadvertently caused it to create its own connections on top of polling JBoss for a DataSource).

[ezanih]

Ok guys! Yahoo! It's finally working! The book does have some errors but here are the differences between my (now) working code and the book chapter example.

Book -
---------
Context jndiContext = getInitialContext( );
Object ref = jndiContext.lookup("TravelAgentBean/remote");
TravelAgentRemote dao = (TravelAgentRemote)PortableRemoteObject.narrow(ref,TravelAgentRemote.class);

Mine -
-------
//Context jndiContext = getInitialContext( );
Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
env.put(Context.PROVIDER_URL, "jnp://localhost:1099");
env.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
InitialContext jndiContext = new InitialContext(env); Object ref = jndiContext.lookup("TravelAgentBean/remote");
TravelAgentRemote dao = (TravelAgentRemote)PortableRemoteObject.narrow(ref,TravelAgentRemote.class);

And since I'm using OracleXE, I have a different persistence.xml file and also I use oracle-ds.xml -

persistence.xml -
------------------
<?xml version="1.0" encoding="UTF-8"?>

<persistence-unit name="titan">
<jta-data-source>java:/OracleXE1_DS</jta-data-source>




</persistence-unit>



oracle-ds.xml -
----------------

<local-tx-datasource>
<jndi-name>OracleXE1_DS</jndi-name>
<connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url>
<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
<user-name>SYSTEM</user-name>
Swordfish1
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>

<type-mapping>Oracle10g</type-mapping>

</local-tx-datasource>


One thing I have to tell you is : I don't think its wise to be exposing user names and passwords in plain text in one of your config files for the world to view!!!

[ezanih]

Sorry, the persistence.xml file should read like so:-

<?xml version="1.0" encoding="UTF-8"?>

<persistence-unit name="titan">
<jta-data-source>java:/OracleXE1_DS</jta-data-source>




</persistence-unit>

[ezanih]

Dang! This editor is definitely missing out the bit. This is my final try so here goes !

<xml version="1.0" encoding="UTF-8"?
persistence>
persistence-unit name="titan">
jta-data-source>java:/OracleXE1_DS</jta-data-source>
properties>
property name="hibernate.hbm2ddl.auto" value="create-drop"/>
property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect"/>
/properties>
persistence-unit>
/persistence>

[jwenting]

"One thing I have to tell you is : I don't think its wise to be exposing user names and passwords in plain text in one of your config files for the world to view!!!"

Well, it has to be exposed somewhere, how else is the server going to know about it?
And it's really no problem whatsoever. Anyone who has access to the machine in a way that lets them read that file can get into the database anyway...
He's either authorised or a good enough cracker to get around whatever security you've thrown up.

As to the error. Everything seems alright from what I can see here except that the slash in the name of the jta-data-source as defined in the persistence unit should not be there (which likely causes the EJB to fail to deploy properly).
Are you sure the EJB is deployed correctly? Check the server console for errors and exceptions.

If it is, check the JMX console for the exact JNDI name of the EJB.
Open the JMX console, find the "JNDIView" service, and under there use the "list" function.
the EJB should be near the bottom of the page.
The datasource should be somewhere near there as well.

[ezanih]

Thanks, jwenting!

But bear in mind JBoss resides on the application server so you should not be able to access the database server from there. As for passwords (AND user names for that matter) being in plain text sitting in configuration files, I think this is not the way especially since JE22 are serving among the largest Fortune companies.

It doesn't seem to be the slash. It was still there when my EJB 3.0 app "suddenly" worked. I still don't know the reason why but I took out a lot of unnecessary stuff such as ejb-jar .xml, jboss.xml files but the sample still cannot run without altering the original book code of GetInitialContext() to using the Properties approach so I think there may be an error in the book.

[jwenting]

well, it needs to be stored somewhere in a way that the server can read...
It can't store it in the database as it would need to have it to access it, a clear paradox.
If it were to store it in encrypted form it would need to store the decryption key somewhere where it could be read.

Server security is always more about physical security and access control than it is about encrypting information.

If the bad guys can't get to the machine (physically or through a remote login) they can't access the information on it.
So if your server room is locked and the servers behind a DMZ, with only trusted persons in your company having shell accounts, there is really no problem.

Those trusted people are likely the same people who are also trusted with database accounts (and probably a smaller set than those who have database accounts).

Of course you should ideally not have your application servers use database accounts that can do anything more than strictly needed to do their work.
So no system accounts are to be used by application servers, only user accounts with maybe limited DBA functionality (create table, alter table, etc.) within their own schemas.

[jaikiran]

"ezanih" wrote:

One thing I have to tell you is : I don't think its wise to be exposing user names and passwords in plain text in one of your config files for the world to view!!!

See this http://wiki.jboss.org/wiki/Wiki.jsp?page=EncryptingDataSourcePasswords

Dang! This editor is definitely missing out the bit.

While posting xml content or logs or code, remember to wrap it in a code block using the Code button in the message editor window. Use the Preview button to make sure your post is correctly formatted.

[ezanih]

Ok, I guess this is new knowledge to me. Probably a hackers motive is to just access the application server and open the hibernate.properties or hibernate.cfg.xml or -ds.xml. I'm not a hacker by the way!

It's the same with Microsoft's ASP. This server-script is plain text and you still have to connect to the database at one point in code, giving the user name and password in plain text.