JBoss4 installation weirdness

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

JBoss4 installation weirdness

Panagiotis Astithas
As I found out the hard way today, jboss4 installs different things
depending on whether it is being built using jdk14 or jdk15. In the
latter case you get EJB3 stuff that (unfortunately for me) include old
versions of commons-stuff which may create conflicts with a deployed
app, thanks to the funky jboss classloader architecture. The binaries
that jboss.com ships evidently contain stuff that you get when you build
with jdk14.

I'm not sure if it is possible or even reasonable to change the current
behavior (I'm overriding JAVA_PREFERRED_PORTS), but perhaps we could add
an informative message when building the port to inform the user.


Cheers,
Panagiotis
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: JBoss4 installation weirdness

Herve Quiroz-2
Hi Panagiotis,

On Mon, Dec 05, 2005 at 02:01:11PM +0200, Panagiotis Astithas wrote:
> As I found out the hard way today, jboss4 installs different things
> depending on whether it is being built using jdk14 or jdk15. In the
> latter case you get EJB3 stuff that (unfortunately for me) include old
> versions of commons-stuff which may create conflicts with a deployed
> app, thanks to the funky jboss classloader architecture. The binaries
> that jboss.com ships evidently contain stuff that you get when you build
> with jdk14.

I don't know much about JBoss 4 but the common practice when ports
install different stuff depending on JDK version is to use a
PKGNAMESUFFIX to indicate the JDK version used (e.g. '-jdk14').
java/openjit is one good example.

> I'm not sure if it is possible or even reasonable to change the current
> behavior (I'm overriding JAVA_PREFERRED_PORTS), but perhaps we could add
> an informative message when building the port to inform the user.

I can think of two approaches here. Either we disallow Java 1.5 (since
there seems to be trouble with it anyway, as you describe above), or we
could just enforce JAVA_VERSION?=1.4 and let the user know that he may
override JAVA_VERSION if he wants another JDK version. Indeed users
don't always read the messages from the install log and the JDK that is
picked up does not only depends on JAVA_PREFERRED_PORTS (it also depends
on the JDKs that are installed at the time you install a port). So I
think it's better to enforce a known-to-be-stable flavor of the port and
allow the users who know what they do to request a different flavor.

I also wondering what could happen if you use java/jdk15 to build the
port and then java/jdk14 to run it... In case this causes trouble, it
would confirm the fact that we need to enforce either "1.4" or "1.5"
(thus no "1.4+").

Herve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: JBoss4 installation weirdness

Panagiotis Astithas
Herve Quiroz wrote:

> Hi Panagiotis,
>
> On Mon, Dec 05, 2005 at 02:01:11PM +0200, Panagiotis Astithas wrote:
>
>>As I found out the hard way today, jboss4 installs different things
>>depending on whether it is being built using jdk14 or jdk15. In the
>>latter case you get EJB3 stuff that (unfortunately for me) include old
>>versions of commons-stuff which may create conflicts with a deployed
>>app, thanks to the funky jboss classloader architecture. The binaries
>>that jboss.com ships evidently contain stuff that you get when you build
>>with jdk14.
>
>
> I don't know much about JBoss 4 but the common practice when ports
> install different stuff depending on JDK version is to use a
> PKGNAMESUFFIX to indicate the JDK version used (e.g. '-jdk14').
> java/openjit is one good example.
Right. Then again that has bitten people occasionally when portupgrading
using packages. IIRC, the right package cannot be found automatically.

>>I'm not sure if it is possible or even reasonable to change the current
>>behavior (I'm overriding JAVA_PREFERRED_PORTS), but perhaps we could add
>>an informative message when building the port to inform the user.
>
>
> I can think of two approaches here. Either we disallow Java 1.5 (since
> there seems to be trouble with it anyway, as you describe above), or we
> could just enforce JAVA_VERSION?=1.4 and let the user know that he may
> override JAVA_VERSION if he wants another JDK version. Indeed users
> don't always read the messages from the install log and the JDK that is
> picked up does not only depends on JAVA_PREFERRED_PORTS (it also depends
> on the JDKs that are installed at the time you install a port). So I
> think it's better to enforce a known-to-be-stable flavor of the port and
> allow the users who know what they do to request a different flavor.
>
> I also wondering what could happen if you use java/jdk15 to build the
> port and then java/jdk14 to run it... In case this causes trouble, it
> would confirm the fact that we need to enforce either "1.4" or "1.5"
> (thus no "1.4+").
Enforcing jdk14 would be in accordance with the official policy (from
JBoss Inc.), as I understand it. Unfortunately the current port suffers
from another issue I have mentioned a while ago. Since it uses jboss4ctl
to control the service, the jdk path gets hardcoded into the executable
when building it. This forces the use of the same jdk to run the service
as the one it was built with. This way however you can't deploy jdk15
applications if you build jboss with jdk14. For the time being I'm using
the attached startup scripts, copied from your tomcat55 one. IIRC, you
were going to look into it, so they may be useful as a starting point.
Some things don't work right though, like the 'status' command.

On the other hand I kinda like the fact that I can get the full jboss4
server with ejb3, annotations and whatnot, with just a recompilation. If
we remove this functionality (granted, I just found out that it existed)
we should replace it with a build option or a slave port (that enforces
jdk15). Currently there is no other way to get this functionality from
the ports collection, you have to get the extra bundles from the
vendor's site.

I'm CCing Jonathan, since he may be already aware of all this.


Regards,
Panagiotis


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: JBoss4 installation weirdness

Jonathan Chen
In reply to this post by Panagiotis Astithas
On Mon, Dec 05, 2005 at 02:01:11PM +0200, Panagiotis Astithas wrote:
> As I found out the hard way today, jboss4 installs different things
> depending on whether it is being built using jdk14 or jdk15. In the
> latter case you get EJB3 stuff that (unfortunately for me) include old
> versions of commons-stuff which may create conflicts with a deployed
> app, thanks to the funky jboss classloader architecture.

Have you tried tweaking the config for conf/jboss-service.xml and
deploy/ear-deployer.xml as described in:

    http://docs.jboss.com/jbossas/whatsnew40/html/

See if this fixes your class-loading problems.

Cheers.
--
Jonathan Chen <[hidden email]>
----------------------------------------------------------------------
                                         "Nyuck, nyuck, nyuck" - Curly
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: JBoss4 installation weirdness

Panagiotis Astithas
Jonathan Chen wrote:

> On Mon, Dec 05, 2005 at 02:01:11PM +0200, Panagiotis Astithas wrote:
>
>>As I found out the hard way today, jboss4 installs different things
>>depending on whether it is being built using jdk14 or jdk15. In the
>>latter case you get EJB3 stuff that (unfortunately for me) include old
>>versions of commons-stuff which may create conflicts with a deployed
>>app, thanks to the funky jboss classloader architecture.
>
>
> Have you tried tweaking the config for conf/jboss-service.xml and
> deploy/ear-deployer.xml as described in:
>
>     http://docs.jboss.com/jbossas/whatsnew40/html/
>
> See if this fixes your class-loading problems.
>
> Cheers.

Thanks, this seems to fix my class-loading issues (although such a
workaround didn't use to work on jboss3). So if the problem with the
startup script (hardcoded jdk path in the executable) gets resolved, we
can keep building the ejb3, aop, annotations, etc. stuff if the proper
jdk is used when building. It's almost like having your cake and eating
it too :-)

Thanks,
Panagiotis
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "[hidden email]"