RE: Accessing resource in WEB-INF outside servlet
Hi, Then you have a screwed up design. There's no portable way to get the ServletContext to fit your needs, and there's no way to make Class#getResource read /WEB-INF unless you write a custom ClassLoader. Change your approach. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Morkeleb [mailto:[EMAIL PROTECTED] Sent: Sunday, November 07, 2004 10:51 AM To: [EMAIL PROTECTED] Subject: Accessing resource in WEB-INF outside servlet Hi. I have a file in WEB-INF which I want to access. However, this is done in a static class which is not a servlet, so I do not have the servlet context. Is there a way to access the servlet context non the less? Is there a way to make getResource find the file anyway? I know a resource is found when it's in /WEB-INF/classes, but it is only in /WEB-INF/ and it is not an option to move it to the classes directory. Can you help me? Thanx in Advance, Lukas Österreicher - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing resource in WEB-INF outside servlet
Is using JNDI to access a file like this a reasonable approach? I just started using JNDI to name my database connections via a connection pool. And when i saw the simplicity of accessing the JNDI context within my java classes, i got to thinking that i should use it to access many of my applications configuration variables, such as the location of various directories for templates and uploads. it seems much cleaner than passing the request around just to get at the application scope. Could the original poster stick either the file location in the JNDI context, so he could easily reference it later, or if the file wasn't too large, use a custom resource factory to wrap its contents in a bean and then use the JNDI context to access the file contents. I haven't tried any of this myself, but was planning to in the next week or two, when i got some time. Can anyone point out pros and cons of this approach? the link to the tomcat/JNDI documentation: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-resources-howto.html dave On Mon, 2004-11-08 at 08:03, Shapira, Yoav wrote: Hi, Then you have a screwed up design. There's no portable way to get the ServletContext to fit your needs, and there's no way to make Class#getResource read /WEB-INF unless you write a custom ClassLoader. Change your approach. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Morkeleb [mailto:[EMAIL PROTECTED] Sent: Sunday, November 07, 2004 10:51 AM To: [EMAIL PROTECTED] Subject: Accessing resource in WEB-INF outside servlet Hi. I have a file in WEB-INF which I want to access. However, this is done in a static class which is not a servlet, so I do not have the servlet context. Is there a way to access the servlet context non the less? Is there a way to make getResource find the file anyway? I know a resource is found when it's in /WEB-INF/classes, but it is only in /WEB-INF/ and it is not an option to move it to the classes directory. Can you help me? Thanx in Advance, Lukas Österreicher - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: Accessing resource in WEB-INF outside servlet
Hi, Is using JNDI to access a file like this a reasonable approach? I just It's an OK approach. Not great, but not terrible either. The reasons it's not great are: - It's heavyweight (JNDI resource binding and resolution is typically several times more resource consuming than a static resource lookup via either the classpath or the ServletContext). But if done once to initialize a variable, this is fairly negligible. - It's container-dependent: you need something to do the JNDI binding and lookups. Running a small console app with this code becomes very difficult. And unit testing it as-is becomes exceedingly difficult. - It's awkward to change: you need to modify a container-specific configuration file to change the entry. This is both a pro and con, though, as it means the server admin running your app can modify this without needing programmer intervention. So it'll work, but the above merit consideration. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing resource in WEB-INF outside servlet
Thanks for the reply. So the next question of course is, what is a better approach? I understand idea of using putting an object in the ServletContext during application initialization, but that leads to other problems. Well, to be specific, heres the problem i have with that in my application: i have static DAO classes, one per database table, that my application uses to handle persistance of my applications business objects. So i need the connection information for the database. i have other application instance specific variables also, directory paths for templates and upload. So originally i wrote a AppConfig class that had properties for all these variables, and a factory class that read an xml file, and created a instance of the AppConfig class and stuck it in the ServletContext during initialization. But the DAO classes are static classes, and should be usable by any java program, not just a Servlet. They currently have a very clean API, for instance: public static Book getBook(String bookId) public static void updateBook(Book book) So in order to preserve that cleanliness, the methods have to get the connection path themselves, which was why i was so excited by the JNDI lookup. So any advice? dave On Mon, 2004-11-08 at 08:59, Shapira, Yoav wrote: Hi, Is using JNDI to access a file like this a reasonable approach? I just It's an OK approach. Not great, but not terrible either. The reasons it's not great are: - It's heavyweight (JNDI resource binding and resolution is typically several times more resource consuming than a static resource lookup via either the classpath or the ServletContext). But if done once to initialize a variable, this is fairly negligible. - It's container-dependent: you need something to do the JNDI binding and lookups. Running a small console app with this code becomes very difficult. And unit testing it as-is becomes exceedingly difficult. - It's awkward to change: you need to modify a container-specific configuration file to change the entry. This is both a pro and con, though, as it means the server admin running your app can modify this without needing programmer intervention. So it'll work, but the above merit consideration. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: Accessing resource in WEB-INF outside servlet
Hi, public static Book getBook(String bookId) public static void updateBook(Book book) So in order to preserve that cleanliness, the methods have to get the connection path themselves, which was why i was so excited by the JNDI lookup. Having each Bean get its own connection path itself is not clean, but it's your design, so it's up to you. You can use the other approach mentioned (but shunned) by the original poster, which is to put said configuration information on the classpath. Then each of your classes can get getClass().getResource(/myConfigFile.prop) to get the configuration. That's much more testable and portable, doesn't depend on a container, doesn't depend on the Servlet API. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing resource in WEB-INF outside servlet
Ok, thanks i will look into the getResource configuration method, it sounds like that would subsitute for the JNDI lookup cleanly. So one last thing, if you've got the time. You said: Having each Bean get its own connection path itself is not clean, but it's your design, so it's up to you. so how do you handle this? do you pass in the connection info to every DAO method, like this: public static Book getBook(String connection, String bookId) public static void updateBook(String connection, Book book) that seems tedious, and since the all of my database interaction is encapsulated in the DAOs, it seems unclean to reference the connection anywhere else. again, thanks for your help thus far. dave On Mon, 2004-11-08 at 09:21, Shapira, Yoav wrote: Hi, public static Book getBook(String bookId) public static void updateBook(Book book) So in order to preserve that cleanliness, the methods have to get the connection path themselves, which was why i was so excited by the JNDI lookup. Having each Bean get its own connection path itself is not clean, but it's your design, so it's up to you. You can use the other approach mentioned (but shunned) by the original poster, which is to put said configuration information on the classpath. Then each of your classes can get getClass().getResource(/myConfigFile.prop) to get the configuration. That's much more testable and portable, doesn't depend on a container, doesn't depend on the Servlet API. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: Accessing resource in WEB-INF outside servlet
Hi, so how do you handle this? do you pass in the connection info to every DAO method, like this: public static Book getBook(String connection, String bookId) public static void updateBook(String connection, Book book) that seems tedious, and since the all of my database You can have the beans get a datasource (from a singleton possibly) and call its getConnection method. To encapsulate further, you can just expose a getConnection method on said singleton. That way only one class needs to worry about database configuration. And you have only one place to change if you switch from a Class#getResource approach to a JNDI one or vice versa. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing resource in WEB-INF outside servlet
On Mon, 2004-11-08 at 09:35, Shapira, Yoav wrote:
Hi,
so how do you handle this? do you pass in the connection info to every
DAO method, like this:
public static Book getBook(String connection, String bookId)
public static void updateBook(String connection, Book book)
that seems tedious, and since the all of my database
You can have the beans get a datasource (from a singleton possibly) and
call its getConnection method. To encapsulate further, you can just
expose a getConnection method on said singleton. That way only one
class needs to worry about database configuration. And you have only
one place to change if you switch from a Class#getResource approach to a
JNDI one or vice versa.
Yoav
So the intialization of this sington datasource provider occurs the
first time the class is called? and from then on out there's only one
instance of the class, owing to its singleton nature? would that look
like this:
public class AppDBConnector {
private static final INSTANCE = new AppDBConector();
private static DataSource ds;
private AppDBConnector() {
// set static ds abov using JNDI lookup or resource bundle
}
public AppDBConnector getInstance() {
return INSTANCE;
}
public Connection getConnection() {
return ds.getConnection();
}
}
Then used in the DAO like this:
Connection conn = AppDBConnector.getInstance().getConnection();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing resource in WEB-INF outside servlet
Hi,
So the intialization of this sington datasource provider occurs the
first time the class is called? and from then on out there's only one
instance of the class, owing to its singleton nature? would that look
like this:
public class AppDBConnector {
private static final INSTANCE = new AppDBConector();
private static DataSource ds;
private AppDBConnector() {
// set static ds abov using JNDI lookup or resource
bundle
}
public AppDBConnector getInstance() {
return INSTANCE;
}
public Connection getConnection() {
return ds.getConnection();
}
}
Close enough. There's no need for ds to be static. And some people
prefer to not construct INSTANCE until the first getInstance call. But
those are smaller details.
Yoav
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged. This e-mail is intended only for the individual(s) to whom
it is addressed, and may not be saved, copied, printed, disclosed or used by
anyone else. If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing resource in WEB-INF outside servlet
Thanks again for the help, this approach is very clean, and i'll be
using it.
dave
On Mon, 2004-11-08 at 10:15, Shapira, Yoav wrote:
Hi,
So the intialization of this sington datasource provider occurs the
first time the class is called? and from then on out there's only one
instance of the class, owing to its singleton nature? would that look
like this:
public class AppDBConnector {
private static final INSTANCE = new AppDBConector();
private static DataSource ds;
private AppDBConnector() {
// set static ds abov using JNDI lookup or resource
bundle
}
public AppDBConnector getInstance() {
return INSTANCE;
}
public Connection getConnection() {
return ds.getConnection();
}
}
Close enough. There's no need for ds to be static. And some people
prefer to not construct INSTANCE until the first getInstance call. But
those are smaller details.
Yoav
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged. This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else. If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender. Thank you.
-
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: Accessing resource in WEB-INF outside servlet
David Evans wrote: so how do you handle this? do you pass in the connection info to every DAO method, like this: public static Book getBook(String connection, String bookId) public static void updateBook(String connection, Book book) that seems tedious, and since the all of my database On Mon, Nov 08, 2004 at 09:35:25AM -0500, Shapira, Yoav wrote: You can have the beans get a datasource (from a singleton possibly) and call its getConnection method. To encapsulate further, you can just expose a getConnection method on said singleton. That way only one class needs to worry about database configuration. And you have only one place to change if you switch from a Class#getResource approach to a JNDI one or vice versa. That's pretty much the approach I took - I have a singleton Database class that primarily serves as a single point to get database connections. I have separate bean and bean-to-db-mapping classes for each table. The bean-to-db-mapping classes grab their connections via Database.getInstance().getConnection(). The Database singleton loads a properties file and keeps it as an instance variable, to get the connection config variables (David, see below for further discussion). This worked at the time, and I had bigger problems to worry about. The properties file grew into being the source of all of the application configuration variables. This works well enough so far, though it really seems like Properties ought to be a separate singleton, and that's on my list of things to refactor. However, there are other issues that bug me in this setup (mainly that everybody tells me that deploying and upgrading works much, much better if you use a WAR file, see my earlier post, Re: Configuration Management, JSP Compiles, WAR files), so I'm interested in exploring alternatives. The best approach I've come up with so far (based on suggestions here) is pretty much keeping a singleton config object, except that the config file is loaded from a file that lives outside the webapp, passed in via a resource ref defined in server.xml. One JNDI hit to load the file, stays in memory after. (Oh, and I'm switching to an XML-based config file instead of properties. I'm also considering splitting the config up into multiple files, since a small subset change often, a medium subset change somewhat often, and the remainder change hardly ever). Further Discussion This approach still leaves the dependency on the properties singleton AND on the connection singleton hardwired into the mapping classes. For David's purposes, sounds like you may want to apply the buzz-word-du-jour, Inversion of Control or Dependency Injection. - make an interface, something like ConnectionFactory - make a singleton that implements ConnectionFactory - add a constructor to each bean (or to the separate mapper object) that takes a ConnectionFactory as a reference. So you inject the dependency into the bean, or into the mapper. At the higher level, you have some setup class that injects the dependencies into various factory singletons, that then inject them into the beans or mappers they dispense. Let's sort out that bean/mapper question first. Like I said above, I have a separate bean and bean-to-db mapper class for each table. The mapper class has select, insert, update and delete methods. Each takes a bean of the same time as an argument and uses that to construct the query (WHERE clause for selects, UPDATE clause for updates, etc). The select method has two flavors, one that returns a bean for the first row, another that returns a List of beans. For my reasons on why I set it up that way, see below in the Even Further Discussion section. Any way you slice it, we now come to the question of where the dependency gets injected - how the ConnectionFactory reference gets to somewhere the mapping method can find it. You have a single source of Connections, and you have a set of DBMappers that are designed to take those connections. Looking at it logically, you only have a few options: 1) instantiate each DBMapper with a Connection reference 2) instantiate each DBMapper with a ConnectionFactory reference 3) create a DBMapperFactory and instantiate with a ConnectionFactory reference (probably at some early app-wide setup point), then: 3a) dispense DBMappers with a Connection reference 3b) dispense DBMappers with a ConnectionFactory reference 3c) dispense DBMappers with a DBMapperFactory reference (e.g.: getDBMapperFactory().getConnectionFactory().getConnection()) 4) move the actual database-interaction methods off to some generic database interaction class, and keep the Beans and Mappers pretty much ignorant of things like Connection. 5) dependency injection: have an outside class set up all of the factories and cross-wire them with references to each other as appropriate. In general, I'd say the design tension is between
Re: Accessing resource in WEB-INF outside servlet
I am not sure where this discussion is coming from or going, but I
have no difficulty with reading resources inside WEB-INF. First, I
use a Classpath class and the given classloaders something like the
following:
package com.whatever.classpath;
public final class Classpath {
public static final String HERE = Classpath.
class.
getClassLoader().
getResource(com + File.separator +
whatever + File.separator +
classpath + File.separator +
Classpath.class).getFile();
}
Other classes can then use this class and HERE as well as other paths
such as CLASSES, MESSAGES, or whatever, inside WEB-INF.
Is this helpful?
Jack
On Sun, 07 Nov 2004 16:50:37 +0100, Morkeleb [EMAIL PROTECTED] wrote:
Hi.
I have a file in WEB-INF which I want to access.
However, this is done in a static class which is not a servlet,
so I do not have the servlet context.
Is there a way to access the servlet context non the less?
Is there a way to make getResource find the file anyway?
I know a resource is found when it's in /WEB-INF/classes,
but it is only in /WEB-INF/ and it is not an option to move
it to the classes directory.
Can you help me?
Thanx in Advance,
Lukas Österreicher
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
You can't wake a person who is pretending to be asleep.
~Native Proverb~
Each man is good in His sight. It is not necessary for eagles to be crows.
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Accessing resource in WEB-INF outside servlet
Hi. I have a file in WEB-INF which I want to access. However, this is done in a static class which is not a servlet, so I do not have the servlet context. Is there a way to access the servlet context non the less? Is there a way to make getResource find the file anyway? I know a resource is found when it's in /WEB-INF/classes, but it is only in /WEB-INF/ and it is not an option to move it to the classes directory. Can you help me? Thanx in Advance, Lukas sterreicher - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
