AW: Problem with JNDI Resources "JavaMail Sessions"
Hey guys,
I found the solution.
I had import the wrong Session-class.
So long,
Sebastian
> Hey Team,
>
> I have some problems with the example of JNDI Resources "JavaMail
> Sessions".
>
> I get the error: The constructor MimeMessage(Session) is undefined
>
> A extract from the HOW-TO page:
> Context initCtx = new InitialContext();
> Context envCtx = (Context) initCtx.lookup("java:comp/env");
> Session session = (Session) envCtx.lookup("mail/Session");
>
> Message message = new MimeMessage(session);
> message.setFrom(new InternetAddress(request.getParameter("from"));
> InternetAddress to[] = new InternetAddress[1];
> to[0] = new InternetAddress(request.getParameter("to"));
> message.setRecipients(Message.RecipientType.TO, to);
> message.setSubject(request.getParameter("subject"));
> message.setContent(request.getParameter("content"), "text/plain");
> Transport.send(message);
>
> I develop with Eclipse / Tomcat 6.0 and created a new Web Application.
>
> At first I modify my web descriptor (/WebContent/WEB-INF/web.xml) and
> include the resource description.
>
> In the next step I downloaded the JavaMail API, included to the
> Tomcat-Library and configure the resource factory
> (Tomcat/lib/context.xml).
>
> Eclipse find the JavaMail API but it doesn't find the constructor in
> this API.
>
> I hope you can help me. This is a new section for me.
>
> Best regards,
> Sebastian
>
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Problem with JNDI Resources "JavaMail Sessions"
Hey Team,
I have some problems with the example of JNDI Resources "JavaMail
Sessions".
I get the error: The constructor MimeMessage(Session) is undefined
A extract from the HOW-TO page:
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
Session session = (Session) envCtx.lookup("mail/Session");
Message message = new MimeMessage(session);
message.setFrom(new InternetAddress(request.getParameter("from"));
InternetAddress to[] = new InternetAddress[1];
to[0] = new InternetAddress(request.getParameter("to"));
message.setRecipients(Message.RecipientType.TO, to);
message.setSubject(request.getParameter("subject"));
message.setContent(request.getParameter("content"), "text/plain");
Transport.send(message);
I develop with Eclipse / Tomcat 6.0 and created a new Web Application.
At first I modify my web descriptor (/WebContent/WEB-INF/web.xml) and
include the resource description.
In the next step I downloaded the JavaMail API, included to the
Tomcat-Library and configure the resource factory
(Tomcat/lib/context.xml).
Eclipse find the JavaMail API but it doesn't find the constructor in
this API.
I hope you can help me. This is a new section for me.
Best regards,
Sebastian
Re: Problem with JNDI environment entry resources
I'm out then. I'm fine with the way tomcat operates and don't feel
anything in the way context xml files are associated with webapps is
ambiguous. It's really simple:
1. If you just want to deploy a webapp and don't need to define any
resources like db pools, just drop the webapp in the webapps folder.
The context xml file is not needed for such a basic deployment. The
context path will be the name of the webapp.
2. If you need resources defined, then create a context xml file named
after the webapp and placed in conf/EngineName/HostName.
3. Only define the docBase attribute of a ...
element if your webapp live's outside the appBase of any of tomcat's
... definitions in server.xml.
I'm sure if you'd like to make changes you could check out the tomcat
source, make your changes, create a patch, and submit your proposal in
Bugzilla for the tomcat committers to take a look at. If you feel the
true problem is in the docs, patches are accepted for that as well.
--David
Paul Pepper wrote:
2008/9/3 David Smith <[EMAIL PROTECTED]>:
There's an implicit association based on the context path. myWebApp.xml in
conf/Catalina/localhost is implicitly associated with the webapp myWebApp in
the webapps directory, whether it be as a .war or expanded folder.
Yes, I agree that the docs read this way. The point under discussion
here was the use of a docBase within server.xml - it's
necessary in order to disambiguate the use of a to a
specific application.
Illegal may be a strong word -- it implies that tomcat will flat out reject
the context when you define a docBase. If there is a docBase attribute
defined, it may be ignored if there's a webapp in the webapps directory
matching the context name (as defined by the *name* of the context xml file
in conf/{Engine Name}/{Host name}, not the path attribute of
I don't understand "may be ignored". Either docBase is ignored in this
situation, or it isn't.
...>). Worse, if the name of your webapp in webapps is
different than the name of the context xml file in conf/{Engine Name}/{Host
name}, you can get a double-deploy. Only one instance of the webapp will
have the additional settings provided by the context xml file though.
I'm afraid I haven't encountered this behaviour described in the docs.
I'd be grateful of a reference to it. Where documentation is missing,
or where further clarity is required (as suggested by repeated
user/developer mistakes), what is the procedure within Apache for
helping make this happen?
Best practice overall is don't specify a docBase attribute unless your
webapp is outside the appBase you are deploying the application to. Some
people have reasons for doing this -- like when they absolutely have to have
the war file named in some specific way that doesn't match the context path.
That suggests that you've encountered cases where it is reasonable for
the docBase and the context's xml file name to differ. However, the
ambiguity in the use of docBase (re. above), and the double deployment
problem that you mention, makes it difficult to solve this problem -
worse if the use of taken away as an option.
If it's agreeable to the guys that have responded so far, then I'd
like to get this discussion onto a thread of its own so that the
subject reflects the discussion and mail headers refer to a specific
topic. If you'd like to continue the discussion about that
we have started here, then please give me a little time to post this
question as another message on this list - referring to this thread in
the archives to avoid repetition.
Also don't define a path attribute unless your ...
element is in server.xml (absolutely NOT recommended).
Agreed!
Thanks,
Paul.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI environment entry resources
2008/9/3 David Smith <[EMAIL PROTECTED]>:
> There's an implicit association based on the context path. myWebApp.xml in
> conf/Catalina/localhost is implicitly associated with the webapp myWebApp in
> the webapps directory, whether it be as a .war or expanded folder.
Yes, I agree that the docs read this way. The point under discussion
here was the use of a docBase within server.xml - it's
necessary in order to disambiguate the use of a to a
specific application.
> Illegal may be a strong word -- it implies that tomcat will flat out reject
> the context when you define a docBase. If there is a docBase attribute
> defined, it may be ignored if there's a webapp in the webapps directory
> matching the context name (as defined by the *name* of the context xml file
> in conf/{Engine Name}/{Host name}, not the path attribute of ...>). Worse, if the name of your webapp in webapps is
> different than the name of the context xml file in conf/{Engine Name}/{Host
> name}, you can get a double-deploy. Only one instance of the webapp will
> have the additional settings provided by the context xml file though.
I'm afraid I haven't encountered this behaviour described in the docs.
I'd be grateful of a reference to it. Where documentation is missing,
or where further clarity is required (as suggested by repeated
user/developer mistakes), what is the procedure within Apache for
helping make this happen?
> Best practice overall is don't specify a docBase attribute unless your
> webapp is outside the appBase you are deploying the application to. Some
> people have reasons for doing this -- like when they absolutely have to have
> the war file named in some specific way that doesn't match the context path.
That suggests that you've encountered cases where it is reasonable for
the docBase and the context's xml file name to differ. However, the
ambiguity in the use of docBase (re. above), and the double deployment
problem that you mention, makes it difficult to solve this problem -
worse if the use of taken away as an option.
If it's agreeable to the guys that have responded so far, then I'd
like to get this discussion onto a thread of its own so that the
subject reflects the discussion and mail headers refer to a specific
topic. If you'd like to continue the discussion about that
we have started here, then please give me a little time to post this
question as another message on this list - referring to this thread in
the archives to avoid repetition.
> Also don't define a path attribute unless your ...
> element is in server.xml (absolutely NOT recommended).
Agreed!
Thanks,
Paul.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with JNDI environment entry resources
> From: Paul Pepper [mailto:[EMAIL PROTECTED] > Subject: Re: Problem with JNDI environment entry resources > > Besides, I don't see any other documented way of associating > each application with its associated element within > server.xml. Because you're not supposed to put elements in server.xml anymore; it works (mostly), but it's strongly discouraged. Don't do it. > Then you'd be taking away the only mechanism (that I can see) for > pointing to an application as ROOT, without the inelegant renaming of > applications as ROOT. Odd viewpoint, since naming the default app ROOT is the most straightforward and elegant mechanism I can think of. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI environment entry resources
There's an implicit association based on the context path. myWebApp.xml
in conf/Catalina/localhost is implicitly associated with the webapp
myWebApp in the webapps directory, whether it be as a .war or expanded
folder.
Illegal may be a strong word -- it implies that tomcat will flat out
reject the context when you define a docBase. If there is a docBase
attribute defined, it may be ignored if there's a webapp in the webapps
directory matching the context name (as defined by the *name* of the
context xml file in conf/{Engine Name}/{Host name}, not the path
attribute of ). Worse, if the name of your
webapp in webapps is different than the name of the context xml file in
conf/{Engine Name}/{Host name}, you can get a double-deploy. Only one
instance of the webapp will have the additional settings provided by the
context xml file though.
Best practice overall is don't specify a docBase attribute unless your
webapp is outside the appBase you are deploying the application to.
Some people have reasons for doing this -- like when they absolutely
have to have the war file named in some specific way that doesn't match
the context path. Also don't define a path attribute unless your
... element is in server.xml (absolutely NOT
recommended).
--David
Paul Pepper wrote:
I'll have to check the docs again. However, docBase is only legal when the webapp is
stored outside of the
appBase directory. Otherwise, you risk ending up with double deployment.
I don't see docBase described that way in the docs - at this moment
I'm referring to
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html. Besides,
I don't see any other documented way of associating each application
with its associated element within server.xml.
unless I named the application ROOT, which is less than ideal
That is the defined mechanism for specifying the default webapp in current
Tomcat levels.
That's one mechanism for specifying the ROOT application. Referring to
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html, when
using individual context files under
$CATALINA_BASE/conf/[enginename]/[hostname]/:
"The default web application may be defined by using a file called
ROOT.xml."
The filename less the .xml provides the context path (/ in the case of
ROOT) and the element's docBase points to the ROOT
application. This is all in accordance with the current 6.0 docs from
my reading of them.
I'd like to pull this out into a thread of its own on this mailing
list. Maybe we can take this discussion there. This particular problem
is of importance to me, and it would seem also to others judging by
the comments left on the bug report that I referenced in my previous
comment.
Placing elements in server.xml is really only there for compatibility
with older versions of Tomcat. Personally, I'd like to see it made illegal, which
would put an end to many potential configuration errors.
Then you'd be taking away the only mechanism (that I can see) for
pointing to an application as ROOT, without the inelegant renaming of
applications as ROOT.
Paul.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI environment entry resources
> I'll have to check the docs again. However, docBase is only legal when the > webapp is stored outside of the > appBase directory. Otherwise, you risk ending up with double deployment. I don't see docBase described that way in the docs - at this moment I'm referring to http://tomcat.apache.org/tomcat-6.0-doc/config/context.html. Besides, I don't see any other documented way of associating each application with its associated element within server.xml. >> unless I named the application ROOT, which is less than ideal > That is the defined mechanism for specifying the default webapp in current > Tomcat levels. That's one mechanism for specifying the ROOT application. Referring to http://tomcat.apache.org/tomcat-6.0-doc/config/context.html, when using individual context files under $CATALINA_BASE/conf/[enginename]/[hostname]/: "The default web application may be defined by using a file called ROOT.xml." The filename less the .xml provides the context path (/ in the case of ROOT) and the element's docBase points to the ROOT application. This is all in accordance with the current 6.0 docs from my reading of them. I'd like to pull this out into a thread of its own on this mailing list. Maybe we can take this discussion there. This particular problem is of importance to me, and it would seem also to others judging by the comments left on the bug report that I referenced in my previous comment. > Placing elements in server.xml is really only there for > compatibility with older versions of Tomcat. Personally, I'd like to see it > made illegal, which would put an end to many potential configuration errors. Then you'd be taking away the only mechanism (that I can see) for pointing to an application as ROOT, without the inelegant renaming of applications as ROOT. Paul. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with JNDI environment entry resources
i havent used JNDI to obtain string values
i use ResourceBundle to obtain the locale specific string value e.g.
myResources.getString("CancelKey");
http://java.sun.com/j2se/1.4.2/docs/api/java/util/ResourceBundle.html
anyone
Martin
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business
of Sender. This transmission is of a confidential nature and Sender does not
endorse distribution to any party other than intended recipient. Sender does
not necessarily endorse content contained within this transmission.
> Date: Wed, 3 Sep 2008 14:42:24 +0100
> From: [EMAIL PROTECTED]
> To: users@tomcat.apache.org
> Subject: Re: Problem with JNDI environment entry resources
>
> Martin,
>
> Thanks for the suggestion, though I think there may have been some
> misunderstanding. I'm attempting to access a simple java.lang.String,
> not a DataSource. elements are used to place String
> resources in an application's environment, not elements,
> AFAIK.
>
> Paul.
>
> 2008/9/3 Martin Gainty <[EMAIL PROTECTED]>:
> >
> > http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
> > /WEB-INF/web.xml contents which contain a jndi reference > xmlns="http://java.sun.com/xml/ns/j2ee";
> >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
> >version="2.4">
> > MySQL Test App
> >
> > DB Connection
> > teststring
> > javax.sql.DataSource
> > Container
> >
> >
> >
> > the lookup to teststring will get you a connection to the DB
> >
> > HTH
> > Martin
> > __
> > Disclaimer and confidentiality note
> > Everything in this e-mail and any attachments relates to the official
> > business of Sender. This transmission is of a confidential nature and
> > Sender does not endorse distribution to any party other than intended
> > recipient. Sender does not necessarily endorse content contained within
> > this transmission.
> >
> >
> >> Date: Wed, 3 Sep 2008 01:01:40 +0100
> >> From: [EMAIL PROTECTED]
> >> To: users@tomcat.apache.org
> >> Subject: Problem with JNDI environment entry resources
> >>
> >> Tomcat 6.0.18
> >> java version "1.6.0_06" (sun-java6-jdk on Ubuntu 8.04 i386)
> >>
> >> I'm attempting to create environment entry resources, of type
> >> java.lang.String, within conf/server.xml and access them from web
> >> applications using JNDI. I've created a bare-bones test web app,
> >> jndistring, with the following conf/server.xml configuration:
> >>
> >> server.xml (snipped):
> >> -
> >>>> appBase="webapps"
> >> unpackWARs="true"
> >> autoDeploy="false"
> >> deployOnStarup="true"
> >> xmlValidation="false"
> >> xmlNamespaceAware="false">
> >>
> >> >> path="jndistring"
> >> useNaming="true">
> >>
> >> >> value="a test value"
> >> type="java.lang.String"
> >> override="false"
> >> />
> >>
> >>
> >>
> >>
> >> For the purpose of this test I've used jsp to access the value of
> >> teststring.
> >>
> >> jndistring.jsp (snipped):
> >>
> >> <%
> >> Context initCtx = new InitialContext();
> >> Context envCtx = (Context) initCtx.lookup("java:comp/env");
> >>
> >> String teststring = (String) envCtx.lookup("teststring");
> >> out.println("teststring: " + teststring);
> >> %>
> >>
> >> Accessing this page throws an exception:
> >> org.apache.jasper.JasperException: An exception occurred processing
> >> JSP page /test.jsp at line 18
> >> 15: Context initCtx = new InitialContext();
> >> 16: Context envCtx = (Context) initCtx.lookup("java:comp/env");
> >> 17:
> >&
RE: Problem with JNDI environment entry resources
> From: Paul Pepper [mailto:[EMAIL PROTECTED] > Subject: Re: Problem with JNDI environment entry resources > > Tomcat 6 docs states that docBase is a valid attribute > in this situation. I'll have to check the docs again. However, docBase is only legal when the webapp is stored outside of the appBase directory. Otherwise, you risk ending up with double deployment. > unless I named the application ROOT, which is less than ideal That is the defined mechanism for specifying the default webapp in current Tomcat levels. > Would folks here, then, be inclined to believe that there is a bug in > using within a server.xml file? Placing elements in server.xml is really only there for compatibility with older versions of Tomcat. Personally, I'd like to see it made illegal, which would put an end to many potential configuration errors. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI environment entry resources
Martin,
Thanks for the suggestion, though I think there may have been some
misunderstanding. I'm attempting to access a simple java.lang.String,
not a DataSource. elements are used to place String
resources in an application's environment, not elements,
AFAIK.
Paul.
2008/9/3 Martin Gainty <[EMAIL PROTECTED]>:
>
> http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
> /WEB-INF/web.xml contents which contain a jndi reference xmlns="http://java.sun.com/xml/ns/j2ee";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
>version="2.4">
> MySQL Test App
>
> DB Connection
> teststring
> javax.sql.DataSource
> Container
>
>
>
> the lookup to teststring will get you a connection to the DB
>
> HTH
> Martin
> __
> Disclaimer and confidentiality note
> Everything in this e-mail and any attachments relates to the official
> business of Sender. This transmission is of a confidential nature and Sender
> does not endorse distribution to any party other than intended recipient.
> Sender does not necessarily endorse content contained within this
> transmission.
>
>
>> Date: Wed, 3 Sep 2008 01:01:40 +0100
>> From: [EMAIL PROTECTED]
>> To: users@tomcat.apache.org
>> Subject: Problem with JNDI environment entry resources
>>
>> Tomcat 6.0.18
>> java version "1.6.0_06" (sun-java6-jdk on Ubuntu 8.04 i386)
>>
>> I'm attempting to create environment entry resources, of type
>> java.lang.String, within conf/server.xml and access them from web
>> applications using JNDI. I've created a bare-bones test web app,
>> jndistring, with the following conf/server.xml configuration:
>>
>> server.xml (snipped):
>> -
>> > appBase="webapps"
>> unpackWARs="true"
>> autoDeploy="false"
>> deployOnStarup="true"
>> xmlValidation="false"
>> xmlNamespaceAware="false">
>>
>> > path="jndistring"
>> useNaming="true">
>>
>> > value="a test value"
>> type="java.lang.String"
>> override="false"
>> />
>>
>>
>>
>>
>> For the purpose of this test I've used jsp to access the value of teststring.
>>
>> jndistring.jsp (snipped):
>>
>> <%
>> Context initCtx = new InitialContext();
>> Context envCtx = (Context) initCtx.lookup("java:comp/env");
>>
>> String teststring = (String) envCtx.lookup("teststring");
>> out.println("teststring: " + teststring);
>> %>
>>
>> Accessing this page throws an exception:
>> org.apache.jasper.JasperException: An exception occurred processing
>> JSP page /test.jsp at line 18
>> 15: Context initCtx = new InitialContext();
>> 16: Context envCtx = (Context) initCtx.lookup("java:comp/env");
>> 17:
>> 18: String teststring = (String) envCtx.lookup("teststring");
>> 19: out.println("teststring: " + teststring);
>> 20: %>
>>
>> The top frame of the root cause is shown as:
>> javax.servlet.ServletException: javax.naming.NameNotFoundException:
>> Name teststring is not bound in this Context
>>
>> If I attempt to create an environment entry resource using
>> (and sub-elements) within web.xml, then the resource is
>> created and I can access it!!!
>>
>> I've read the "JNDI resources howto", docs regarding the ,
>> and elements (and others), but don't see
>> that I have missed anything.
>>
>> Can anyone suggest what I might have missed? Has anyone else had
>> similar problems?
>>
>> Thanks,
>>
>> Paul.
>>
>> -
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> _
> Get thousands of games on your PC, your mobile phone, and the web with
> Windows(R).
> http://clk.atdmt.com/MRT/go/108588800/direct/01/
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI environment entry resources
Thanks Chuck, I just tested this by creating a context element in its own file under conf/Catalina/localhost/jnditest.xml and that worked. (BTW, Tomcat 6 docs states that docBase is a valid attribute in this situation. It is only illegal when the element is defined within META-INF/context.xml.): I had chosen the server.xml approach because I wish to deploy some applications as the default/ROOT, and I haven't had any success in doing that using this approach (unless I named the application ROOT, which is less than ideal). Others have raised a bug report against this particular difficulty, and I recently contributed a comment, but it was dealt with in an unhelpful manner: https://issues.apache.org/bugzilla/show_bug.cgi?id=41746 Well, that's for another question on this mailing list! Would folks here, then, be inclined to believe that there is a bug in using within a server.xml file? - given that I'm using only a slightly changed configuration (the "path" attribute being the only change). I'm hesitant to raise a bug for fear of being flamed again! Thanks, Paul. 2008/9/3 Caldarale, Charles R <[EMAIL PROTECTED]>: >> From: Paul Pepper [mailto:[EMAIL PROTECTED] >> Subject: Problem with JNDI environment entry resources >> >> Can anyone suggest what I might have missed? > > What happens if you follow the (strongly) recommended practice of not putting > elements in server.xml? If you don't want to put the > inside your .war file (understandable), put it in > conf/Catalina/localhost/jndistring.xml, and remove the illegal docBase and > path attributes. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with JNDI environment entry resources
http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
/WEB-INF/web.xml contents which contain a jndi reference http://java.sun.com/xml/ns/j2ee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
version="2.4">
MySQL Test App
DB Connection
teststring
javax.sql.DataSource
Container
the lookup to teststring will get you a connection to the DB
HTH
Martin
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business
of Sender. This transmission is of a confidential nature and Sender does not
endorse distribution to any party other than intended recipient. Sender does
not necessarily endorse content contained within this transmission.
> Date: Wed, 3 Sep 2008 01:01:40 +0100
> From: [EMAIL PROTECTED]
> To: users@tomcat.apache.org
> Subject: Problem with JNDI environment entry resources
>
> Tomcat 6.0.18
> java version "1.6.0_06" (sun-java6-jdk on Ubuntu 8.04 i386)
>
> I'm attempting to create environment entry resources, of type
> java.lang.String, within conf/server.xml and access them from web
> applications using JNDI. I've created a bare-bones test web app,
> jndistring, with the following conf/server.xml configuration:
>
> server.xml (snipped):
> -
>appBase="webapps"
> unpackWARs="true"
> autoDeploy="false"
> deployOnStarup="true"
> xmlValidation="false"
> xmlNamespaceAware="false">
>
> path="jndistring"
> useNaming="true">
>
> value="a test value"
> type="java.lang.String"
> override="false"
> />
>
>
>
>
> For the purpose of this test I've used jsp to access the value of teststring.
>
> jndistring.jsp (snipped):
>
> <%
> Context initCtx = new InitialContext();
> Context envCtx = (Context) initCtx.lookup("java:comp/env");
>
> String teststring = (String) envCtx.lookup("teststring");
> out.println("teststring: " + teststring);
> %>
>
> Accessing this page throws an exception:
> org.apache.jasper.JasperException: An exception occurred processing
> JSP page /test.jsp at line 18
> 15: Context initCtx = new InitialContext();
> 16: Context envCtx = (Context) initCtx.lookup("java:comp/env");
> 17:
> 18: String teststring = (String) envCtx.lookup("teststring");
> 19: out.println("teststring: " + teststring);
> 20: %>
>
> The top frame of the root cause is shown as:
> javax.servlet.ServletException: javax.naming.NameNotFoundException:
> Name teststring is not bound in this Context
>
> If I attempt to create an environment entry resource using
> (and sub-elements) within web.xml, then the resource is
> created and I can access it!!!
>
> I've read the "JNDI resources howto", docs regarding the ,
> and elements (and others), but don't see
> that I have missed anything.
>
> Can anyone suggest what I might have missed? Has anyone else had
> similar problems?
>
> Thanks,
>
> Paul.
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
_
Get thousands of games on your PC, your mobile phone, and the web with Windows®.
http://clk.atdmt.com/MRT/go/108588800/direct/01/
RE: Problem with JNDI environment entry resources
> From: Paul Pepper [mailto:[EMAIL PROTECTED] > Subject: Problem with JNDI environment entry resources > > Can anyone suggest what I might have missed? What happens if you follow the (strongly) recommended practice of not putting elements in server.xml? If you don't want to put the inside your .war file (understandable), put it in conf/Catalina/localhost/jndistring.xml, and remove the illegal docBase and path attributes. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with JNDI environment entry resources
Tomcat 6.0.18
java version "1.6.0_06" (sun-java6-jdk on Ubuntu 8.04 i386)
I'm attempting to create environment entry resources, of type
java.lang.String, within conf/server.xml and access them from web
applications using JNDI. I've created a bare-bones test web app,
jndistring, with the following conf/server.xml configuration:
server.xml (snipped):
-
For the purpose of this test I've used jsp to access the value of teststring.
jndistring.jsp (snipped):
<%
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
String teststring = (String) envCtx.lookup("teststring");
out.println("teststring: " + teststring);
%>
Accessing this page throws an exception:
org.apache.jasper.JasperException: An exception occurred processing
JSP page /test.jsp at line 18
15: Context initCtx = new InitialContext();
16: Context envCtx = (Context) initCtx.lookup("java:comp/env");
17:
18: String teststring = (String) envCtx.lookup("teststring");
19: out.println("teststring: " + teststring);
20: %>
The top frame of the root cause is shown as:
javax.servlet.ServletException: javax.naming.NameNotFoundException:
Name teststring is not bound in this Context
If I attempt to create an environment entry resource using
(and sub-elements) within web.xml, then the resource is
created and I can access it!!!
I've read the "JNDI resources howto", docs regarding the ,
and elements (and others), but don't see
that I have missed anything.
Can anyone suggest what I might have missed? Has anyone else had
similar problems?
Thanks,
Paul.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with JNDI using a changed context root path
Thank you very much :). Deploying the application as ROOT.war solved all my problems ;) and in fact my parameters in the context.xml were useless. Am Montag, den 21.04.2008, 08:19 -0500 schrieb Caldarale, Charles R: > > From: Felix Schumacher [mailto:[EMAIL PROTECTED] > > Subject: Re: Problem with JNDI using a changed context root path > > > > Remember to move the corresponding context file as well, so move > > conf/Catalina/localhost/mywebapp.xml to > > conf/Catalina/localhost/ROOT.xml. > > The above .xml file is not always created; regardless, it should be > deleted, not just renamed, since it likely contains invalid attributes > from the previous deployment. > > > > My context.xml in the META-INF: > > > > > > > > You must remove both the path and docBase attributes - neither are > allowed and they are possibly messing up Tomcat's internal structures > during deployment. As Felix noted, rename your .war file to ROOT.war > (and remove Tomcat's default ROOT directory) in order to make it the > default webapp. > > > > > It's probably inappropriate to use the "warfilename" as part of JNDI > lookup, since the name of the .war file (and therefore the webapp) is > subject to change; use a fixed value, both there and in the code doing > the lookup. > > > > My context tag in the server.xml: > > > > > docBase="warfilename" > > > reloadable="true" /> > > You must not have the defined twice; I think the one in > server.xml will be overridden by the one in META-INF/context.xml, but > you should not count on it. For that matter, you should never place > elements in server.xml in modern versions of Tomcat. If you > absolutely insist on putting your in server.xml, the path for > the default app is an empty string "", not a slash. Read the doc: > http://tomcat.apache.org/tomcat-5.5-doc/config/context.html > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail > and its attachments from all computers. > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with JNDI using a changed context root path
> From: Felix Schumacher [mailto:[EMAIL PROTECTED] > Subject: Re: Problem with JNDI using a changed context root path > > Remember to move the corresponding context file as well, so move > conf/Catalina/localhost/mywebapp.xml to > conf/Catalina/localhost/ROOT.xml. The above .xml file is not always created; regardless, it should be deleted, not just renamed, since it likely contains invalid attributes from the previous deployment. > > My context.xml in the META-INF: > > > > You must remove both the path and docBase attributes - neither are allowed and they are possibly messing up Tomcat's internal structures during deployment. As Felix noted, rename your .war file to ROOT.war (and remove Tomcat's default ROOT directory) in order to make it the default webapp. > >> My context tag in the server.xml: > > > docBase="warfilename" > > reloadable="true" /> You must not have the defined twice; I think the one in server.xml will be overridden by the one in META-INF/context.xml, but you should not count on it. For that matter, you should never place elements in server.xml in modern versions of Tomcat. If you absolutely insist on putting your in server.xml, the path for the default app is an empty string "", not a slash. Read the doc: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI using a changed context root path
On Mon, April 21, 2008 10:55 am, Stefan Dirschnabel wrote: > Hi, > > I experience a problem changing the context root path of my Tomcat 5.5. > I deploy my application using a war file. Because the Application can > now only be accessed using www.url.de/warfilename I changed the context > root of my Tomcat. I just want the user to enter www.url.de to access > the application. In fact it works almost perfect. The "www.url.de" is > translated to the according subdirectory in the webapps folder and I can > see the website. If you want the user to access your webapp with www.url.de you should call your webapps context ROOT. You can achieve this by moving the webapp from webapps/mywebapp to webapps/ROOT. Remember to move the corresponding context file as well, so move conf/Catalina/localhost/mywebapp.xml to conf/Catalina/localhost/ROOT.xml. > > Almost, because my connection pooling which I realized with JNDI does > not work anymore. It's interesting that the JNDI Lookup (and so the > connection pooling) _still_ works if I use the old url > www.url.de/warfilename. Just the access via the new url does not work. > I get: > > javax.naming.NameNotFoundException: Name jdbc is not bound in this > Context > > My context.xml in the META-INF: > > > > maxActive="50" maxIdle="5" maxWait="1" >username="user" password="password" > driverClassName="com.mysql.jdbc.Driver" >url="jdbc:mysql://localhost/user" /> > This file is only here for use in deployment. It will be copied to conf/Catalina/localhost/webappname.xml. You should leave out the path Attribute, since it will be determined by the name of the file. > > > My context tag in the server.xml: > > docBase="warfilename" > reloadable="true" /> Context should be a file under conf/Catalina/localhost for each context/webapp you install. This file should have configured the database Resource, which you used above in META-INF/context.xml. HTH Felix > > > I really can't find the solution and searching the web for hours > (days?!) now. I also tested the usage of globalnaming resources in the > server.xml but no result - same problem. Shouldn't this be a familiar > use case ^^ > > > Regards > Stefan Dirschnabel > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with JNDI using a changed context root path
Hi, I experience a problem changing the context root path of my Tomcat 5.5. I deploy my application using a war file. Because the Application can now only be accessed using www.url.de/warfilename I changed the context root of my Tomcat. I just want the user to enter www.url.de to access the application. In fact it works almost perfect. The "www.url.de" is translated to the according subdirectory in the webapps folder and I can see the website. Almost, because my connection pooling which I realized with JNDI does not work anymore. It's interesting that the JNDI Lookup (and so the connection pooling) _still_ works if I use the old url www.url.de/warfilename. Just the access via the new url does not work. I get: javax.naming.NameNotFoundException: Name jdbc is not bound in this Context My context.xml in the META-INF: My context tag in the server.xml: I really can't find the solution and searching the web for hours (days?!) now. I also tested the usage of globalnaming resources in the server.xml but no result - same problem. Shouldn't this be a familiar use case ^^ Regards Stefan Dirschnabel - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with JNDI
Hallo
I solved the problem. It is embarrasing to me but in some cases I didn't
close the connection. So therefore I had this problem.
Thanks.
2006/2/3, Hans Sowa <[EMAIL PROTECTED]>:
>
> Hi
>
> I'm working on a webapplikation using JNDI to lookup for a database
> connection. Actually it works for several times and then it stopps and I
> don't get an connection. I analysed it and found out that Method
> getConnnection has a problem.
>
> Here is my code:
>
> protected Connection lookupJNDIConnection(final String resource) {
> InitialContext ic = null;
> try {
> System.out.println("will InitialContext");
> ic = new InitialContext();
> System.out.println("lookup nach comp/env");
> Context envContext = (Context) ic.lookup("java:/comp/env");
> System.out.println ("lookup.");
> DataSource ds = (DataSource) envContext.lookup(resource);
> System.out.println("return getconnection.");
> return ds.getConnection();
>
> } catch (Exception e) {
> e.printStackTrace();
> return null;
> }
> }
>
> I can see the out.println("return getconnection.") but the out.printlnafter
> that, in the method which calls the this method, are not visible.
>
> And for every sql statement I perform a lookup, get the connection,
> perform the sql statement and then close the connection. Has anyone an idea
> what the problem is?
>
> Thanks in advance.
>
> --
> mfg Hans Sowa
> mailto:[EMAIL PROTECTED]
--
mfg Hans Sowa
mailto:[EMAIL PROTECTED]
problem with JNDI
Hi
I'm working on a webapplikation using JNDI to lookup for a database
connection. Actually it works for several times and then it stopps and I
don't get an connection. I analysed it and found out that Method
getConnnection has a problem.
Here is my code:
protected Connection lookupJNDIConnection(final String resource) {
InitialContext ic = null;
try {
System.out.println("will InitialContext");
ic = new InitialContext();
System.out.println("lookup nach comp/env");
Context envContext = (Context) ic.lookup("java:/comp/env");
System.out.println("lookup.");
DataSource ds = (DataSource) envContext.lookup(resource);
System.out.println("return getconnection.");
return ds.getConnection();
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
I can see the out.println("return getconnection.") but the out.println after
that, in the method which calls the this method, are not visible.
And for every sql statement I perform a lookup, get the connection, perform
the sql statement and then close the connection. Has anyone an idea what the
problem is?
Thanks in advance.
--
mfg Hans Sowa
mailto:[EMAIL PROTECTED]
