-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 prov
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 th
AM
To: Tomcat Users List
Subject: Re: JDBC driver of class '' for connect URL 'null' in Tomcat
5.5.12
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
-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.
> B
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 en
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 soo
-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
> deploym
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 upd
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 DBCP
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 depl
no I didn't...:-(
I was going off the globalresources config reference page, wher it lists
the attributes of a element as being:
**snip**
The valid attriutes for a element are as follows:
Attribute Description
auth
Specify whether the web Application code signs on to the corresponding
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
As far as I'm aware, there is no difference between a
element in context.xml and a element in a
... block. Well... other
than the need to use a to make it available to an
individual webapp. Did you try it and get a failure?
--David
Matthew Kerle wrote:
now that sounds good! the only t
-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)
-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 stru
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
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
-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
> ea
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 -
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 8/16/07
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, but
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 detai
now that sounds good! the only thing is I don't see how that maps to a
DataSource declaration, the element in
doesn't seem to allow the full range of
properties that you need to define a database connection, eg -
username/password/driverClassName/url etc...
Where would you define these?
Da
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
Hi Chris
my experience has been: one tomcat instance per dev/test/prod, & the
webapp on each instance always points to the same database (dev
tomcat->dev db, test tomcat -> test db etc), so the database connection
on a /single/ instance never changes. However when promoting code from
dev to t
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
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.
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 block of a context.xml file also makes it so
resources can come and g
-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
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
definition in a separate file called 'context.xml'. Explode your WAR,
put this in /META
Hi David
David Smith wrote:
My only editorial comment on the page is to NOT place your
or 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 the tomcat
docs have chang
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 config in your myapp/META-INF/context.xml or
conf/Catalina/localhost/myap
Sent: Thursday, August 16, 2007 10:27 AM
To: Tomcat Users List
Subject: Re: JDBC driver of class '' for connect URL 'null' in Tomcat
5.5.12
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
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
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 allow
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 manua
36 matches
Mail list logo
