-
1. Re: DataSources Don't Belong in java:/ Space
darranl Jan 23, 2004 12:23 PM (in response to acg6764)So basically you have been caught out with using the proprietary features of a commercial application server.
Have you considered using Cactus for unit testing? -
2. Re: DataSources Don't Belong in java:/ Space
darranl Jan 23, 2004 12:25 PM (in response to acg6764)Sorry forgot the link :-
http://jakarta.apache.org/cactus/index.html -
3. Re: DataSources Don't Belong in java:/ Space
acg6764 Jan 23, 2004 12:42 PM (in response to acg6764)Proprietary? How is using unit tests that talk to a database proprietary? Like I mentioned previously, every other application server we've tried works alright other than Sun ONE. Sun ONE may work too with a custom external JVM. JBoss is the only appserver I know of that states that this will not work. I would like to emphasize again that we currently support 4 application servers and are in no way using any proprietary extensions. JNDI lookups to a connection pool aren't exactly uncommon in the J2EE realm.
Cactus, although a worthwhile product, is geared mainly towards integration tests in my opinion. If my EJBs delegate the database interactions to other classes, then should I not write unit tests for all classes involved?
I do appreciate your feedback but it seems that rather than addressing the issue, you're redirecting the argument to our application design by calling it flawed. -
4. Re: DataSources Don't Belong in java:/ Space
jcprout Jan 23, 2004 2:54 PM (in response to acg6764)From the J2EE 1.3 spec, a client should have access to java: in the JNDI namespace. Section 9.4:
As with all J2EE components, application clients use JNDI to look up enterprise beans, to get access to resource managers, to reference configurable parameters set at deployment time, etc. Application clients use the java: JNDI namespace to access these items.
A connection pool should be available through this mechanism, but I don't think JBoss yet supports this -
5. Re: DataSources Don't Belong in java:/ Space
acg6764 Jan 23, 2004 3:16 PM (in response to acg6764)jcprout:
That is very interesting information. In the threads I had found so far by searching this forum, the claim was that the "java:" prefix implies (atleast as far as JBoss is concerned), an in-jvm namespace. And my understanding was that that was the reason for not allowing access to resources such as connection pools. It appeared as though the intent by JBoss developers was not to modify this behavior now or in the future. That is why I was proposing moving DataSources out of this namespace.
However, with the information you presented in light, I hope JBoss will support java: namespace lookups in the near future (4.0?). I'm just really surprised that even after the myriads of posts concerning this topic in these forums, this feature has not been implemented yet.
Does anyone in the development community have any comments on this topic? -
6. Re: DataSources Don't Belong in java:/ Space
jonlee Jan 23, 2004 8:32 PM (in response to acg6764)The distinction made, as I understand it, is that the "java:/" is not available external to the JVM in which the JNDI schema is created, as opposed to "java:". That is; "java:/myObject" is not the same as "java:myObject". And there are security reasons for which you may not want objects accessible from an external JVM.
The issue with regards to access to the datasource from an external JVM in JBoss is ultimately a physical restriction with connections rather than an arbitrary choice by the JBoss developers. The DataSource is just a connection factory.
The physical connection is manifested between the JVM in which the DataSource is instantiated, and the actual datasource (database). Passing the connection handle (Connection) to an external environment would be of little use. Now the JBoss developers might produce a proxy implementation for connections manufactured from the DataSource but the cost benefits of a connection pool are diminished by the cost of establishing a separate connection between the external JVM and the JVM in which the real datasource connection resides.
Secondly, were JBoss developers to develop a proxy implementation for the connection pool, there is no security restriction inherent in the Connection manufacture from a DataSource such that exposing the DataSource to external access opens the datasource to possible malicious attack from unauthorised parties.
MHO.