On Fri, 2003-01-17 at 22:28, Andrew Savory wrote:
> On Tue, 14 Jan 2003, Joe Phillips wrote:
>
> > I spent yesterday rebuilding and testing my debs. The versions
> > currently on my company site[1] have been tested to properly start/stop
> > the server without exceptions.
>
> Just been trying the debs out (apt-get install jboss jboss-doc), and came
> across the following problems:
I'm glad to see interest. I'm also glad to get feedback.
I'm assuming the above are the only packages you installed (jboss and
jboss-doc) - you're definitely missing some files then. It would
explain bad permissions and missing files as you found...
> log4j:ERROR setFile(null,false) call failed.
> java.io.FileNotFoundException: /usr/share/jboss/server/default/log/boot.log
>(Permission denied)
>
> (Fixed by chown -R jboss /usr/share/jboss)
Actually, not fixed by that command. /usr/share/jboss/server/default is
not found in jboss or jboss-doc packages.
> org.jboss.deployment.DeploymentException: url
> file:/usr/share/jboss/server/default/conf/jboss-service.xml could not be opened,
>does it exist?
>
> (Fixed by apt-get install jboss-server-all, then editing
> /etc/default/jboss and setting which server to start to "all")
See above comment.
> After all that, there's still no sign of life from JBoss on 8080 or
> 8082... :-(
I expect that you would see jboss on 8080 after installing
jboss-server-all and editing /etc/default/jboss. You didn't mention but
I hope you set your JAVA_HOME properly within /etc/default/jboss?
This is likely to be a long email so bear with me...
I just now installed my packages on my laptop, a machine on which I have
never installed these packages. Here's what I did (kindof following
your general steps) to get jboss up on 8080.
1- apt-get install jboss-server-all
this brings in jboss, libjboss3-java, libjboss3-client-java,
jboss-tomcat
2- edit /etc/default/jboss
- set JAVA_HOME to my j2sdk 1.4.1 installation
- set server to 'all'
- enabled (uncommented) console output to /var/log/jboss/console.log
3- start jboss with /etc/init.d/jboss start
waited until I saw the following in /var/log/jboss/console.log...
23:42:25,611 INFO [Server] JBoss (MX MicroKernel) [3.0.2
Date:200209111840] Started in 0m:51s:521ms
4- hit http://localhost:8080/jmx-console with my browser
My system is Debian stable with Ximian GNOME packages, custom 2.4.18
kernel package, and custom Sun j2sdk-1.4.1 packages.
<sidebar>
I'm going to cover details on how the packages are put together and what
motivated my decisions, I'm happy to take comments and feedback. I'm
also assuming the reader has some experience installing and running
JBOSS from a binary distribution.
</sidebar>
The thing to note here is that the 'jboss' package isn't the full JBOSS
and neither is 'jboss-server-all'. In order to get the *whole* JBOSS as
distributed on sourceforge, with minor changes, you need to install all
the jboss-server-X packages (where X is all, default and minimal). Each
is installed under a /usr/share/jboss/server/X directory.
This is how a JBOSS zip/tarball installs by default. Unfortunately, I
can see where 'jboss-server-all' would be confusing.
Generally, you would only want one of those packages. By default, the
packages come configured to attempt to run the 'default' server. You
saw this in your error messages. This is also why installing
jboss-server-all (and not changing /etc/default/jboss) doesn't fix the
errors you saw.
Each of the jboss-server-X packages' postinstall scripts takes care of
properly setting ownership and permissions on /usr/share/jboss/server/X
files. Also, some of the directories or files under
/usr/share/jboss/server/X are symlinks to more Debianized locations (eg
/var/log/jboss/X or /etc/jboss/X) to be more in line with Debian policy.
It comes down to, in general, you want jboss-server-minimal,
jboss-server-default or jboss-server-all installed. /etc/default/jboss
needs to have the server set appropriately to match which server you
wish to run.
My jboss package recommends one of the above three packages but apt-get
won't force you to install a recommended package. I chose not to depend
on the server packages because you *can* use jboss without them, if you
build your own jboss-server equivalent package. In fact, this is what
my company is doing in production. We have a jboss-server-isg package
which is essentially a tweaked jboss-server-default. Our custom server
package installs under /usr/share/jboss/server/isg/ and requires us to
set JBOSS_SERVER=isg in /etc/default/jboss.
Originally, I considered creating a single server directory, say
/usr/share/jboss/server/default/ removing the all and minimal
directories. I figured all jboss-server-X packages could install there,
with minimal being a subset of default being a subset of all. I'm not
so sure they're strictly subsets though. I also figured that developers
familiar with the three servers in jboss already may be confused or
hindered by the inflexibility of a single server directory. What we
have today is a pretty true to out of the box JBOSS installation -
including the three server directories, each found in jboss-server-X
packages.
I'm not totally satisfied with what we have but it's a start. We can
always improve on it.
Part of the problem seems to me that JBOSS packages will almost always
need to be customized in some way. The deploy directories seem to
include both software 'libraries' as well as configurations in XML
files.
Should the whole contents of a server directory be treated as
configuration files?
Another problem with the current layout is it's difficult to package
J2EE software to work with my JBOSS packages due to the fact that you
never know which server the user is running. Should the application be
installed in all, minimal, default or somewhere else? hmm...
I guess I'll make sure the README.Debian file for the jboss package
mentions the server packages. If we keep the three server layout (I'm
starting to think we don't want to), maybe a task-jboss-server or
jboss-full package would be helpful?
I definitely want suggestions on what the best way to deal with servers
in our jboss packages would be.
-joe
--
Innovation Software Group, LLC - http://www.innovationsw.com/
Business Automation Specialists
UNIX, Linux and Java Training
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
