My guess is that is Jetspeed's database connection and therefore not
the one you want to use. Jetspeed can be configured to store data a
number of ways including in an embedded Derby database (flat files).
You'll want to declare your own JNDI database connection in
{tomcat_dir}/conf/Catalina/conf/context.xml.
On Fri, Apr 18, 2008 at 5:15 PM, Dan Olsen <[EMAIL PROTECTED]> wrote:
> I see that Jetspeed created a jetspeed.xml file in
> {tomcat_dir}/conf/Catalina/localhost/jetspeed.xml. This looks like it
> declares a the resource for a JNDI connection. However when I try to access
> it I get the error:
>
> javax.naming.NameNotFoundException: Name jdbc is not bound in this Context.
>
> How can I get Tomcat to pick up that jetspeed.xml context file? I figure if
> that file is put there by Jetspeed then it should be accessible and I should
> be able to access the JNDI connection.
>
> >>> "Andrew Strickland" <[EMAIL PROTECTED]> 4/18/2008 1:55 PM >>>
>
>
> This can be done a number of ways in Java. Depending on the web
> server you're using you might even be able to configure this there.
> For instance, Weblogic allows you to create and configure JNDI
> connection pools through it's web console. Your code then only ever
> needs to reference the JNDI name to lookup the connection pool. All
> other database connection info is handled by the JNDI connection pool
> within Weblogic. Thus giving you the single point of configuration /
> maintenance you would like.
>
> Alternatively you can configure your database connection using
> Spring...referencing your connection through beans and such. I'm not
> that familiar with this option. Spring has it's own set of XML
> configuration files you'd need to define the JNDI and connection pool
> info in.
>
> Tomcat allows you to define a JNDI database connection in the
> context.xml file. The implementation is much the same as Weblogic
> where you look up the connection using the JNDI name but Tomcat has no
> web console to configure this for you, you do it by hand in the
> context.xml file.
>
> On Fri, Apr 18, 2008 at 3:49 PM, Dan Olsen <[EMAIL PROTECTED]> wrote:
> > How about when talking to the database? All the portlets will be talking
> to the same database and I don't want to have to change all the portlets code
> to point to the new production database. Is there a way I can define the
> database properties and use that and make it so I only have to update the
> database information in one place? Something like a preferences file?
> >
> > I'm new to Java web programming so I'm not sure how this is all done. I
> know with PHP I could just have a config file where I can read the
> information from. I'd like to do something like that in Java with my portlets.
> >
> > >>> "Andrew Strickland" <[EMAIL PROTECTED]> 4/18/2008 1:44 PM >>>
> > Don't have time to post examples but...
> >
> > Using a form on the edit page shouldn't be any different than using a
> > form on the view or help page. I've done it and there's really
> > nothing exceptional. Just handle the form submission in your
> > portlet's processAction method.
> >
> > You can put a hidden input into your form with a name like "action"
> > and give it a value of "edit" or "save" so that you can differentiate
> > between which portlet page the submission is coming from. There might
> > be better ways to do that but this way is easy and simple.
> >
> > The way I use the edit page is as the page that can modify the portlet
> > preferences. So any form submission from the edit page is a change to
> > a preference which the portlet then makes use of Jetspeed's
> > preference database to store.
> >
> > On Fri, Apr 18, 2008 at 3:36 PM, Dan Olsen <[EMAIL PROTECTED]> wrote:
> > > Does anyone know of any example portlets that use forms in the Edit
> window state and the new information from the form is then stored in a
> database? I need to do this for my project and I'm looking for some best
> practices on how to do this.
> > >
> > > - Dan
> > >
> >
> > ---------------------------------------------------------------------
> > 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]
