So .RAR files are like .JAR, .WAR and .EAR (in that the jar program reads
them?). I must associate with the wrong type of people. They tell me .RAR
files (and some RAR tool) are used by hackers for 'zipping up' illegally
copied software.
Thanks for clearing that up.
Cheers
-----Original Message-----
From: Aaron Mulder [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 08, 2001 11:52 AM
To: jBoss Developer
Subject: RE: [jBoss-Dev] Where do .RARs go?
On Thu, 8 Feb 2001, Jay Walters wrote:
> I hate to ask a stupid question (but I want to anyways), so what's a RAR?
> And what extra tools will we need to use with JBoss to get to Minerva with
> these latest changes?
Glad you asked. I'll take the opportunity to over-answer, on
behalf of anyone who's not familiar with the J2EE Connector spec. :)
The J2EE Connector specification, included in J2EE 1.3, defines a
standard way for beans to connect to data sources (or EISs, as the spec
terms them) of all types (not just databases), such as TP systems, ERP
systems, etc. It's split into two parts. The app server has to implement
one part, and the EIS vendor has to implement the other (the vendor
implementation is known as a Resource Adapter).
So basically what this means is, you should be able to deploy a
bean that uses an Oracle connection and a PeopleSoft connection, and the
app server can manage security and transactions and pooling and stuff for
both types of connections in a standard way. You bean still needs to
know the difference, because it's unlikely that PeopleSoft would use a
javax.sql.DataSource, but from the app server's point of view, they're all
just "connections."
Now, the app server part of the API is implemented within the
server - nothing new there. But the vendor implementations are packaged
into a standard J2EE JAR-based format with deployment descriptors, etc.
This is a .RAR file (Resource adapter ARchive).
This will probably eventually work much like an EJB JAR. You'll
get an Oracle .RAR with an Oracle deployment descriptor, use EJX to create
a JBoss-specific deployment descriptor describing all the pools you want
to set up and the connection and security parameters for each, and dump
the .RAR into dist/deploy and voila! your pools will be started. That
part isn't implemented yet, so currently you have to put all the JBoss
configuration in jboss.jcml and then use the JMX web interface (or
whatever) to tell the "RARDeployer" service to deploy the .RAR at a URL
you provide. I think Toby's working on the further automation and
deployment support.
But, back to Minerva. JBoss has an interface for the app-server
part of the spec, allowing for pluggable implementations. Minerva has an
implementation, and the glue code for JBoss. That part is taken care of
in the MBeans with code="org.jboss.resource.ConnectionManagerFactoryLoader"
in jboss.jcml. There are two, one for LocalTransactions, and one for JTA
transactions. The former provides native support for JDBC 1/2 connections
so you don't need the Minerva "XA wrappers". The latter provides native
support for JDBC XA connections. And, of course, they both support other
resource adapter types besides databases. :)
Now, the only problem left is that most of the database products
that we know and love don't provide resource adapters (.RARs) yet. So
Minerva includes .RARs as well, for both types of DB connections (and
these .RARs are for DBs only!). So if you favorite DB doesn't have a
.RAR, just load the Minerva .RAR with the JDBC URL or XADataSource
implementation and it's loaded as a resource adapter.
So, now it appears that the current JBoss connection pool loaders
are obsolete: if the new spec-compliant way to access data is via J2EE
Connectors, and we have a Connector implementation for databases, why
would you want to use XADataSourceLoader instead? But rather than
removing it, for backward compatibility, we can just make
XADataSourceLoader and JDBCDataSourceLoader do all their work via
Connectors under the covers.
Which brings me to the question in my message. Since RARs can be
deployed into a server like JARs and WARs, it seems like they ought to go
in dist/deploy. But if we update the xxxDataSourceLoader classes to
behave as I just outlined, they will depend on the Minerva .RARs being
available. And so dist/deploy isn't necessarily the best place for those.
Better?
Aaron
P.S. There are no stupid questions... only stupid answers.
