You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by Steve Viens <st...@viens.net> on 2004/06/14 06:09:07 UTC

jUDDI 0.9rc1 Available

I've built version 0.9rc1 and made it available via jUDDI's 'releases'
page:
 
  http://ws.apache.org/juddi/releases.html
 
I have not yet labeled CVS and would like to asap however I'd first like
a few volunteers to validate that the releases are in good working
order. Simply installing and testing jUDDI from the binary distribution
(juddi-0.9rc1.zip or .tar.gz) will suffice. Please refrain from making
changes to CVS until I give the word. Probably in a day or so.
 
Thanks,
 
Steve Viens
steve@viens.net

RE: jUDDI 0.9rc1 Available

Posted by Steve Viens <st...@viens.net>.
Antoni brings up a good point here.  What's the most appropriate way to
access and update property values used by a webapp which may be deployed
either exploded or as a war file?

1. Placing the juddi.properies file in the classpath worked but didn't
make it easily accessible if it needed to be altered when deploying
jUDDI as a war file. 

2. Placing the juddi.properties file in the WEB-INF directory also isn't
a great idea for the reasons mentioned in Antoni's note below.

We don't actually need a juddi.properties file - we can keep these
properties in other locactions.  So far I've avoided placing property
values in the database/DataSource simply because the dataStore to use is
identified by the property juddi.dataStore.  However this may be a more
appropriate place for them - especially in a clustered deployment since
the properties used by all instances of jUDDI would need to be updated
at the same time.

Would reading properties from <context-param> elements from web.xml be
more appropriate? Instead of using a juddi.properties file these values
would look like this:

  <context-param>
    <param-name>juddi.auth</param-name>
 
<param-value>org.apache.juddi.auth.DefaultAuthenticator</param-value>
  </context-param>

  <context-param>
    <param-name>juddi.dataStore</param-name>
 
<param-value>org.apache.juddi.datastore.jdbc.JDBCDataStore</param-value>
  </context-param>

  (..etc..)

Antoni also mentioned that jUDDI attempts to create a juddi.properties
file on startup if one doesn't exist (see the init method of the
RegistryServlet). I've added this functionality recently because in the
immediate future I'd like to implement a web-based admin interface that
supports ability to configure/update these property values.

Thoughts?

Steve

-----Original Message-----
From: Antoni Reus [mailto:areus@lavila.org] 
Sent: Monday, June 14, 2004 2:08 AM
To: juddi-dev@ws.apache.org
Subject: Re: jUDDI 0.9rc1 Available


The new configuration code fails if the war is not exploded. The problem
is 
the use of ServletContext.getRealPath(String), that can return null if
the 
container for any reason cannot return the path (for example in war
files). I 
think this should be noted in the release notes.

Also, writing the configuration file if it doesn't exist is not a very
good 
practice, and is likely to fail under some containers.

Salut!

-- Antoni Reus

El Lunes, 14 de Junio de 2004 06:09, Steve Viens escribió:
> I've built version 0.9rc1 and made it available via jUDDI's 'releases'
> page:
>
>   http://ws.apache.org/juddi/releases.html
>
> I have not yet labeled CVS and would like to asap however I'd first 
> like a few volunteers to validate that the releases are in good 
> working order. Simply installing and testing jUDDI from the binary 
> distribution (juddi-0.9rc1.zip or .tar.gz) will suffice. Please 
> refrain from making changes to CVS until I give the word. Probably in 
> a day or so.
>
> Thanks,
>
> Steve Viens
> steve@viens.net




Re: jUDDI 0.9rc1 Available

Posted by Antoni Reus <ar...@lavila.org>.
The new configuration code fails if the war is not exploded. The problem is 
the use of ServletContext.getRealPath(String), that can return null if the 
container for any reason cannot return the path (for example in war files). I 
think this should be noted in the release notes.

Also, writing the configuration file if it doesn't exist is not a very good 
practice, and is likely to fail under some containers.

Salut!

-- Antoni Reus

El Lunes, 14 de Junio de 2004 06:09, Steve Viens escribió:
> I've built version 0.9rc1 and made it available via jUDDI's 'releases'
> page:
>
>   http://ws.apache.org/juddi/releases.html
>
> I have not yet labeled CVS and would like to asap however I'd first like
> a few volunteers to validate that the releases are in good working
> order. Simply installing and testing jUDDI from the binary distribution
> (juddi-0.9rc1.zip or .tar.gz) will suffice. Please refrain from making
> changes to CVS until I give the word. Probably in a day or so.
>
> Thanks,
>
> Steve Viens
> steve@viens.net