resource defined in web.xml has null attributes but server.xml is ok
When I set up a db resource in web.xml and create it, for some reasons it has null's in its attributes (such as username, url, driverClass, ..). But when I set up the same resource in server.xml, it works fine. >From the documentation it wasn't clear to me if both need to be set up the same way. i.e. I use . in server.xml or web.xml, and then create a reference to it using in web.xml. Is this the correct way of doing this and if so any ideas on why a resource defined in web.xml should have null attributes when i get the object? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resource defined in web.xml has null attributes but server.xml is ok
So - I cannot *not* define a resource at the server level (i.e. not touch the server.xml or any other server configuration file) and only define it in the app configuration files - i.e. web.xml ? It seems like thats what you are saying below - just want to be sure I understand clearly. Thanks On Tue, 09 Nov 2004 10:11:27 +1100, Peter Johnson <[EMAIL PROTECTED]> wrote: > Hi, > > You need both. You define the resource in the context of the app and > then link to the resource from the app. > > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-datasource-examples-howto.html > > PJ > > > > Nishant Deshpande wrote: > > >When I set up a db resource in web.xml and create it, for some reasons > >it has null's in its attributes (such as username, url, driverClass, > >..). > > > >But when I set up the same resource in server.xml, it works fine. > > > >From the documentation it wasn't clear to me if both need to be set up > >the same way. i.e. I use > > > > > > > > . > > > > > >in server.xml or web.xml, and then create a reference to it using > > in web.xml. > > > >Is this the correct way of doing this and if so any ideas on why a > >resource defined in web.xml should have null attributes when i get the > >object? > > > >Thanks > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resource defined in web.xml has null attributes but server.xml is ok
Ok got it. If I could read property I would have saved myself a lot of time. Just to emphasise for anyone else looking at this thread.. > a context (if not > DefaultContext) can be defined in the server.xml *or* > conf///.xml The OR is important - i was defining a context for the same webapp in server.xml *and* my context.xml. When I do this, the META-INF/context.xml file does not get read and copied to /conf/Catalina//.xml. Only the context in server.xml is read. Thanks for your help. On Tue, 09 Nov 2004 11:33:11 +1100, Peter Johnson <[EMAIL PROTECTED]> wrote: > Almost, you must define it in a context usually app specific rather than > DefaultContext. The bit that makes it almost is that a context (if not > DefaultContext) can be defined in the server.xml *or* > conf///.xml e.g. home>/conf/Catalina/localhost/test.xml > > If deploying as a WAR to Tomcat you would have > WEB-INF/web.xml *and* > META-INF/context.xml <--- app specific context definition > > PJ > > > > Nishant Deshpande wrote: > > >So - I cannot *not* define a resource at the server level (i.e. not > >touch the server.xml or any other server configuration file) and only > >define it in the app configuration files - i.e. web.xml ? > > > >It seems like thats what you are saying below - just want to be sure I > >understand clearly. > > > >Thanks > > > > > > > >On Tue, 09 Nov 2004 10:11:27 +1100, Peter Johnson <[EMAIL PROTECTED]> wrote: > > > > > >>Hi, > >> > >>You need both. You define the resource in the context of the app and > >>then link to the resource from the app. > >> > >>http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-datasource-examples-howto.html > >> > >>PJ > >> > >> > >> > >>Nishant Deshpande wrote: > >> > >> > >> > >>>When I set up a db resource in web.xml and create it, for some reasons > >>>it has null's in its attributes (such as username, url, driverClass, > >>>..). > >>> > >>>But when I set up the same resource in server.xml, it works fine. > >>> > >>> > >>> > >>>From the documentation it wasn't clear to me if both need to be set up > >> > >> > >>>the same way. i.e. I use > >>> > >>> > >>> > >>> . > >>> > >>> > >>>in server.xml or web.xml, and then create a reference to it using > >>> in web.xml. > >>> > >>>Is this the correct way of doing this and if so any ideas on why a > >>>resource defined in web.xml should have null attributes when i get the > >>>object? > >>> > >>>Thanks > >>> > >>>- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >>> > >>- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >> > > > >- > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: connection pooling
I've been dealing with similar issues recently. Basically your
reference in web.xml is not 'pointing' to the resource you defined in
server.xml for some reason, which is why if you examine the datasource
you get, you will see all the fields set to null (as indicated by the
error).
Try to create a context for your webapp in server.xml and put your
resource in there as a first step to debug.
If this doesn't work, check your server.xml is being read - i think
the log will tell you (?) and / or try with a simple server.xml to
eliminate any xml errors.
On Tue, 9 Nov 2004 14:25:41 +0100, Akacem Mohammed
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> I am stuck in the same Probleme as Erik. I did exactly what in the e-mails
> suggested is with no success.
> I am runing TC 5.0.28 und try to get a connection to an informix database.
> I got the following Error Message:
>
> org.apache.commons.dbcp.SQLNestedException: Cannot create JDBC driver of
> class '' for connect URL 'null'
>
> mycode :
>
> try {
> initCtx = new InitialContext();
> envCtx = (Context) initCtx.lookup("java:comp/env");
> ds = (DataSource) envCtx.lookup("jdbc/SteaDB");
> } catch (NamingException e) {
> // TODO Auto-generated catch block
>
> e.printStackTrace();
> }
> try {
> conn=ds.getConnection();
> } catch (SQLException e2) {
> // TODO Auto-generated catch block
> e2.printStackTrace();
> }
>
> My Configuration is as follow:
>
> web.xml :
>
>
> DB Connection to informix
> jdbc/SteaDB
> javax.sql.DataSource
> Container
>
>
> server.xml :
>
>
>
>
>
>
> factory
> org.apache.commons.dbcp.BasicDataSourceFactory
>
>
>
> maxWait
> 1
>
>
>
>
> username
> unknown
>
>
> password
> unknown
>
>
>
>
>driverClassName
>com.informix.jdbc.IfxDriver
>
>
>
> url
>
>
> jdbc:informix-sqli://s0062033.vt.bb.de:300056/coadb:informixserver=coadbzentral
>
>
>
>
> removeAbandoned
> true
>
>
> removeAbandonedTimeout
> 300
>
>
>
> logAbandoned
> true
>
>
>
>
>
> thanks for any hint
>
> Mohammed
>
> -Ursprüngliche Nachricht-
> Von: Steve Kirk [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 9. November 2004 01:40
> An: 'Eric Wulff'; 'Tomcat Users List'
> Betreff: RE: connection pooling
>
> Worth clarifyig what we are meaning by "DBCP". The DBCP I was referring to
> was the specific implementation of connection pooling that is part of
> Jakarta Commons:
> http://jakarta.apache.org/commons/dbcp/
>
> There are other pooling implementations which are alternatives to Commons
> DBCP.
>
> Some DB drivers included pooling support as-is. Others do not. For those
> that do not, you need to implement pooling by building code around the
> standard driver. You used to have to do this yourself, but now there is
> DBCP to take care of this for you. DBCP is a "wrapper" used around a
> non-pooling DB driver.
>
> So, hence my question, are you intending to use DBCP, or does your Informix
> driver include pooling?
>
> From the JNDI/JDBC guides it appears that you have the choice of using DBCP
> or not (although there is one aspect of the docs that seem slightly unclear
> on that, which I am going start another thread to clear up). The configs
> are similar. Personally I have only got the DBCP approach to work, hence my
> suggestion of using that, for which you need to include the factory
> parameter. What this does is basically tells TC to call DBCP rather than
> your database driver when making a connection - DBCP then calls your DB
> driver if and when it needs to.
>
> I think I'm right in saying that if you don't explcitly use DBCP, and your
> DB driver does not support pooling, you will end up with non-pooled
> connections. The webapp will still work but you will not have the
> advantages of pooling.
>
> In case it helps, here are my ResourceParams. Note that I have both
> "factory" and "driverClassName":
>
>
>
> factory
>
> org.apache.commons.dbcp.BasicDataSourceFactory
>
>
> driverClassName
> com.mysql.jdbc.Driver
>
>
> username
> me
>
>
> password
> secret
>
>
> url
> jdbc:mysql://localhost:3306/myDb
>
>
>
> > -Original Message-
>
http request sent to https port
I have https enabled on port 80. If i request 'http://localhost/', it comes back with some errenous http reply which my browser can't interpret (nor can wget). On other web sites, I see that my http request gets redirected to https, but seemingly on the same port. Anyone know how this is done? i.e. am I being redirected to a different port but its 'hidden' (i can redirect but can't hide the port), or being redirected to the same port but for https (this i don't know how to do..) i.e. to clarify: i type in 'http://somewebsite/login' and i go to 'https://somewebsite/login' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
invalidated session
I store a bunch of objects in my session. After the session timeout, I see the session getting invalidated (via my listener). Now I am expecting to see the finalizers from the objects in the session being called - I'm pretty sure I don't have any other references to them. I don't see the finalizers getting called. Am I missing something? Thanks Nishant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
persistence with sessions & distributable attribute
Hoping for some help from the tomcat experts on this list.
I want to ensure all objects stored in sessions are serializable.
I read that I can put the tag in my web.xml file to
'enforce' this.
But I don't see any enforcing happening. I assumed it would throw
exceptions at runtime when I did 'setAttribute("xxx",
SomeNonSerializableObject)'.
I have put 'distributable' in
web.xml: ... ...
I also have the following in server.xml:
Am I missing something? How is the serializability enforced?
Also another question: the serialization does not happen in the
directory i specify for Store above, rather it happens in the
$CATALINA_HOME/work/Catalina/* directories. Any ideas about this one?
Thanks,
Nishant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: persistence with sessions & distributable attribute
Apologies - I omitted the tomcat version: 5.0.28
On 8/16/05, Nishant Deshpande <[EMAIL PROTECTED]> wrote:
> Hoping for some help from the tomcat experts on this list.
>
> I want to ensure all objects stored in sessions are serializable.
>
> I read that I can put the tag in my web.xml file to
> 'enforce' this.
>
> But I don't see any enforcing happening. I assumed it would throw
> exceptions at runtime when I did 'setAttribute("xxx",
> SomeNonSerializableObject)'.
>
> I have put 'distributable' in
>
> web.xml: ... ...
>
> I also have the following in server.xml:
>
>
>
>reloadable="true" debug="1"/>
>pathname="/cv/data/tmp" debug="5" saveOnRestart="true"
> distributable="true">
> directory="/cv/data/tmp"
>debug="5"/>
>
>
>
>
>
> Am I missing something? How is the serializability enforced?
>
> Also another question: the serialization does not happen in the
> directory i specify for Store above, rather it happens in the
> $CATALINA_HOME/work/Catalina/* directories. Any ideas about this one?
>
> Thanks,
>
> Nishant
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: persistence with sessions & distributable attribute
Thanks for the input.
Any idea how I can *catch* errors during serialization? I am guessing
I will have to create my own PersistanceManager and override some
functions..
Has anyone done this (or any other method of doing this)?
On 8/17/05, Christoph Kutzinski <[EMAIL PROTECTED]> wrote:
> I didn't say that distributables don't have to implement
> java.io.Serializable. In fact they have to.
> I just had the impression (from your first post) that you thought by
> putting an non-serializable Attribute into a HashMap, the attribute
> would become serializable, too.
>
> Example:
> If you want to put a java.net.Socket into the session the session won't
> be distributable because Socket isn't Serializable.
> But if you put the Socket object into a java.util.HashMap (which
> implements Serializable) and put the map into the session, the session
> still wouldn't be distributable. This is because to serialize the
> session the HashMap and ALL its fields must be serialized. Because the
> Socket object is now part of the map, this won't work.
>
> Serializable is just a "marker" interface, i.e. the class just
> "declares" that is it serializable.
> You should read the Java Tutorial (somewhere in the JDK docs).
> There is explained what Serialization really means.
>
> Christoph
>
> Lintang JP wrote:
> > I'm referring to this document on :
> > http://www.onjava.com/pub/a/onjava/2004/04/14/clustering.html?page=2
> > The words "Serializable" here would mean for session replication, right ?
> > CMIIW.
> > On 8/17/05, Christoph Kutzinski <[EMAIL PROTECTED]> wrote:
> >
> >>Hi Nishant,
> >>
> >>where did you read that will *enforce* serializability?
> >>AFAIK "only" means that your sessions can be distributed
> >>to different tomcat nodes (i.e. a cluster). It doesn't enforce anything,
> >>you have to make sure that your session attributes are serializable by
> >>yourself.
> >>
> >>I've done this for my testing environment with a SessionListener:
> >>
> >>public class SessionListener implements HttpSessionListener,
> >>HttpSessionAttributeListener {
> >>
> >>private ObjectOutputStream stream = new ObjectOutputStream(new
> >>OutputStream() {
> >>public void write(int b) {}
> >>});
> >>
> >>public void attributeAdded(HttpSessionBindingEvent evt) {
> >>
> >>if (LOCAL_DEBUG) {
> >>// try to serialize attribute
> >>Object o = evt.getValue();
> >>synchronized (stream) {
> >>try {
> >>stream.writeObject(o);
> >>} catch (IOException e) {
> >>System.err.println(evt.getName() + " is not serializable: " +
> >>e.getMessage());
> >>e.printStackTrace();
> >>}
> >>}
> >>}
> >>}
> >>
> >>...
> >>}
> >>
> >>I disable LOCAL_DEBUG in the production environment, because trying to
> >>serialize every attribute is probably to expensive under heavy load.
> >>
> >>
> >>@Lintang:
> >>
> >>That wouldn't help any. If you put your attributes (which are not
> >>serializable) into a HashMap (which CAN (!) be serializable) the
> >>resulting object (map + attribute) still wouldn't be serializable.
> >>Serializable is more than just implementing the java.io.Serializable
> >>interface.
> >>
> >>
> >>greetings,
> >>
> >>Christoph
> >>
> >>
> >>
> >>
> >>Lintang JP wrote:
> >>
> >>>hi Nishant,
> >>>You might want to put all your session variable inside HashMap or other
> >>>datatypes that implements Serializable, rather than put it just in a
> >>
> >>single
> >>
> >>>variable. Refer to the javadocs, what are those Serializable data types
> >>
> >>are.
> >>
> >>>Or maybe you can build your own class with something like this :
> >>>public class StoredSessionValue implements Serializable {
> >>>// your session variable goes here
> >>>// your setter and getter method for those variables goes here
> >>>}
> >>>
> >>>You did right on your tags.
> >>>On 8/17/05, Nishant Deshpande <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>>Hoping for some help from the tomcat experts on this list.
> >>>>
> >>>&
Re: persistence with sessions & distributable attribute
The SessionListener can check if the attribute implements
Serializable, not if it actually is serializable.
i.e. Nothing to stop people from storing objects which implement
serializable but will barf when actually are serialized.
So - I want to catch each time there is a serialization exception and
log it etc etc.. and even perhaps just drop that object and continue
rather than just drop the serialization for the whole session (this is
what appears to be current behaviour)
i'm talking about 2 possibly orthogonal things here.. but just laying
out what i'm trying to do.
On 8/18/05, Christoph Kutzinski <[EMAIL PROTECTED]> wrote:
> Question: why do you want to catch errors during serialization.
> If you want to check that your attributes are serializable, you can use
> a SessionListener as I have shown. I can not think of any other reason
> why one would want to catch serialization exceptions.
>
>
>
> Nishant Deshpande wrote:
> > Thanks for the input.
> >
> > Any idea how I can *catch* errors during serialization? I am guessing
> > I will have to create my own PersistanceManager and override some
> > functions..
> >
> > Has anyone done this (or any other method of doing this)?
> >
> >
> > On 8/17/05, Christoph Kutzinski <[EMAIL PROTECTED]> wrote:
> >
> >>I didn't say that distributables don't have to implement
> >>java.io.Serializable. In fact they have to.
> >>I just had the impression (from your first post) that you thought by
> >>putting an non-serializable Attribute into a HashMap, the attribute
> >>would become serializable, too.
> >>
> >>Example:
> >>If you want to put a java.net.Socket into the session the session won't
> >>be distributable because Socket isn't Serializable.
> >>But if you put the Socket object into a java.util.HashMap (which
> >>implements Serializable) and put the map into the session, the session
> >>still wouldn't be distributable. This is because to serialize the
> >>session the HashMap and ALL its fields must be serialized. Because the
> >>Socket object is now part of the map, this won't work.
> >>
> >>Serializable is just a "marker" interface, i.e. the class just
> >>"declares" that is it serializable.
> >>You should read the Java Tutorial (somewhere in the JDK docs).
> >>There is explained what Serialization really means.
> >>
> >>Christoph
> >>
> >>Lintang JP wrote:
> >>
> >>>I'm referring to this document on :
> >>>http://www.onjava.com/pub/a/onjava/2004/04/14/clustering.html?page=2
> >>> The words "Serializable" here would mean for session replication, right ?
> >>>CMIIW.
> >>> On 8/17/05, Christoph Kutzinski <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>>Hi Nishant,
> >>>>
> >>>>where did you read that will *enforce* serializability?
> >>>>AFAIK "only" means that your sessions can be distributed
> >>>>to different tomcat nodes (i.e. a cluster). It doesn't enforce anything,
> >>>>you have to make sure that your session attributes are serializable by
> >>>>yourself.
> >>>>
> >>>>I've done this for my testing environment with a SessionListener:
> >>>>
> >>>>public class SessionListener implements HttpSessionListener,
> >>>>HttpSessionAttributeListener {
> >>>>
> >>>>private ObjectOutputStream stream = new ObjectOutputStream(new
> >>>>OutputStream() {
> >>>>public void write(int b) {}
> >>>>});
> >>>>
> >>>>public void attributeAdded(HttpSessionBindingEvent evt) {
> >>>>
> >>>>if (LOCAL_DEBUG) {
> >>>>// try to serialize attribute
> >>>>Object o = evt.getValue();
> >>>>synchronized (stream) {
> >>>>try {
> >>>>stream.writeObject(o);
> >>>>} catch (IOException e) {
> >>>>System.err.println(evt.getName() + " is not serializable: " +
> >>>>e.getMessage());
> >>>>e.printStackTrace();
> >>>>}
> >>>>}
> >>>>}
> >>>>}
> >>>>
> >>>>...
> >>>>}
> >>>>
> >>>>I disable LOCAL_DEBUG in the production environment, because trying to
> >>>>serialize every attribute is probably to expensive un
Re: persistence with sessions & distributable attribute
Christoph - you exactly summarize my situation - i.e. there are objects with hashmaps and so i really don't know what can be serialized at the time of serialization. As regards to 'people', others also work on this webapp, and more others will work on it in the future... so i want to try to 'futureproof' it somewhat.. thanks - i will probably implement my own PersistanceManager - looks like the only solution at this stage.. On 8/20/05, Christoph Kutzinski <[EMAIL PROTECTED]> wrote: > Nishant Deshpande wrote: > > The SessionListener can check if the attribute implements > > Serializable, not if it actually is serializable. > > > > i.e. Nothing to stop people from storing objects which implement > > serializable but will barf when actually are serialized. > > > That is not exactly true. > Look at my example. It tries to write the attribute into a "dummy" > ObjectOutputstream. If the attribute is not serializable (at that > moment) an exception will be thrown. > This does not save you, of course, from situation where someone puts an > empty HashMap via setAttribute and later puts a not serializable Object > into the map. But doing this (changing an session attribute after the > setAttribute call) isn't recommended anyway, since AFAIK Tomcats session > replication works this way that session are only updated on the remote > nodes if a setAttribute was called. > > But another question: you are talking about "people" putting objects > into the session. Isn't it you - i.e. your webapplication - who is > putting session attributes? You should have enough control over your own > application to ensure that your session attributes are serializable, > shouldn't you? > > > > So - I want to catch each time there is a serialization exception and > > log it etc etc.. and even perhaps just drop that object and continue > > rather than just drop the serialization for the whole session (this is > > what appears to be current behaviour) > > Yes, this is apparently the current behaviour. I'm not sure if I like > it, too. I guess it is implemented this way, because if one session > isn't serializable the probability is very high that other sessions are > not serializable, either. > So if you want to change this behaviour, you will probably have to > implement your own PersistanceManager. > > > > On 8/18/05, Christoph Kutzinski <[EMAIL PROTECTED]> wrote: > > > >>Question: why do you want to catch errors during serialization. > >>If you want to check that your attributes are serializable, you can use > >>a SessionListener as I have shown. I can not think of any other reason > >>why one would want to catch serialization exceptions. > >> > >> > >> > >>Nishant Deshpande wrote: > >> > >>>Thanks for the input. > >>> > >>>Any idea how I can *catch* errors during serialization? I am guessing > >>>I will have to create my own PersistanceManager and override some > >>>functions.. > >>> > >>>Has anyone done this (or any other method of doing this)? > >>> > >>> > >>>On 8/17/05, Christoph Kutzinski <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>>I didn't say that distributables don't have to implement > >>>>java.io.Serializable. In fact they have to. > >>>>I just had the impression (from your first post) that you thought by > >>>>putting an non-serializable Attribute into a HashMap, the attribute > >>>>would become serializable, too. > >>>> > >>>>Example: > >>>>If you want to put a java.net.Socket into the session the session won't > >>>>be distributable because Socket isn't Serializable. > >>>>But if you put the Socket object into a java.util.HashMap (which > >>>>implements Serializable) and put the map into the session, the session > >>>>still wouldn't be distributable. This is because to serialize the > >>>>session the HashMap and ALL its fields must be serialized. Because the > >>>>Socket object is now part of the map, this won't work. > >>>> > >>>>Serializable is just a "marker" interface, i.e. the class just > >>>>"declares" that is it serializable. > >>>>You should read the Java Tutorial (somewhere in the JDK docs). > >>>>There is explained what Serialization really means. > >>>> > >>>>Ch
