Application Scoped datasources

[matanderson]

I am looking for a way to setup application scoped datasources within JBoss (4.2.3 or 5).

I have a situation where we have multiple home grown applications on a single JBoss install. Each application uses a datasource that may point do a separate server or the same server with different database permissions.

How can I prevent application X from using application Y's datasource?

I have found this concept in other java app servers. Weblogic uses something called the JDBC Module, where you have an *-jdbc.xml file that you place inside the ear make a small change to the weblogic-application.xml file and the datasource is now only limited to that one application. Is this possible on JBoss?

[peterj]

As far as I know, once the datasource is deployed and its name show up in the JNDI tree, any app can connect to the database.

[henk53]

"matanderson" wrote:
I am looking for a way to setup application scoped datasources within JBoss (4.2.3 or 5).[...] Is this possible on JBoss?

I think so, put your database-ds.xml in your ear at the top level, and define a reference to it in yourear/META-INF/jboss-app.xml:

<jboss-app>
 <module>
 <service>database-ds.xml</service>
 </module>
</jboss-app>

At least now its defined by your individual app. Jboss AS offers a mechanism to prevent classes being visible to other applications. This is called scoped class loading and works by defining a class loader repository. Maybe a similar mechanism (or perhaps even that exact mechanism) could be used to prevent the datasource from being visible to other apps.

I'm not the greatest Jboss expert, but maybe this give you some pointers and hopefully a real expert will give some better advice.

[matanderson]

Thanks henk53 - this is the sort of idea I was looking for. I'll see what I can figure out from this.

[matanderson]

I did what you suggested - and It still added the datasource on the global jndi tree.

In this case, i put my test datasource in the META-INF directory.

<jboss-app>
 <module>
 <service>META-INF/datasource1-ds.xml</service>
 </module>
</jboss-app>

When the application is deployed, I see:
INFO [ConnectionFactoryBindingService] Unbound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=datasource1' from JNDI name 'java:datasource1'
on the console.

A second applications (DBTester) can read the datasoure by issuing a

INFO [ConnectionFactoryBindingService] Unbound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=datasource1' from JNDI name 'java:datasource1'

Thanks for the suggestion, other ideas?

[jaikiran]

As Peter said, even if you package the datasource within your app, the datasource will finally be bound to a JNDI tree which can be accessible by other applications deployed on the same server instance.

[matanderson]

So it seems not possible to true application scoped datasources at this time.

I have a few followup questions.
1) How are others working with this issue? Do you trust your developers to not comb the jndi tree and look for datasources? Or do you just spawn a new jboss install for each application?

2) To me, this sounds like something JBoss could benefit from. How do I go about a feature enhancement to get something like this in? Sadly, I am not much of a coder, more of a system admin type person so I am of very little help when it comes to enhancements.

thanks for the discussion.

[peterj]

1) By restricting who has access to the production server (only the sysadmin is allowed to deploy apps to production) and by using code reviews to make sure that no developer write a datasource fishing app. For really secure environments, an app server instance per app is also used.

2) Enter a JIRA issue at http://jira.jboss.org/. You can use your forum account and password to log into JIRA.

[henk53]

"PeterJ" wrote:
1) By restricting who has access to the production server (only the sysadmin is allowed to deploy apps to production) and by using code reviews to make sure that no developer write a datasource fishing app. For really secure environments, an app server instance per app is also used.

Those are indeed the two most commonly used methods. I don't think that Java EE was really designed for a kind of 'shared hosting' scenario where applications that are potentially hostile to each other should be protected. The app server is not exactly a replacement for a fully multitasking protected/supervisor mode OS.

By using an app server per app you're basically piggy backing on the process security model of your operating system. There are some variants here. In the most basic setup you run every app server on the same account. Theoretically, apps could still mess with other apps via the file system, although they can't access each other's address space directly. So, the next level is running each app server using different user accounts for each.

Another option that's gaining in popularity lately is running an app server per OS instance on a hypervisor (XEN, VMWare, etc). This provides the maximum isolation possible on a single piece of hardware. It has certain other management advantages too, like separating ports being used, dedicating memory, dedicating cores, etc.