Hi chris
Christopher Schultz wrote:
IIRC, JBoss used to use Tomcat as its servlet container. Maybe that's no
longer the case.
it still is. after my post I had a read through the jboss docs, and
apparently it uses embedded tomcat internally as a web container, then
the jboss code does all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matt,
Matthew Kerle wrote:
after my post I had a read through the jboss docs, and
apparently it uses embedded tomcat internally as a web container, then
the jboss code does all the extra j2ee app server goodness.
To be more precise, Tomcat
Thanks for all your advice,
Problem sorted now.
I moved the ojdbc14.jar into common/lib only, and set-up a context in the
appname/META-INF/contex.xml. Tomcat still
wouldn't start after renaming ResourceParams to Resource even after I had
validated the xml with an xml validator
tool. In the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matt,
Matthew Kerle wrote:
I'm changing jobs soon and the new company uses JBoss (:-), so
it may take a while to convince them how good tomcat is ;-p!
IIRC, JBoss used to use Tomcat as its servlet container. Maybe that's no
longer the case.
But
but an XML validator tool will only validate whether the XML is malformed or
not, right? Not whether it touches parameters that exist in Tomcat. Right?
Glad to hear you got it working.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, August 17, 2007 7:56
I'm upgrading from tomcat 4.1.24 to tomcat 5.5.12 on WinXP. I have three
applications that are deployed from this
server, two of which work fine with tomcat 5.5.12, however the third which uses
an oracle 9i database gives me the
following error javax.servlet.ServletException: Cannot create
hmm, you have an interesting problem!
first thing I'd say is use this opportunity to upgrade to the
ojdbc14.jar, which is the latest oracle jdbc driver and allows lots of
nice enhancements.
second, I'm assuming that since the error is a servlet exception, that
there's some servlet code
check this
http://evolutionnext.com/blog/2005/10/13/1129259088959.html
On 8/16/07, Matthew Kerle [EMAIL PROTECTED] wrote:
hmm, you have an interesting problem!
first thing I'd say is use this opportunity to upgrade to the
ojdbc14.jar, which is the latest oracle jdbc driver and allows lots
Thanks for your advice so far
I've upgraded to the latest Oracle ojdbc14.jar and placed it the
myapp\WEB-INF\lib folder, I also tried it the
Tomcat\common\lib for for good measure but still got the same results. I'll
continue to use ojdbc14.jar from now
though.
I've change the ResourceParams
why don't you use this jar? ojdbc14_g.jar
That's what I ended up upgrading to.
Let me know if you need it, Ian, and I'll send it to you offline.
Barry
And, you should put it in the common/lib folder.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday,
Hi Ian.
ojdbc14.jar needs to ONLY be in common/lib. It won't work in
myapp/WEB-INF/lib and won't work if you have the jar in both places.
Additionally you should take a look at the JDBC howto docs regarding
what your Resource... config in your myapp/META-INF/context.xml or
Hi David
David Smith wrote:
My only editorial comment on the page is to NOT place your
Resource.../ or Context .../ definition in server.xml as
recommended on the page. Place it in context.xml or myapp.xml as I
describe above.
Just quickly, I was wondering why you recommend this? I know
looks like your xml doc has an un-closed tag or similar, hate to suggest
this but maybe can you recheck your change to make sure this isn't the case?
I'd suggest going with David's suggestion, and put your context .../
definition in a separate file called 'context.xml'. Explode your WAR,
put
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matt,
Matthew Kerle wrote:
I never
understood why, and personally doing things that way is a serious pain
for me since it means I need to build a separate deployment descriptor
for dev, test prod, which means I need to know the prod database
In my experience, a resource is usually only relevant to one webapp.
There's no need to put it in server.xml as a GlobalNamingResource unless
you want that resource available in all your webapps. Moving the
resource to the Context block of a context.xml file also makes it so
resources can
On 8/16/07, Len Popp [EMAIL PROTECTED] wrote:
You're right that putting server-specific info in context.xml in the
.war is no good when the app could be installed on different servers.
Isn't that what build.properties files are for? :-)
--
Hassan Schroeder [EMAIL
How do you use a build.properties file to define a JNDI resource? Or
do you create JDBC connections a different way?
--
Len
On 8/16/07, Hassan Schroeder [EMAIL PROTECTED] wrote:
On 8/16/07, Len Popp [EMAIL PROTECTED] wrote:
You're right that putting server-specific info in context.xml in the
The reason is that server.xml is for the whole server, so when you
change something you have to restart the whole server rather than just
the one application.
You're right that putting server-specific info in context.xml in the
.war is no good when the app could be installed on different servers.
now that sounds good! the only thing is I don't see how that maps to a
DataSource declaration, the Resource element in
GlobalNamingResources doesn't seem to allow the full range of
properties that you need to define a database connection, eg -
username/password/driverClassName/url etc...
On 8/16/07, Len Popp [EMAIL PROTECTED] wrote:
How do you use a build.properties file to define a JNDI resource? Or
do you create JDBC connections a different way?
Not sure I understand the question -- we're talking about putting
a Resource element in META-INF/context.xml, right? So the details
I don't get it. Are you assuming that the programmer would put the
JDBC server info in a build.properties file that is used at compile
time? That doesn't work unless the programmer knows all the servers
the app will eventually be deployed on - which isn't always the case
for me.
--
Len
On
it's doable, some of my teammates use that method, but it's a pain in
the butt because you basically have to create 3 WARs per release (one
for each target). considering a struts/hibernate/spring/xFire
application is about 30mb in 3rd party jars, that's a lot of space. ok
HD space is cheap,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matt,
Matthew Kerle wrote:
Most of the sysadmin's I've worked with really don't like the idea of
having to rip open a war and update some weird config file just to do a
deploy. the alternative is I know all the passwords and build a war for
each
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Len,
Len Popp wrote:
How do you use a build.properties file to define a JNDI resource? Or
do you create JDBC connections a different way?
Search-and-replace, baby. That's how I have my configuration working.
- -chris
-BEGIN PGP SIGNATURE-
On 8/16/07, Christopher Schultz [EMAIL PROTECTED] wrote:
They're all crap solutions when nobody wants to do their job.
heh -- indeed.
And how about we add the it depends corollary -- they're all
crap solutions for /some/ specific environment(s) :-)
--
Hassan Schroeder
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matt,
I disagree with many of your assertions.
Matthew Kerle wrote:
it's doable, some of my teammates use that method, but it's a pain in
the butt because you basically have to create 3 WARs per release (one
for each target). considering a
On 8/16/07, Len Popp [EMAIL PROTECTED] wrote:
I don't get it. Are you assuming that the programmer would put the
JDBC server info in a build.properties file that is used at compile
time? That doesn't work unless the programmer knows all the servers
the app will eventually be deployed on -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Len,
Len Popp wrote:
I don't get it. Are you assuming that the programmer would put the
JDBC server info in a build.properties file that is used at compile
time?
Well, you have to get creative. For instance, all our devs (and
deployment folks)
As far as I'm aware, there is no difference between a Resource /
element in context.xml and a Resource / element in a
GlobalNamingResources.../GlobalNamingResources block. Well... other
than the need to use a ResourceLink .../ to make it available to an
individual webapp. Did you try
Hi Chris
I apologise for coming across a bit harsh there, don't mean to offend!
I'll take it a bit easier...;-p
Either of the methods you recommended looks good, the only trouble is
that the doco is a bit... terse on the subject of setting up a JNDI
datasource outside the war file, and it's
no I didn't...:-(
I was going off the globalresources config reference page, wher it lists
the attributes of a Resource element as being:
**snip**
The valid attriutes for a Resource element are as follows:
Attribute Description
auth
Specify whether the web Application code signs on to
I see. Some of the tomcat docs are probably out of date, depending on
someone pointing out the flaw or contributing updates.
Tomcat uses reflection to configure the pool using bean setter methods.
That makes the full set of attributes dependant on the implementation
used -- in this case
Hi Chris
It seems like you guys have a pretty good setup going, better than the
one at my (current) company anyway. I didn't realise that your
environment doesn't have dependencies on statically linked war files
like ours does. The developer makes a release and creates the three wars
for
much better, thank you! I think I'm gonna have to put aside some time
to brush up on tomcat 5.5/6 jndi datasourcing as I'm obviously out of date.
cheers!
David Smith wrote:
I see. Some of the tomcat docs are probably out of date, depending on
someone pointing out the flaw or contributing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matt,
Matthew Kerle wrote:
the doco is a bit... terse on the subject of setting up a JNDI
datasource outside the war file, and it's not as straightforward or easy
to find as compared to the method for placing the context.xml inside the
deployment
Hi Chris
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matt,
I agree the documentation is terse and/or missing. If you implement any
of these strategies, consider submitting an update to the documentation
to help others in the future.
will do. I'm changing jobs
36 matches
Mail list logo
