RE: help with installing tomcat on unix

[Noel J. Bergman]

 (a) check the logs for any messages
 (b) you might want to use [EMAIL PROTECTED]

One possibility could be something else blocking that port.

--- Noel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

help with installing tomcat on unix

[K. A.]

Hi,
 
I'm trying to install tomcat on solaris. I followed the installation instructions 
including changing the server.xml and web.xml files. However, it still won't run. When 
I check the default webpage at the port number 8080 it says that page can not be 
displayed. Does anyone have any idea what else I'm missing?
 
Thanks.


-
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003

RE: Ontology-based portals - RDF, LDAP, Xindice (was: java@apache)

[Noel J. Bergman]

Henri Yandell wrote:
> Noel J. Bergman wrote:
> The next level up is a community. Noel uses the word ontology here,
> but even though I started using this, I don't understand what it is,
> so have gone with something simpler. Easy to s+r out. I've defined a
> community xml file:

You described a portal made of communities, and each community having a
name, logo, members, url, description, projects.

I'm not clear on how you intend to model the (virtual) containment.  For
example, the items you list for a community could also be for a project.
Some of that can be implemented by determining that community's members are
a superset of the union of its projects' members.  So asking the model for a
list of a community's members would be that superset.  But other things are
singleton's, e.g., a portal, a community and a project may each have a
descrpiption, logo, etc., but asking the model for the item would depend
upon which container you were looking at.

As for an ontology (http://dictionary.reference.com/search?q=ontology), we
could start thinking about how we might want to classify things: language,
implemented JSRs, implemented interfaces (e.g., a service provider for JNDI
or JavaMail), implemented RFCs (SMTP, S/MIME), client and/or server
interface (where applicable), etc.  We could also associate items with user
friendly classifications, such as web server, mail server, database server,
CMS, document processor, spreadsheet, etc., build upon the more precise
classifications.

See also: http://www.dmoz.org/Computers/Software/
  http://www.dmoz.org/Computers/
  http://www.daml.org/
  http://www.daml.org/ontologies/ontologies.html
  http://sol1.cps.unizar.es:5080/ANTARCTICA/SRS/

Making some sense?

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [License] for jars in CVS

[Erik Hatcher]

On Jan 2, 2004, at 2:10 PM, Craig R. McClanahan wrote:
You still need mechanisms to allow the developer to override the 
default
decisions checked in to the build scripts.  For nearly all of the 
"I've checked
in jars for the convenience of developers" packages I've evaluated for 
use fail
to allow such overrides, and hard code their build classpaths to point 
at the
checked in JARs only.
Well, we should address bad build file writing more than JAR's in CVS!  
:)  My build files follow this scheme 
 - and I 
have an Ant property for *each* JAR that can be easily overridden at 
many levels.

	Erik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [License] for jars in CVS

[Craig R. McClanahan]

Quoting Danny Angus <[EMAIL PROTECTED]>:

> 
> 
> 
> 
> > I see what you are saying, but why is this an issue only with OGNL? Is it
> because of license
> > incompatibilities? 'Cause there are other jars in CVS both Apache and
> non-Apache.
> Harish,
> 
> It isn't only an issue with OGNL, it is a general issue which has been
> bubbling away for months.
> In principle it is not good to have Jars in CVS. In practice it makes life
> much easier for many people.

It also makes it more difficult for many other people -- especially those that
need to integrate lots of open source projects (with overlapping dependencies)
together.  The goal here is to ensure that all the modules you want to create
are built with (and tested with) the *same* versions of the common
dependencies, not the ones whose jars happen to be checked in to CVS for that
particular module.

You still need mechanisms to allow the developer to override the default
decisions checked in to the build scripts.  For nearly all of the "I've checked
in jars for the convenience of developers" packages I've evaluated for use fail
to allow such overrides, and hard code their build classpaths to point at the
checked in JARs only.

> There are moves afoot to produce some kind of
> jar download site which would provide the convenience of automated
> downloads with Ant or Maven, and comply with licence issues, and not
> require jars to be in CVS, cvs is not great at handling binaries.
> 
> d.
> 

Craig McClanahan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [License] for jars in CVS

[Danny Angus]

> I see what you are saying, but why is this an issue only with OGNL? Is it
because of license
> incompatibilities? 'Cause there are other jars in CVS both Apache and
non-Apache.
Harish,

It isn't only an issue with OGNL, it is a general issue which has been
bubbling away for months.
In principle it is not good to have Jars in CVS. In practice it makes life
much easier for many people. There are moves afoot to produce some kind of
jar download site which would provide the convenience of automated
downloads with Ant or Maven, and comply with licence issues, and not
require jars to be in CVS, cvs is not great at handling binaries.

d.



***
The information in this e-mail is confidential and for use by the addressee(s) only. 
If you are not the intended recipient (or responsible for delivery of the message to 
the intended recipient) please notify us immediately on 0141 306 2050 and delete the 
message from your computer. You may not copy or forward it or use or disclose its 
contents to any other person. As Internet communications are capable of data 
corruption Student Loans Company Limited does not accept any  responsibility for 
changes made to this message after it was sent. For this reason it may be 
inappropriate to rely on advice or opinions contained in an e-mail without obtaining 
written confirmation of it. Neither Student Loans Company Limited or the sender 
accepts any liability or responsibility for viruses as it is your responsibility to 
scan attachments (if any). Opinions and views expressed in this e-mail are those of 
the sender and may not reflect the opinions and views of The Student Loans Company 
Limited.

This footnote also confirms that this email message has been swept for the presence of 
computer viruses.

**


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]