[jUDDI-developers] RE: jUDDI Task: Log4j implementation of the Logger interface

[Steve Viens <sv...@steveviens.com>]

Alex, 

So I spent some time this morning and updated the Ant build script so
that it creates a juddi.war file.  The web.xml document needs some work
(I haven't touched it yet) but the basic directory creation, movement of
resources and 'jar' operation work so you do end up with a 'juddi.war'
file in the juddi-0.6 distribution directory. This can then be dropped
into the Tomcat webapps directory.

I have a statement and a question though. First, I added servlet.jar to
the lib directory so that the build would work - this does not get
bundled into the 'war' file.  Second, the WEB-INF/lib directory contains
the following jar files:

 axis.jar
 hsqldb.jar
 juddi.jar
 uddi4j.jar
 xerces.jar

I assume we also need 'log4j-core.jar' and possibly 'clutil.jar' and
'wsdl4j.jar'. Is that right? I ask because I noticed these two
additional libraries in my 2 month old axis installation. 

Am I correct?

Steve

PS: Anything additional should be added to the 'juddi/lib' directory -
the build.xml will pick them up and put them in the correct place.

PPS: I will add the appropriate 'LICENSE' documents to both the
'juddi/lib' and 'WEB-INF/lib' directories in the next day or two (once I
round them up).

-----Original Message-----
From: Alex Ceponkus [mailto:alex@ceponkus.org] 
Sent: Monday, January 21, 2002 11:22 AM
To: Steve Viens
Subject: RE: jUDDI Task: Log4j implementation of the Logger interface


> #1 understood ... still hate it :)

Yeah, drive me nuts also. :)  Although if we just had shell access to
the cvs tree, we could manually remove it.

> #2 yeah, but the log4j lib will need to be in the jUDDI WEB-INF 
> directory
for jUDDI to use it (per the new Servlet spec)

But the jUDDI WEB-INF is the same as the Axis WEB-INF.  If we distribute
a .war then it's less of a big deal, but the Axis code would have to
work with the log4j.jar that we bundle.  And if somebody follows the
'deploy jUDDI to existing Axis' instructions, it would be good to know
which versions of Axis we know that can happen on (alpha3 being our
target for now.)

Alex

RE: [jUDDI-developers] RE: jUDDI Task: Log4j implementation of the Logger interface

[Alex Ceponkus <al...@ceponkus.org>]

No objections, that's what I was also leaning towards .. leave them unless
we are really concerned about an additional 100k.

-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of Steve
Viens
Sent: Wednesday, January 23, 2002 9:17 AM
To: juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] RE: jUDDI Task: Log4j implementation of
the Logger interface


Ummmmm, I already added them (yesterday) just to be in the safe side. I
could remove them but I'd rather include them until we're sure we don't
need them (or want them).

Any objections?

:)

Steve

-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of Alex
Ceponkus
Sent: Tuesday, January 22, 2002 7:23 PM
To: juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] RE: jUDDI Task: Log4j implementation of
the Logger interface


> bundled into the 'war' file.  Second, the WEB-INF/lib directory
> contains the following jar files:
>
>  axis.jar
>  hsqldb.jar
>  juddi.jar
>  uddi4j.jar
>  xerces.jar
>
> I assume we also need 'log4j-core.jar' and possibly 'clutil.jar' and
> 'wsdl4j.jar'. Is that right? I ask because I noticed these two
> additional libraries in my 2 month old axis installation.

That's right .. log4j, clutil and wsdl4j also come with the latest Axis
(alpha 3.)  However we might not need to ship them all.  I just tried
removing clutil and wsdl4j, and then ran a quick find_business test
without problems.  I would need to dig a bit further about not bundling
clutil to see when it actually gets used.  It's a small jar (10k), so
probably not that big of a deal with shipping it.  wsdl4j on the other
hand might be a little safer to not ship.  I would need to look into it
further to make sure that somebody trying to access wsdl functionality
doesn't bring down
axis+juddi.  It's a 100k jar, not that large either .. do you think it's
worth checking to see if we really need it?

I don't see us needing WSDL support in the near term.  Even when we will
be adding 'wsdl support', that will probably mean letting UDDI entries
point to WSDL docs rather than generating WSDLs for jUDDI calls.  Does
anybody see a good reason for generating WSDLs for UDDI soap queries?  I
don't see anytime runtime negotiation going on .. UDDI clients and
servers know about the structure of UDDI soap responses and requests
ahead of time.

Alex


_______________________________________________
juddi-developers mailing list juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers


_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers

RE: [jUDDI-developers] RE: jUDDI Task: Log4j implementation of the Logger interface

[Steve Viens <sv...@steveviens.com>]

Ummmmm, I already added them (yesterday) just to be in the safe side. I
could remove them but I'd rather include them until we're sure we don't
need them (or want them).

Any objections?

:)

Steve

-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of Alex
Ceponkus
Sent: Tuesday, January 22, 2002 7:23 PM
To: juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] RE: jUDDI Task: Log4j implementation of
the Logger interface


> bundled into the 'war' file.  Second, the WEB-INF/lib directory 
> contains the following jar files:
>
>  axis.jar
>  hsqldb.jar
>  juddi.jar
>  uddi4j.jar
>  xerces.jar
>
> I assume we also need 'log4j-core.jar' and possibly 'clutil.jar' and 
> 'wsdl4j.jar'. Is that right? I ask because I noticed these two 
> additional libraries in my 2 month old axis installation.

That's right .. log4j, clutil and wsdl4j also come with the latest Axis
(alpha 3.)  However we might not need to ship them all.  I just tried
removing clutil and wsdl4j, and then ran a quick find_business test
without problems.  I would need to dig a bit further about not bundling
clutil to see when it actually gets used.  It's a small jar (10k), so
probably not that big of a deal with shipping it.  wsdl4j on the other
hand might be a little safer to not ship.  I would need to look into it
further to make sure that somebody trying to access wsdl functionality
doesn't bring down
axis+juddi.  It's a 100k jar, not that large either .. do you think it's
worth checking to see if we really need it?

I don't see us needing WSDL support in the near term.  Even when we will
be adding 'wsdl support', that will probably mean letting UDDI entries
point to WSDL docs rather than generating WSDLs for jUDDI calls.  Does
anybody see a good reason for generating WSDLs for UDDI soap queries?  I
don't see anytime runtime negotiation going on .. UDDI clients and
servers know about the structure of UDDI soap responses and requests
ahead of time.

Alex


_______________________________________________
juddi-developers mailing list juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers

RE: [jUDDI-developers] RE: jUDDI Task: Log4j implementation of the Logger interface

[Alex Ceponkus <al...@ceponkus.org>]

> bundled into the 'war' file.  Second, the WEB-INF/lib directory contains
> the following jar files:
>
>  axis.jar
>  hsqldb.jar
>  juddi.jar
>  uddi4j.jar
>  xerces.jar
>
> I assume we also need 'log4j-core.jar' and possibly 'clutil.jar' and
> 'wsdl4j.jar'. Is that right? I ask because I noticed these two
> additional libraries in my 2 month old axis installation.

That's right .. log4j, clutil and wsdl4j also come with the latest Axis
(alpha 3.)  However we might not need to ship them all.  I just tried
removing clutil and wsdl4j, and then ran a quick find_business test without
problems.  I would need to dig a bit further about not bundling clutil to
see when it actually gets used.  It's a small jar (10k), so probably not
that big of a deal with shipping it.  wsdl4j on the other hand might be a
little safer to not ship.  I would need to look into it further to make sure
that somebody trying to access wsdl functionality doesn't bring down
axis+juddi.  It's a 100k jar, not that large either .. do you think it's
worth checking to see if we really need it?

I don't see us needing WSDL support in the near term.  Even when we will be
adding 'wsdl support', that will probably mean letting UDDI entries point to
WSDL docs rather than generating WSDLs for jUDDI calls.  Does anybody see a
good reason for generating WSDLs for UDDI soap queries?  I don't see anytime
runtime negotiation going on .. UDDI clients and servers know about the
structure of UDDI soap responses and requests ahead of time.

Alex