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 attachment 40034 [details] a tar of files relating to the jboss-4.0.0 ebuild
Created attachment 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 attachment 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 attachment 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.
