Building and deploying J2EE apps ? Now there is a solution for production root cause analysis.

Question

Is your organization building and deploying J2EE apps? If so, Halo
can help solve one of the toughest issues facing enterprises today:
Finding the root cause of software faults.
"Halo monitors, pinpoints, reports on and provides a source-code level
root cause of software faults in deployed J2EE apps. Halo is unique
because it's the only technology that can give you a root cause
diagnosis in a fully deployed, live production application. Halo has
such low performance overhead that customers deploy their final,
production versions of their applications with Halo enabled.
Used with Web Application Servers like WebLogic, Halo helps ensure
that deployed code is reliable and able to be quickly fixed if
problems turn up. Most important, because Halo is an "always on"
technology, you get all the information you need to rapidly solve a
problem on the first fault. Problem replication and bug reports are
obsolete with Halo
"Halo has a unique ability to provide a root cause diagonosis and
understanding
of software problems in production systems, without needing to
replicate the
issue.
Test on WebLogic proved that Halo runs with extremely low overhead and
is suitable for use in deployed production systems"
Andrew Sliwkowski, Software Engineer
BEA Systems, Inc.
The key is Halo's high performance, low overhead TraceBack
instrumentation technology. Based on technology out of MIT and proven
in the field, TraceBack enables you to instrument JARs, EARs and WARs
within minutes, without touching source code.
Halo is useful throughout the entire application life cycle, from
development through test, beta and deployment.
If you have interest in learning more visit our website at
www.incer.com or email me directly at [email protected] (Rick Martin)

Answer 1

I have two questions. We have just started developing apps using jdev9i, 9iAS v2 and are new to the j2ee environment so my questions may be very easy ones.
Question 1: We have set up Oracle pooling connection to our databases. We have a development, test and production database. When I deploy my application, it includes the connections. This is preventing me from moving the EAR files from dev to test to prod without modification and re deploying to my EAR file. Is there a way or a place that I can put my database connections that will not be included in my EAR files and the application still find them?datasources.xml is where the info regradings connection to databases is licated. If you're using 9iAS
you can use EM to create datasource entry at the global level. In OC4J standalone you could use admin.jar
or edit the file. Check out the standalone user's guide at http://otn.oracle.com/tech/java/oc4j/pdf/oc4j_so_usersguide_r2.pdf.
Also, you will othe OC4J docs on OTN.
Question 2: I have a stand alone oc4j set up for our developers to use while testing their applications. The applications include libraries supplied in jdev such as xml parser v2. I do not want to deploy those lib files with the app because I will have to redeploy all my apps if I upgrade jdev. I just want to be able to upgrade the libraries, test the apps and not have to redeploy everything. I can do this by coping the jdev lib to 9iAS but I can't seem to find the right place to put the lib for the stand alone oc4j instance. You can use the library tag within application.xml for server wide availability. Check out the article
http://otn.oracle.com/oramag/oracle/02-sep/o52oc4j_2.html specifically class loading in OC4J section
Any help would be greatly appreciated. Thanks in advance.