[ROO-311] roo does not create jndi reference in context.xml for jndi lookup objects Created: 25/Oct/09  Updated: 18/Mar/14  Resolved: 27/Oct/09

Status: Closed
Project: Spring Roo
Component/s: PERSISTENCE, WEB MVC
Affects Version/s: 1.0.0.RC2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Matt Young Assignee: Stefan Schmidt
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all



 Description   

when building a web application with roo, jndi references in the ${webapp}/META-INF/context.xml are not created even if jpa is set up with a jndi datasource.

Steps to reproduce:
(in roo)
1) project --topLevelPackage com.example.test
2) persistence setup --provider HIBERNATE --database POSTGRESQL --jndiDataSource java:comp/env/jdbc/testDataSource
3) entity --name Ent1
4) field string name
5) controller all --package com.example.test

(in maven)
6) mvn clean install -Dmaven.test.skip=true

7) configure tomcat with the proper jndi config to match the database drivers and credentials of the jdbc/testDataSource
8) copy resulting war file from step 6 to the tomcat/webapps dir
9) start tomcat

expected behavior is that tomcat should start without errors. actual behavior is that tomcat complains about the jndi name not being bound.
"nested exception is javax.naming.NameNotFoundException: Name xxxxxxxx is not bound in this Context"

A simple fix is to copy the following text into the webapp/META-INF/context.xml file:
<Context path="/test"
debug="5"
reloadable="true" crossContext="true" privileged="true">

<!-- Link to the user database we will get roles from -->
<ResourceLink name="jdbc/testDataSource" global="jdbc/testDataSource"
type="javax.sql.DataSource"/>

</Context>

repeat steps 6 thru 9 and you will see that tomcat no longer complains about the datasource. If the above file is simply created as part of the scaffolding, this issue can be completely avoided.



 Comments   
Comment by Stefan Schmidt [ 26/Oct/09 ]

Hi Matt,

When I implemented the support for JNDI through the persistence setup command I actually tried it out with Tomcat too. The trick is indeed to setup a ResourceLink.

However, this is a Tomcat-specific setting and would not make any sense in other containers. Now, my assumption was that if you use a JNDI resource you would have that pre-configured.

I think that the Roo documentation could certainly provide a pointer for the Tomcat specific configuration but since Roo is not aware to which container the application will be deployed to it should not provide this container-specific context.xml file. Otherwise, we would see plenty more tickets which as for Jetty, WebLogic, WebSphere, etc container 'auto-configuration'.

Hope this makes sense.

-Stefan

Comment by Matt Young [ 27/Oct/09 ]

your response does make sense, however, the resource link would be ignored by all other containers would it not? Spring's own app server is based on tomcat. It would therefore make sense (at least to me) to add this benign addition to the roo scaffolding.

Comment by Stefan Schmidt [ 27/Oct/09 ]

Hi Matt,

I discussed this with Ben Alex and we both feel that the actual configuration of JNDI resources in the container of choice should be up to the developer / systems engineer. We don't see that much demand in JNDI on the Tomcat side anyway since most Spring developers prefer the configuration of data sources and the like inside the application rather than global container-supplied resources. And if you do want to use JNDI Roo allows you to do just that.

However going the step further and taking care of configuring JNDI resources in your container goes beyond of what we think is appropriate for Roo. Again, it would be quite unfair to configure everything for Tomcat and then disregard requests to do the same for other Web / App containers out there. Also, most likely the systems engineer would know much better how to configure the actual resource in your container compared to a generic solution chosen by Roo.

Your argument that other containers would simply ignore the Tomcat specific configuration artifact is valid, however we think the developer would get confused by a number of configuration artifacts in his application (for Tomcat, Jetty, JBoss, Glassfish, WebLogic, WebSphere, etc) which are actually not used / ignored. I think this would lead to more confusion than actual value in the long term.

I think what we should definitely do is to have a reference in the Roo documentation to the Tomcat configuration or even a small configuration sample.

So, unfortunately, we will have to 'push back' for this request since we feel it is out of scope for Roo to take care of configuring containers for you. I will therefore go ahead and close this ticket.

Regards,
Stefan

Comment by Greg Dicovitsky [ 18/Mar/14 ]

For what it's worth, I found this post to be quite useful. To round out what I had to do: I did the equivalent in ROO, I updated the context.xml, as above, and I placed

<configuration>
<webResources>
<resource>
<directory>${project.basedir}/src/main/resources</directory>
</resource>
</webResources>
</configuration>

in it, (yes, I decided to put context.xml in the STS resources directory...)

In addition, I had to add the following to the web.xml:

<resource-ref>
<description>postgreSQL Datasource example</description>
<res-ref-name>jdbc/testDb</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

People use JNDI in Tomcat, it allows developers to develop solutions where ease of deployment is of importance. Some say this is not best practice, but it makes for an efficient deployment process. (Edit the server.xml, load the .WAR, and go...)

Generated at Tue Oct 22 21:34:10 UTC 2019 using Jira 7.13.8#713008-sha1:1606a5c1e7006e1ab135aac81f7a9566b2dbc3a6.