Bugzilla Bug 64795

I have created an ebuild for jboss version 4.0.0

This ebuild needs the following stuff looked into.
 - rebuild files/4.0.0/catalog with the latest dtds 
 - check the log4j config is ok from 3.2.x version with 4.x.x (works fine here)
 - Add a deploy directory to /var/lib/jboss ie applications and append it to the deploy search path in jboss

Reproducible: Always
Steps to Reproduce:

Created an attachment (id=40034) [details]
a tar of files relating to the jboss-4.0.0 ebuild

Created an attachment (id=40162) [details]
jboss 4.0.0 ebuild related files

Added an Applications folder outside of the /var/lib/jboss/[default all
minimal] directories and configured jboss to watch it as a deploy path.

Updated log4j.xml with settings from previous versions replacement config.

Installation with this ebuild worked flawlessly for me :)

Emerging it now...

Two comments so far:
1) Consider using the .tar.bz2 source package in SRC_URI as it saves a few MB over the .tar.gz version. Expecially useful for dialup users like me.
2) According to the specs at www.jboss.org, JBoss 4.0.0 needs at least a 1.4 JDK to run, while the ebuild proposed here has 1.3 listed in RDEPEND...

Played with it a little, provided ebuild works nicely here...

With which JVM are you testing?  I'm not sure that it matters, and it sure
shouldn't - but I had problems with this ebuild on my system.
The default jboss configuration wouldn't start up at all.
I haven't had time to track down why not just yet.
I'm using the Sun JDK 1.4.2.06 on my system.

I'm using dev-java/sun-j2sdk-1.4.2, compiled with NPTL turned on...

When I try the attached 4.0.0 port on my system (a fresh install, no prior
jboss 
install), I get some carnage starting like:

2004-12-23 12:16:06,598 INFO  [org.jboss.web.WebService] Using RMI server
codebase: http:
//camus:8083/
2004-12-23 12:16:06,725 ERROR [org.jboss.system.pm.AttributePersistenceService]
Starting
failed jboss:service=AttributePersistenceService
java.lang.Exception: The base directory is not valid:
/usr/share/jboss/server/default/dat
a/xmbean-attrs
        at
org.jboss.system.pm.XMLAttributePersistenceManager.initDataDir(XMLAttributePer
sistenceManager.java:642)
        at
org.jboss.system.pm.XMLAttributePersistenceManager.create(XMLAttributePersiste
nceManager.java:165)

The VM I'm using is:

java version "1.4.2-01"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-01)
Java HotSpot(TM) Client VM (build Blackdown-1.4.2-01, mixed mode)

I need to get this resolved before finally committing to the tree.

Yeah, that was it.  I was seeing the same problem
as described in comment #8.

Works for me, no problems here!

Dominik, When you say it works for you, are you saying it works for you from a
fresh install? (ie. no prior JBoss or JBoss configs, server directories etc.)

Hi Matthew, yes that is correct. I did not have anything related to JBoss
installed before.

Can we go ahead and get this into portage as an unstable build?  Or at the very
least, masked?

So, here's some more information for the pile that is building up...

I unmerged jboss, and blew away anything relevant from a 'locate jboss'
output.  This included getting rid of /etc/conf.d/jboss, /etc/init.d/jboss,
and /etc/env.d/50jboss.  I also deleted group jboss and user jboss
(/etc/group & /etc/passwd modifications).
I was reasonably certain that all traces of jboss were gone from my system.
(oh yes - I blew away /var/log/jboss as well).

Then, I emerged jboss-4.0.0 again.
And I'm still seeing the same problem as in comment #8.

Additionally, I'll add that the directory /usr/share/jboss/server/default
does not exist on my system.

Ok, I took the time to track down the problem that I was having.
It amounted to an unexpected directory in the /usr/share/jboss/server
directory - "standard".  If you look in the first ebuild, you'll see that the
script mv's the various servers {all,default,minimal} to /var/lib/jboss.  But
leaves behind standard.  Then, the rmdir fails.  Then, the dosym doesn't work
the way the ebuild expects.

So, I simply modified the ebuild to also mv the standard server.
Then, after an emerge using this new ebuild - I now have a "default" jboss
server running on my system, with no errors or exceptions.
I'll attach the modified ebuild in a moment.

Created an attachment (id=48226) [details]
The modified 4.0.0 ebuild.

I installed Jboss 4.0.1 by altering the name of ebuild file. It worked
perfectly for me. I also did a copy/paste on the directory name files/4.0.0 to
files/4.0.1 not sure if I had to do that tho 8-). Could somebody plz do the
same to verify this ebuild file and put it into the portage tree 

This latest ebuild for JBoss 4.0 does not work for me. I get an abort with 17
errors. First one is this:

/var/tmp/portage/jboss-4.0.0/work/jboss-4.0.0-src/varia/src/main/org/jboss/jmx/adaptor/snmp/agent/TrapEmitter.java:44:
package org.jboss.jmx.adaptor.snmp.config.manager does not exist

This is a clean system with no prior JBoss installation (gcc 3.3.5)

*** Bug 79276 has been marked as a duplicate of this bug. ***

I've started work on an ebuild for jboss-4.0.2, using the ebuild I'm using over
at  bug #63258 as a base.

Fortuntately, there are significantly fewer dependencies that aren't in portage,
compared to 3.2.7. I hope to file requests for the remaining packages in the
next few days.

I just made bugs for all the dependencies not in portage yet, and added them as
dependencies for this bug.

In the past few months, I've done a good amount of work on getting jboss into
portage. There have been some complications. In particular, some of jboss's
dependencies rely on other jboss jars.

This is because jboss is separated into a number of modules. For example, the
hibernate module requires hibernate-3, which in turn depends on jboss-cache.jar.

To solve this, I've taken to separating jboss into its separatable components,
which are in fact able to be built separately. There's a lot of legwork
involved, but I've been able to simplify the build process through the power of
an eclass and some bash sorcery.

Another hurdle is that a few of the dependencies use maven to build, and maven
is a PITA to deal with from the perspective a packager. There are some maven
plugins to yield an equivilant ant script, but I haven't had the
time/energy/inclination to get both maven and the plugin (JAM I believe its
called) working.

That being said, I'm maintaining said module ebuilds and dependencies in the
Java experimental overlay (http://gentoo-wiki.com/Experimental_Java_tree).
Sometime in the near future, I hope to work with the Java devs to get the
dependencies into the official.

To be able to install jboss-4.0.2 I just loaded the latest ebuild for version
4.0.0 attached to this report 
into www-servers/jboss in my portage overlay and moved it to
jboss-4.0.2.ebuild. Then I created the 
related digest file and emerged the package.

Since the server was refusing to startup saying that the JBOSS_HOME variable
was not set I examined /
etc/conf.d/jboss and came across the line which is responsible for grepping a
JBOSS_HOME entry in /
etc/profile.env.
This entry was missing, so I created it like that:
echo "export JBOSS_HOME=/usr/share/jboss" >> /etc/profile.env

Probably adding this line to the ebuild would fix this issue.

Just a note: the jboss-server ebuild in the experimental overlay IS NOT the
jboss server, despite what its name suggests. It is actually the jboss 'server'
module. To avoid confusion, I will probably rename all the jboss-* to
jboss-module-* for clarity.

Has anyone tried it with 4.0.3?

yes, seems to be working fine for 4.0.3 - can we get a status update on when
something from the 4.0 branch will be in the tree?

I've been keeping the status in the experimental overlay at
http://gentooexperimental.org/svn/java/gentoo-java-experimental/TODO.nichoj
under the JBoss section.

To summarize, 2 modules still need to be packaged, out of some 30. One is
getting some compile errors that I can't figure out (jboss-module-varia), and
the other depends on the first (jboss-module-console).
 
When all the modules are done, we need to basically put them all together into
like a normal JBoss install. Also, I think we may be able to go ahead with the
modules we currently have, because I believe jboss has 3 'profiles', ie minimal,
default, and all. So, we could probably do minimal and default, and wait to do
all once the others modules have been packaged.

Additionally, the eclass used to do these modules could use some serious cleanup
and documenting.

As to when to expect something in portage... I wouldn't hold your breath :-/
First of all, a large number of dependencies are still just in the experimental
overlay. Second, the eclass and module ebuilds need testing. And thirdly, the
Java herd is severly lacking in personel. In addition to that, the primary
concern is getting things ready for 1.5 (bug 65937). 

Created an attachment (id=94989) [details]
ebuild for jboss-4.0.4.GA

This is a modified jboss-4.0.1.ebuild from
http://svn.ipforensics.org/repos/portage/www-servers/jboss
In order to use this, you need to run "cp -a 4.0.1 4.0.4" (or just link them)
in the files directory.

Please find the latest jboss ebuild in overlay:
http://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/www-servers/jboss/

Today, xerces-2.6 was moved into own slot. This should solve your problem when
one part of jboss doesn't build with any higher version, and not cause
upgrade/downgrade loops. Just make the dep as =xerces-2.6* and use '..jar-from
xerces-2.6'. Should probably keep it consistent through all relevant ebuilds
and eclass, so you don't get two different versions of xerces on classpath (not
sure what would happen then :) I've upgraded all deps in portage and overlays
but left jboss to you, minions :)

*** Bug 179822 has been marked as a duplicate of this bug. ***

*** Bug 181240 has been marked as a duplicate of this bug. ***

Closing bug. Removed from tree, till we get a maintainer and current version
from source.