Simple way to use a lib/jar in MDB app in a Thorntail uberJar

[fwelland]

Env:   Thorntail 2.6.0.Final  +  activemq-rar.rar (to external broker) + java 1.8 + gradle 6 & gradle thorntail plugin. 

It is pretty simple to make an MDB class  (MessageListener impl with @MessageDriven annotations)  that can get a message and print  helloWorld or something trivial like that.....

...But when said MDB goes to do 'real' stuff, using a jar/lib for example, the Thorntails MDB uberJar cannot see classes that are NOT part of 'project' (that is, source is just part of the core project contains source of said MDB).

Take simple case of an onMessage method in the MessageListener impl that uses some string/text method/class from 'org.apache.commons:commons-text:1.8':   at runtime, while service the onMessage() method is running, I'd get java.lang.NoClassDefFoundError errors for any lib reference.    

In an JBOSS/EAP or Wildfly deploy; i'd just shove an mdb.jar (with my code) in an EAR and deps jar in the EAR/lib and deploy that.   (Maybe you guessed, but what I am doing is decomposing a general purpose, HUGE jboss instance with lots of MDB ears into more purpose oriented message processors via Thorntail). 

Well, IFAIK, Thorntail really won't take an EAR.   

I can totally see that my TT uberjar  contains an m2repo that does indeed have the jars I need in it.    It is just that the loader that is running my MDB doesn't really have access to them. 

What is good way, and simple, way to make these libs available to the MDB class? 

------

Thought & Things I have tried: 

• added MANIFEST.MF  Class-Path attribute    --  still NoClassDef at run time
• added MANIFEST.MF   Dependencies  attribute  -- TT jar wouldn't start, 'cause at deploy time it couldn't resolve the dependency (just tried jar name, and g:a:v syntax -- this seems to be for JBOSS/WF modules?  Not sure I want to make every lib I possibly use a module seems like too much effort)
• [idea] make my own uberJar contain my MDB classes and its deps, collapsed;  and then have thorntail (& gradle plugin) make an runnable jar out of this uberJar 
• [idea] use war packaging (that seems to allow & use  /lib)   -- this is hokie as I don't want to then spend time shutting down lots of http listerners that I don't need
• [idea] ask this group and hope for a good simple answer
• [idea] maybe make a hollow thorntail.jar that can do MDB to external brokers and just write an old fashion .sh start script with classpath stuff pointing to my deps...
• [idea] ???

[Ladislav Thon]

Hi,

I'm afraid there's no simple way to add arbitrary dependencies to a JAR deployment. At least not that I'm aware of. 

Few more remarks inline.

On 15. 01. 20 21:59, fwelland wrote:

Env:   Thorntail 2.6.0.Final  +  activemq-rar.rar (to external broker) + java 1.8 + gradle 6 & gradle thorntail plugin. 

It is pretty simple to make an MDB class  (MessageListener impl with @MessageDriven annotations)  that can get a message and print  helloWorld or something trivial like that.....

...But when said MDB goes to do 'real' stuff, using a jar/lib for example, the Thorntails MDB uberJar cannot see classes that are NOT part of 'project' (that is, source is just part of the core project contains source of said MDB).

Take simple case of an onMessage method in the MessageListener impl that uses some string/text method/class from 'org.apache.commons:commons-text:1.8':   at runtime, while service the onMessage() method is running, I'd get java.lang.NoClassDefFoundError errors for any lib reference.    

In an JBOSS/EAP or Wildfly deploy; i'd just shove an mdb.jar (with my code) in an EAR and deps jar in the EAR/lib and deploy that.   (Maybe you guessed, but what I am doing is decomposing a general purpose, HUGE jboss instance with lots of MDB ears into more purpose oriented message processors via Thorntail). 

Well, IFAIK, Thorntail really won't take an EAR.

Correct, Thorntail doesn't support EARs.

I can totally see that my TT uberjar  contains an m2repo that does indeed have the jars I need in it.    It is just that the loader that is running my MDB doesn't really have access to them. 

What is good way, and simple, way to make these libs available to the MDB class? 

------

Thought & Things I have tried: 

• added MANIFEST.MF  Class-Path attribute    --  still NoClassDef at run time
• added MANIFEST.MF   Dependencies  attribute  -- TT jar wouldn't start, 'cause at deploy time it couldn't resolve the dependency (just tried jar name, and g:a:v syntax -- this seems to be for JBOSS/WF modules?  Not sure I want to make every lib I possibly use a module seems like too much effort)

Correct, the `Dependencies` attribute in the manifest is supposed to contain names of JBoss Modules modules.

Creating a module in Thorntail shouldn't be that hard (look into WildFly's modules/system/layers/base and replicate the directory structure under src/main/resources/modules; it should be possible to use Maven coordinates in the module.xml, instead of adding a JAR file).

• [idea] make my own uberJar contain my MDB classes and its deps, collapsed;  and then have thorntail (& gradle plugin) make an runnable jar out of this uberJar

I think that might be one of the easier ways. I don't really know Gradle, so not sure.

• [idea] use war packaging (that seems to allow & use  /lib)   -- this is hokie as I don't want to then spend time shutting down lots of http listerners that I don't need

This would probably be easiest. It should be possible to remove the HTTP listeners by configuring the Undertow subsystem, but de-configuring something that is present by default can be harder to express in YAML.

• [idea] ask this group and hope for a good simple answer

Sorry I couldn't be of more help.

LT

[fwelland]

This was helpful.     

Leaning toward uberJar and then to *-thorntail.jar.      Gradle has several uberJar plugins that are similar to maven's shade (and related plugins). 

OR 

perhaps towards war-packaging.   

But I was curious about more about this comment:  ", but de-configuring something that is present by default can be harder to express in YAML."   Can you elaborate more on that? 

FWIW:   I'd  throw a vote towards adding in some sort of TT feature for some sort of "/lib" support to non-WAR style TT apps.     

related...

I had another inspiration towards solving/working around this and wouldn't mind some feed back on that direction:  use a TT hollow jar something like: 

java --classpath thirdparty1.jar:thirdparty2.jar   -jar my-hollow-thorntail.jar  myMDB.jar  

thoughts on that??? 

[Ladislav Thon]

Hi,

On 16. 01. 20 16:15, fwelland wrote:

This was helpful.     

Leaning toward uberJar and then to *-thorntail.jar.      Gradle has several uberJar plugins that are similar to maven's shade (and related plugins). 

OR 

perhaps towards war-packaging.   

But I was curious about more about this comment:  ", but de-configuring something that is present by default can be harder to express in YAML."   Can you elaborate more on that?

by default, we indeed configure some HTTP listeners for WAR deployments. Removing them is certainly possible, but expressing that removal in YAML can prove tricky. The standard way of setting a `null` value in YAML should work, but it might require a bit of debugging the Thorntail code.

FWIW:   I'd  throw a vote towards adding in some sort of TT feature for some sort of "/lib" support to non-WAR style TT apps.     

related...

I had another inspiration towards solving/working around this and wouldn't mind some feed back on that direction:  use a TT hollow jar something like: 

java --classpath thirdparty1.jar:thirdparty2.jar   -jar my-hollow-thorntail.jar  myMDB.jar  

thoughts on that???

When running a hollow JAR, you can specify `-Dthorntail.classpath=...` to add some JARs to the classpath. It's a semicolon-separated list, I think. So far, it's been tested to allow adding JDBC drivers, but I recall I've heard about issues when trying to use it for a different usecase.

One other thing: it seems you're in for a more long-term project. I'd recommend to take a look at Quarkus instead of Thorntail (see https://thorntail.io/posts/thorntail-community-announcement-on-quarkus/).

LT

On Wednesday, January 15, 2020 at 3:59:05 PM UTC-5, fwelland wrote:

Env:   Thorntail 2.6.0.Final  +  activemq-rar.rar (to external broker) + java 1.8 + gradle 6 & gradle thorntail plugin. 

It is pretty simple to make an MDB class  (MessageListener impl with @MessageDriven annotations)  that can get a message and print  helloWorld or something trivial like that.....

...But when said MDB goes to do 'real' stuff, using a jar/lib for example, the Thorntails MDB uberJar cannot see classes that are NOT part of 'project' (that is, source is just part of the core project contains source of said MDB).

Take simple case of an onMessage method in the MessageListener impl that uses some string/text method/class from 'org.apache.commons:commons-text:1.8':   at runtime, while service the onMessage() method is running, I'd get java.lang.NoClassDefFoundError errors for any lib reference.    

In an JBOSS/EAP or Wildfly deploy; i'd just shove an mdb.jar (with my code) in an EAR and deps jar in the EAR/lib and deploy that.   (Maybe you guessed, but what I am doing is decomposing a general purpose, HUGE jboss instance with lots of MDB ears into more purpose oriented message processors via Thorntail). 

Well, IFAIK, Thorntail really won't take an EAR.   

I can totally see that my TT uberjar  contains an m2repo that does indeed have the jars I need in it.    It is just that the loader that is running my MDB doesn't really have access to them. 

What is good way, and simple, way to make these libs available to the MDB class? 

------

Thought & Things I have tried: 

• added MANIFEST.MF  Class-Path attribute    --  still NoClassDef at run time
• added MANIFEST.MF   Dependencies  attribute  -- TT jar wouldn't start, 'cause at deploy time it couldn't resolve the dependency (just tried jar name, and g:a:v syntax -- this seems to be for JBOSS/WF modules?  Not sure I want to make every lib I possibly use a module seems like too much effort)
• [idea] make my own uberJar contain my MDB classes and its deps, collapsed;  and then have thorntail (& gradle plugin) make an runnable jar out of this uberJar 
• [idea] use war packaging (that seems to allow & use  /lib)   -- this is hokie as I don't want to then spend time shutting down lots of http listerners that I don't need
• [idea] ask this group and hope for a good simple answer
• [idea] maybe make a hollow thorntail.jar that can do MDB to external brokers and just write an old fashion .sh start script with classpath stuff pointing to my deps...
• [idea] ???

--
You received this message because you are subscribed to the Google Groups "Thorntail" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thorntail+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/ae1b244b-5ab6-4978-8e1e-319790ab2e2e%40googlegroups.com.

[fwelland]

Thanks for all your feedback. 

The uber to TT jar wasn't panning out; TT would deploy just fine but never really activate my MDB class.  

The war packaging is OK despite the HTTP/S stuff; we are cautiously moving that direction. 

About Quarkus,  not really in a need of docker oriented solutions (yet) and not clear how it would solve my needs. In the end my needs are simple:  need a MDB container/runner; do not need full EE support or web stuff; do use injection (cdi); transactions I can work around or implement on own.     Glancing thru the quarkus guides didn't really shed light on how I could use it to solve my needs. 

On Wednesday, January 15, 2020 at 3:59:05 PM UTC-5, fwelland wrote:

[Ladislav Thon]

On 21. 01. 20 13:13, fwelland wrote:

Thanks for all your feedback. 

The uber to TT jar wasn't panning out; TT would deploy just fine but never really activate my MDB class.  

The war packaging is OK despite the HTTP/S stuff; we are cautiously moving that direction.

Good to hear, thanks!

About Quarkus,  not really in a need of docker oriented solutions (yet) and not clear how it would solve my needs. In the end my needs are simple:  need a MDB container/runner; do not need full EE support or web stuff; do use injection (cdi); transactions I can work around or implement on own.     Glancing thru the quarkus guides didn't really shed light on how I could use it to solve my needs.

It's not a really Docker-oriented thing. I only suggested Quarkus because it's got way more traction than Thorntail, but if you need MDBs, then it's not an option for sure.

LT

On Wednesday, January 15, 2020 at 3:59:05 PM UTC-5, fwelland wrote:

Env:   Thorntail 2.6.0.Final  +  activemq-rar.rar (to external broker) + java 1.8 + gradle 6 & gradle thorntail plugin. 

It is pretty simple to make an MDB class  (MessageListener impl with @MessageDriven annotations)  that can get a message and print  helloWorld or something trivial like that.....

...But when said MDB goes to do 'real' stuff, using a jar/lib for example, the Thorntails MDB uberJar cannot see classes that are NOT part of 'project' (that is, source is just part of the core project contains source of said MDB).

Take simple case of an onMessage method in the MessageListener impl that uses some string/text method/class from 'org.apache.commons:commons-text:1.8':   at runtime, while service the onMessage() method is running, I'd get java.lang.NoClassDefFoundError errors for any lib reference.    

In an JBOSS/EAP or Wildfly deploy; i'd just shove an mdb.jar (with my code) in an EAR and deps jar in the EAR/lib and deploy that.   (Maybe you guessed, but what I am doing is decomposing a general purpose, HUGE jboss instance with lots of MDB ears into more purpose oriented message processors via Thorntail). 

Well, IFAIK, Thorntail really won't take an EAR.   

I can totally see that my TT uberjar  contains an m2repo that does indeed have the jars I need in it.    It is just that the loader that is running my MDB doesn't really have access to them. 

What is good way, and simple, way to make these libs available to the MDB class? 

------

Thought & Things I have tried: 

• added MANIFEST.MF  Class-Path attribute    --  still NoClassDef at run time
• added MANIFEST.MF   Dependencies  attribute  -- TT jar wouldn't start, 'cause at deploy time it couldn't resolve the dependency (just tried jar name, and g:a:v syntax -- this seems to be for JBOSS/WF modules?  Not sure I want to make every lib I possibly use a module seems like too much effort)
• [idea] make my own uberJar contain my MDB classes and its deps, collapsed;  and then have thorntail (& gradle plugin) make an runnable jar out of this uberJar 
• [idea] use war packaging (that seems to allow & use  /lib)   -- this is hokie as I don't want to then spend time shutting down lots of http listerners that I don't need
• [idea] ask this group and hope for a good simple answer
• [idea] maybe make a hollow thorntail.jar that can do MDB to external brokers and just write an old fashion .sh start script with classpath stuff pointing to my deps...
• [idea] ???

--

You received this message because you are subscribed to the Google Groups "Thorntail" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thorntail+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/a9ad0bb8-ad46-4f4b-b30d-c3427988ec7b%40googlegroups.com.

[fwelland]

Ah gotcha -- was gathering from some Quarkus stuff I am reading that seems to have allot of affinity or application in the micro-services area.   

That said:   I know I have been saying  "MDB" and indeed I have lots of (older) real MDBs  (that are running in a JBOSS EAP) -- but really I could use, especially for new work I am doing, a 'thing' that can listen to a Q and then dispatch to a jms MessageListener class;  and maybe having a some rudimentary 'container' like features like some threading support, simple msg ack/nack; maybe a bit of resource pooling. 

   

Indeed that isn't too hard really to DIY that;  in some greenfield work I have that already;  but, of course, it can't really just take an existing EE style MDB and 'run' it w/o significant modifications to said MDB. 

All 'small java container' things out there (TT, SpringBoot,  DropWizard, and others) are really geared to micro-services and http/s APIS;  almost nothing really for small container-based batch processing needs...

....sigh....

To unsubscribe from this group and stop receiving emails from it, send an email to thor...@googlegroups.com.

[Ladislav Thon]

On 22. 01. 20 19:24, fwelland wrote:

Ah gotcha -- was gathering from some Quarkus stuff I am reading that seems to have allot of affinity or application in the micro-services area.  

Indeed that's the main target, but you can run it as a plain old Java application, the Docker / Kubernetes / OpenShift thing is not enforced in any way.

That said:   I know I have been saying  "MDB" and indeed I have lots of (older) real MDBs  (that are running in a JBOSS EAP) -- but really I could use, especially for new work I am doing, a 'thing' that can listen to a Q and then dispatch to a jms MessageListener class;  and maybe having a some rudimentary 'container' like features like some threading support, simple msg ack/nack; maybe a bit of resource pooling. 

   

Indeed that isn't too hard really to DIY that;  in some greenfield work I have that already;  but, of course, it can't really just take an existing EE style MDB and 'run' it w/o significant modifications to said MDB. 

All 'small java container' things out there (TT, SpringBoot,  DropWizard, and others) are really geared to micro-services and http/s APIS;  almost nothing really for small container-based batch processing needs...

Agree this seems to be the main focus across the entire landscape. I'm pretty sure Thorntail won't get any batch/short-lived mode, but I know it's planned for Quarkus: https://github.com/quarkusio/quarkus/issues/5656

LT

To unsubscribe from this group and stop receiving emails from it, send an email to thorntail+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/03ad2ca3-6003-400a-97dd-91b08bc9e992%40googlegroups.com.