Bootable WF + a module (RAR) + Hollow Jar?

[Fred Welland]

I am having some good success with BWF.    

I am looking for an example or verification if possible to do this: 

1. hollowed bootable image
2. had a jboss/wf module slipped stream 'into' it
3. can take CLI commands during image bake or assembly step
4. remain as a hollowed bootable so I can iterate over my target deploy w/o reassembly each build. 

Is this possible? 

TIA, 

Fred

[Emmanuel Hugonnet]

For 4 you have the dev watch mode:

mvn org.wildfly.plugins:wildfly-jar-maven-plugin:dev-watch will do this for you

Cheers,
Emmanuel

Le 25/02/2021 à 13:16, Fred Welland a écrit :
> I am having some good success with BWF.    
>
> I am looking for an example or verification if possible to do this: 
>

> 1. hollowed bootable image
> 2. had a jboss/wf module slipped stream 'into' it
> 3. can take CLI commands during image bake or assembly step
> 4. remain as a hollowed bootable so I can iterate over my target deploy w/o reassembly each build. 

>
> Is this possible? 
>
> TIA, 
>
> Fred

> --
> You received this message because you are subscribed to the Google Groups "WildFly" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com
> <mailto:wildfly+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Jean Francois Denise]

Hi,

I will try to answer based on what I understand. Feel free to correct me, I am not sure of the "image" context.

On 2/25/21 1:16 PM, Fred Welland wrote:

I am having some good success with BWF.    

I am looking for an example or verification if possible to do this: 

1. hollowed bootable image

A docker image (from ?) in which you install an already built hollow bootable JAR. Built being done prior to build the docker image. Right?

1. had a jboss/wf module slipped stream 'into' it

You can only add custom JBoss Modules module during build of the hollow-jar (step 1).

1. can take CLI commands during image bake or assembly step

For now, CLI commands whith changes persisted in the server configuration can only be executed during Bootable JAR packaging.

You can run CLI commands against a running Bootable JAR, any change will be lost  at shutdown time.

1. remain as a hollowed bootable so I can iterate over my target deploy w/o reassembly each build.

You can start an hollow-jar with a --deployment=<path to your deployment> argument.

Is this possible?

TIA, 

Fred

--
You received this message because you are subscribed to the Google Groups "WildFly" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com.

[Fred Welland]

Wow thanks for the help.   Let me add a bit of color to my use case that I left out. 

• Yeah, I'd love docker for this -- my organization isn't there yet..sigh, baby steps, baby steps...
  
• So we have lots of MDBs that are being broken out into singleton worker BWF instances.   They are all the same structurally:   listen to an external AMQ 5x broker via RAR, and then process.   Some post messages back to AMQ via an RAR admin object; some don't.   Most use an oracle DB.   The only thing different about each MDB is the processing they do -- i.e. the MDB.ear.    
• FWIW:  most of my config in CLI are props driven;  BWF images are started with properties via  --properties=somefile.properties. 
• We are a gradle shop and, for these projects, we only use maven for assembling the BWF image; ear/war/etc are built by gradle.   The dev-mode thing may or may not work for my case; may try to see how that could work; but it does miss a point:   that if I had a BWF image with the RAR in place, and properties driven config in said BWF image; then MDB development becomes:    make an EAR, make an props file, use a curated BWF artifact (and not rebuild that over and again).   

I was browsing the samples here:   https://github.com/wildfly-extras/wildfly-jar-maven-plugin/tree/3.0.0.Final/examples  and was hoping for an example that installed a custom module archive during assembly, but can still be hollow.      I actually don't' see an example of installing a custom module (hollow or not) -- I could have missed it. 

Currently,  I literally have BWF CLI that does: 

deploy --name=ActiveMQ-RAR --runtime-name-activemq-rar.rar  <path>/activemq-rar-5.16.0.rar

##

## other cli steps to configure RAR or DB and stuff

## 

deploy build/libs/my-mbd.ear

I found that in CLI for BWF, once you use 'deploy' once in CLI, you can no longer use the --deploy <artifact>  startup switch  to provide an EAR while running the bootable.    BFW, says "sorry something is already deployed".    You can, however, use multiple deploy commands during image bake -- which is how I get the rar deployed and then my EAR.     But, that has to be done during bake time -- which isn't' terrible but it does cost a few extra minutes to the dev/build/test cycle. 

I guess I have a couple other thoughts: 

• Can I get the RAR 'in' my BWF w/o using cli 'deploy' so I can go back to hollowed BWF.jars? 
• Wouldn't be cool if there was a pre-built AMQ 5x layer that slammed in the RAR; kinda like using the 'oracle-driver' layer from galleon data source packs? 
• Or maybe BWF startup can tolerate having a deploy via CLI & bake and also still process the --deployment startup switch. 

Thanks again for your help!

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/1a2beddf-2e69-a8c6-6d21-a31233e804e3%40redhat.com.

[Jean Francois Denise]

On 2/25/21 2:36 PM, Fred Welland wrote:

Wow thanks for the help.   Let me add a bit of color to my use case that I left out. 

• Yeah, I'd love docker for this -- my organization isn't there yet..sigh, baby steps, baby steps...
  
• So we have lots of MDBs that are being broken out into singleton worker BWF instances.   They are all the same structurally:   listen to an external AMQ 5x broker via RAR, and then process.   Some post messages back to AMQ via an RAR admin object; some don't.   Most use an oracle DB.   The only thing different about each MDB is the processing they do -- i.e. the MDB.ear.    
• FWIW:  most of my config in CLI are props driven;  BWF images are started with properties via  --properties=somefile.properties. 
• 
  
• We are a gradle shop and, for these projects, we only use maven for assembling the BWF image; ear/war/etc are built by gradle.   The dev-mode thing may or may not work for my case; may try to see how that could work; but it does miss a point:   that if I had a BWF image with the RAR in place, and properties driven config in said BWF image; then MDB development becomes:    make an EAR, make an props file, use a curated BWF artifact (and not rebuild that over and again).   

I was browsing the samples here:   https://github.com/wildfly-extras/wildfly-jar-maven-plugin/tree/3.0.0.Final/examples  and was hoping for an example that installed a custom module archive during assembly, but can still be hollow.      I actually don't' see an example of installing a custom module (hollow or not) -- I could have missed it.

We don't have such example, but we have some that can help you. You can look at https://github.com/wildfly-extras/wildfly-jar-maven-plugin/tree/master/examples/https that copies a keystore (look at the extra-content dir).

Create a directory for your module inside the extra-content dir: eg: extra-content/modules/org/foo/bar/main Add module.xml and artifact to it. Reference this extra-content dir ad done there: https://github.com/wildfly-extras/wildfly-jar-maven-plugin/blob/master/examples/https/pom.xml#L50

Hope that helps.

JF

[Fred Welland]

Finally got around to trying this.     Using normal WF22, I proto-typed the module and that seemed to work.  NOTE:  I used jboss-cli to create the resource-adapter, using 'module' rather than 'archive'.   

I took that directory and used the extra-content dir stuff and manipulated my directories while building the bootable so that  the bootable.jar:wildfly.zip   has a folder that is the same as what I used for WF22.    (NOTE:  the resulting module folder in zip is wildfly.zip:/modules/system/layers/base/org/apache/amq-rar   inside that folder is 'main' containing module.xml and jar artifacts, etc). 

Tweaked my CLI for bootable to define resource-adpate using module rather than archive (same syntax as used for WF22) and built a bootable.    Essentially,  I changed 

/subsystem=resource-adapters/resource-adapter=AMQBroker:add(archve=activemq-rar.rar) 

     to 

/subsystem=resource-adapters/resource-adapter=AMQBroker:add(module=org.apache.amq-rar ) 

The rest of my BWF cli was the same as the working version (using RAR that is just deployed via 'deploy') . 

The bootable built, seemingly OK.   It "runs"; BUT on bootup -- the RA complains about fail to load module   (in my case 'org.apache.amq-rar').   Of course, the rest of BWF image spews failures based on missing RA, etc etc etc. 

So, is there something I gotta do to get the module 'recognized' by BWF?   Or perhaps a step I missed? 

[Fred Welland]

WooHoo!   You fixed it! 

Your comment made me go back and look at the error more closely.    After a few tries, I fixed it.    But my fix does raise a question or two.   

For starters, the problem was the module was loading but it had a declared dependency that couldn't be found or loaded.   Said dependency was 'javax.management.j2ee.api' 

Adding "<layer>management</layer> "  didn't affect this and then I recall seeing deps in the module.xml I had 'authored'.    "Authored"  here means I stole it off some post off of the interwebbies and, I am ashamed to admit it, but do not fully know everything the sample module.xml does. 

All I did was comment out the <module /> from the <dependencies /> section of module.xml.   Rebuild the bootable;  and that problem went away.....

...and basically it works!    I am now running  my app via: 

java -jar  bootable.jar --deployment=myMdb.ear --properties myproperties.props 

Much better!   

Now onto some questions  (maybe not totally BWF, modules are new-ish to me, but this is a WF list...) : 

1. I unraveled my RAR to make the module.   Is there a way to reference the rar file as a resource-root  w/o unraveling and using <resource-root path="..."/> and pointing to all bits from the rar file.  OR ...
2. ....is there a cli "module add"  switch or something that can take the rar as a 'resource-archive' and then also take --name and --dependencies  (and other needed things), so I don't have to curate a modules directory? 
3. How does one 'know' what a RAR's dependencies are?  (so I know what to correctly put in the module.xml's <dependencies /> section?
4. What layer would have provided 'javax.management.j2ee.api' any way?
5. [esoteric]  When I ran my MDB as deployed in a normal WF22 instance I had to add 'javax.jms.api' as a Dependencis in manifest of the MDB.jar; when I run the BWF this doesn't seem needed. Why? 

(hmm...probably got a few more, but I need to build up some gradle/automation around maintaining this modules stuff some; to be able to better ask some more targeted questions). 

Thanks!

On Mon, Mar 1, 2021 at 12:35 PM Jean Francois Denise <jde...@redhat.com> wrote:

On 3/1/21 4:21 PM, Fred Welland wrote:

Finally got around to trying this.     Using normal WF22, I proto-typed the module and that seemed to work.  NOTE:  I used jboss-cli to create the resource-adapter, using 'module' rather than 'archive'.   

I took that directory and used the extra-content dir stuff and manipulated my directories while building the bootable so that  the bootable.jar:wildfly.zip   has a folder that is the same as what I used for WF22.    (NOTE:  the resulting module folder in zip is wildfly.zip:/modules/system/layers/base/org/apache/amq-rar   inside that folder is 'main' containing module.xml and jar artifacts, etc). 

Tweaked my CLI for bootable to define resource-adpate using module rather than archive (same syntax as used for WF22) and built a bootable.    Essentially,  I changed 

/subsystem=resource-adapters/resource-adapter=AMQBroker:add(archve=activemq-rar.rar) 

     to 

/subsystem=resource-adapters/resource-adapter=AMQBroker:add(module=org.apache.amq-rar ) 

The rest of my BWF cli was the same as the working version (using RAR that is just deployed via 'deploy') . 

The bootable built, seemingly OK.   It "runs"; BUT on bootup -- the RA complains about fail to load module   (in my case 'org.apache.amq-rar').   Of course, the rest of BWF image spews failures based on missing RA, etc etc etc.

If you could share your startup output, could be a missing dependency?  You could check that target/bootable-jar/wildfly/bin/standalone.sh starts properly (and that this installation contains the rar module)?

[Jean Francois Denise]

Hi Fred,

some replies inlined.

On 3/1/21 9:17 PM, Fred Welland wrote:

WooHoo!   You fixed it! 

Your comment made me go back and look at the error more closely.    After a few tries, I fixed it.    But my fix does raise a question or two.   

For starters, the problem was the module was loading but it had a declared dependency that couldn't be found or loaded.   Said dependency was 'javax.management.j2ee.api' 

Adding "<layer>management</layer> "  didn't affect this and then I recall seeing deps in the module.xml I had 'authored'.    "Authored"  here means I stole it off some post off of the interwebbies and, I am ashamed to admit it, but do not fully know everything the sample module.xml does. 

All I did was comment out the <module /> from the <dependencies /> section of module.xml.   Rebuild the bootable;  and that problem went away.....

...and basically it works!    I am now running  my app via: 

java -jar  bootable.jar --deployment=myMdb.ear --properties myproperties.props 

Much better!   

Now onto some questions  (maybe not totally BWF, modules are new-ish to me, but this is a WF list...) : 

1. I unraveled my RAR to make the module.   Is there a way to reference the rar file as a resource-root  w/o unraveling and using <resource-root path="..."/> and pointing to all bits from the rar file.  OR ...
2. ....is there a cli "module add"  switch or something that can take the rar as a 'resource-archive' and then also take --name and --dependencies  (and other needed things), so I don't have to curate a modules directory?
   

You can do: module add --name=org.apache.amq --dependencies=javax.management.j2ee.api,<all other dependencies> --resources=<rar file>

A new module will be created in <wildfly home>/modules directory.

1. How does one 'know' what a RAR's dependencies are?  (so I know what to correctly put in the module.xml's <dependencies /> section?
2. What layer would have provided 'javax.management.j2ee.api' any way?

If wildfly was defining a jsr77 layer, this is the one that would bring it I guess. Its module.xml has a required dependency on it.

You can explicitly add a package when building a bootable JAR:

<feature-pack>
  <location>wildfly@maven(org.jboss.universe:community-universe)#23.0.0.Beta1</location>
  <included-packages>
    <package>javax.management.j2ee.api</package>
  </included-packages>
</feature-pack>

[Emmanuel Hugonnet]

Le 01/03/2021 à 21:17, Fred Welland a écrit :
> WooHoo!   You fixed it! 
>
> Your comment made me go back and look at the error more closely.    After a few tries, I fixed it.    But my fix does raise a question or
> two.   
>
> For starters, the problem was the module was loading but it had a declared dependency that couldn't be found or loaded.   Said dependency
> was 'javax.management.j2ee.api' 
>
> Adding "<layer>management</layer> "  didn't affect this and then I recall seeing deps in the module.xml I had 'authored'.    "Authored" 
> here means I stole it off some post off of the interwebbies and, I am ashamed to admit it, but do not fully know everything the sample
> module.xml does. 
>
> All I did was comment out the <module /> from the <dependencies /> section of module.xml.   Rebuild the bootable;  and that problem went
> away.....
>
> ...and basically it works!    I am now running  my app via: 
>
> java -jar  bootable.jar --deployment=myMdb.ear --properties myproperties.props 
>
> Much better!   
>
> Now onto some questions  (maybe not totally BWF, modules are new-ish to me, but this is a WF list...) : 
>

> 1. I unraveled my RAR to make the module.   Is there a way to reference the rar file as a resource-root  w/o unraveling and using

> <resource-root path="..."/> and pointing to all bits from the rar file.  OR ...

> 2. ....is there a cli "module add"  switch or something that can take the rar as a 'resource-archive' and then also take --name and

> --dependencies  (and other needed things), so I don't have to curate a modules directory? 

> 3. How does one 'know' what a RAR's dependencies are?  (so I know what to correctly put in the module.xml's <dependencies /> section?
> 4. What layer would have provided 'javax.management.j2ee.api' any way?
> 5. [esoteric]  When I ran my MDB as deployed in a normal WF22 instance I had to add 'javax.jms.api' as a Dependencis in manifest of the

> MDB.jar; when I run the BWF this doesn't seem needed. Why?
>

5. feels strange to me as the MDB detection is the same and APIs are injected in the deployment. If you could reproduce or provide a
reproducer I would love to 'fix' that.
Emmanuel

>
> (hmm...probably got a few more, but I need to build up some gradle/automation around maintaining this modules stuff some; to be able to
> better ask some more targeted questions). 
>
> Thanks!
>
>
>
>
>
>
>
> On Mon, Mar 1, 2021 at 12:35 PM Jean Francois Denise <jde...@redhat.com <mailto:jde...@redhat.com>> wrote:
>
> On 3/1/21 4:21 PM, Fred Welland wrote:
>> Finally got around to trying this.     Using normal WF22, I proto-typed the module and that seemed to work.  NOTE:  I used jboss-cli
>> to create the resource-adapter, using 'module' rather than 'archive'.   
>>
>> I took that directory and used the extra-content dir stuff and manipulated my directories while building the bootable so that  the
>> bootable.jar:wildfly.zip   has a folder that is the same as what I used for WF22.    (NOTE:  the resulting module folder in zip is
>> wildfly.zip:/modules/system/layers/base/org/apache/amq-rar   inside that folder is 'main' containing module.xml and jar artifacts, etc). 
>>
>> Tweaked my CLI for bootable to define resource-adpate using module rather than archive (same syntax as used for WF22) and built a
>> bootable.    Essentially,  I changed 
>>
>> /subsystem=resource-adapters/resource-adapter=AMQBroker:add(archve=activemq-rar.rar) 
>>      to 
>> /subsystem=resource-adapters/resource-adapter=AMQBroker:add(module=org.apache.amq-rar ) 
>>
>> The rest of my BWF cli was the same as the working version (using RAR that is just deployed via 'deploy') . 
>>
>>
>> The bootable built, seemingly OK.   It "runs"; BUT on bootup -- the RA complains about fail to load module   (in my case
>> 'org.apache.amq-rar').   Of course, the rest of BWF image spews failures based on missing RA, etc etc etc.
> If you could share your startup output, could be a missing dependency?  You could check that
> target/bootable-jar/wildfly/bin/standalone.sh starts properly (and that this installation contains the rar module)?
>>
>> So, is there something I gotta do to get the module 'recognized' by BWF?   Or perhaps a step I missed? 
>>
>>
>>
>> On Thu, Feb 25, 2021 at 1:45 PM Jean Francois Denise <jde...@redhat.com <mailto:jde...@redhat.com>> wrote:
>>
>> On 2/25/21 2:36 PM, Fred Welland wrote:
>>> Wow thanks for the help.   Let me add a bit of color to my use case that I left out. 
>>>

>>> * Yeah, I'd love docker for this -- my organization isn't there yet..sigh, baby steps, baby steps...
>>> * So we have lots of MDBs that are being broken out into singleton worker BWF instances.   They are all the same

>>> structurally:   listen to an external AMQ 5x broker via RAR, and then process.   Some post messages back to AMQ via an RAR
>>> admin object; some don't.   Most use an oracle DB.   The only thing different about each MDB is the processing they do --
>>> i.e. the MDB.ear.    

>>> * FWIW:  most of my config in CLI are props driven;  BWF images are started with properties via 
>>> --properties=somefile.properties. 
>>> *
>>>
>>> * We are a gradle shop and, for these projects, we only use maven for assembling the BWF image; ear/war/etc are built by

>>> * Can I get the RAR 'in' my BWF w/o using cli 'deploy' so I can go back to hollowed BWF.jars? 
>>> * Wouldn't be cool if there was a pre-built AMQ 5x layer that slammed in the RAR; kinda like using the 'oracle-driver' layer

>>> from galleon data source packs? 

>>> * Or maybe BWF startup can tolerate having a deploy via CLI & bake and also still process the --deployment startup switch. 

>>>
>>>
>>> Thanks again for your help!
>>>
>>>
>>>
>>>
>>> On Thu, Feb 25, 2021 at 7:29 AM Jean Francois Denise <jde...@redhat.com <mailto:jde...@redhat.com>> wrote:
>>>
>>> Hi,
>>> I will try to answer based on what I understand. Feel free to correct me, I am not sure of the "image" context.
>>> On 2/25/21 1:16 PM, Fred Welland wrote:
>>>> I am having some good success with BWF.    
>>>>
>>>> I am looking for an example or verification if possible to do this: 
>>>>

>>>> 1. hollowed bootable image

>>>>
>>> A docker image (from ?) in which you install an already built hollow bootable JAR. Built being done prior to build the
>>> docker image. Right?
>>>>

>>>> 1. had a jboss/wf module slipped stream 'into' it

>>>>
>>> You can only add custom JBoss Modules module during build of the hollow-jar (step 1).
>>>>

>>>> 1. can take CLI commands during image bake or assembly step

>>>>
>>> For now, CLI commands whith changes persisted in the server configuration can only be executed during Bootable JAR packaging.
>>>
>>> You can run CLI commands against a running Bootable JAR, any change will be lost  at shutdown time.
>>>

>>>> 1. remain as a hollowed bootable so I can iterate over my target deploy w/o reassembly each build.

>>>>
>>> You can start an hollow-jar with a --deployment=<path to your deployment> argument.
>>>> Is this possible?
>>>>
>>>> TIA, 
>>>>
>>>> Fred
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "WildFly" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com

>>>> <mailto:wildfly+u...@googlegroups.com>.

>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com

>>>> <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

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

>>> <mailto:wildfly+u...@googlegroups.com>.

>>> To view this discussion on the web visit

>>> https://groups.google.com/d/msgid/wildfly/1a2beddf-2e69-a8c6-6d21-a31233e804e3%40redhat.com
>>> <https://groups.google.com/d/msgid/wildfly/1a2beddf-2e69-a8c6-6d21-a31233e804e3%40redhat.com?utm_medium=email&utm_source=footer>.

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

> <mailto:wildfly+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/wildfly/CAGO%3D3NaFfjSYm2qejhjgLgm%2By6CReh80AeKubj2_mATysM7aig%40mail.gmail.com
> <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NaFfjSYm2qejhjgLgm%2By6CReh80AeKubj2_mATysM7aig%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Fred Welland]

Thanks for the feedback!

Turns out WF nor BWF seems to support modules with a RAR file like: 

      <resource-root path="some-rar.rar"/> 

Which is why I unraveled the RAR and curated a module directory.     I did try the <artifact name="G:A:V" />  element too, that seems to be part of newer module XSDs.   That doesn't lead anywhere.  

I had also tried something like:    module add --name=org.apache.amq --dependencies=javax.management.j2ee.api,<all other dependencies> --resources=<rar file>   .   Of course that didn't work, as per above.    Maybe there is another way to do this (module containing an archive, which contains other jars & resources).   

Pretty confident I could just enumerate the 20 or so jars that comprise the rar, in the CLI 'module add --resources ' argument, and that would work.    Using the G:A:V for the rar, fetching it, unpacking and generating the module add cli command are probably automateable -- if but a bit awkward and time consuming to author.   

....And that,  javax.management.j2ee.api, is a question; but good to know how to add it in.     I omitted this from the module dependency and everything seems to work OK.   I guess I was more curious how one would know what to add to a modules dependency section given a set of jars (i.e. the jar set from the RAR).   But thinking and observing a bit, I bet they are just the transitives needed by the jars in the module and relying on the container to provide rather than packing them in the module.    Indeed AMQ 5x rar, bundles a copy of the geronimo-j2ee spec jar -- so that must be why random postings on the internet suggested that this is a needed dependency and my current work isn't really hitting that feature of the RAR such that the J2EE management stuff is used.   

Thanks again for your help!

[Fred Welland]

Will this help? 

https://github.com/fwelland/BWF-MDB-EAR-ModuledRAR

This is in reference to comment from this thread: 

5. feels strange to me as the MDB detection is the same and APIs are injected in the deployment. If you could reproduce or provide a

reproducer I would love to 'fix' that.

Emmanuel

[Jean Francois Denise]

Hi Fred,

an old thread...

Emmanuel is evolving the gradle example you contributed: https://github.com/wildfly-extras/wildfly-jar-maven-plugin/pull/336

If you want to have a look, a lot changed there (usage of EE-10, kafka, ...)

Thank-you.

JF

[Emmanuel Hugonnet]

Yes I changed the example quite a bit because I needed a producer and thus I created a war.
The gradle script is still working but now maven is doing the same job thus you can use the tool you like.
I didn't keep the properties file since it required to make the script a bit more complex sicen i reuse the connection factory in the sender.
Cheers,
Emmanuel

>> wildfly+u...@googlegroups.com <mailto:wildfly%2Bunsu...@googlegroups.com>
>> >>>>             <mailto:wildfly+u...@googlegroups.com <mailto:wildfly%2Bunsu...@googlegroups.com>>.

>> >>>>             To view this discussion on the web visit
>> >>>> https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com
>> >>>>           
>>  <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com?utm_medium=email&utm_source=footer
>> <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>> >>>
>> >>>
>> >>>             --
>> >>>             You received this message because you are subscribed to the Google Groups "WildFly" group.
>> >>>             To unsubscribe from this group and stop receiving emails from it, send an email to

>> wildfly+u...@googlegroups.com <mailto:wildfly%2Bunsu...@googlegroups.com>
>> >>>             <mailto:wildfly+u...@googlegroups.com <mailto:wildfly%2Bunsu...@googlegroups.com>>.

>> >>>             To view this discussion on the web visit
>> >>> https://groups.google.com/d/msgid/wildfly/1a2beddf-2e69-a8c6-6d21-a31233e804e3%40redhat.com
>> >>>           
>>  <https://groups.google.com/d/msgid/wildfly/1a2beddf-2e69-a8c6-6d21-a31233e804e3%40redhat.com?utm_medium=email&utm_source=footer
>> <https://groups.google.com/d/msgid/wildfly/1a2beddf-2e69-a8c6-6d21-a31233e804e3%40redhat.com?utm_medium=email&utm_source=footer>>.
>> >>>
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "WildFly" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com

>> <mailto:wildfly%2Bunsu...@googlegroups.com>
>> > <mailto:wildfly+u...@googlegroups.com <mailto:wildfly%2Bunsu...@googlegroups.com>>.

>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/wildfly/CAGO%3D3NaFfjSYm2qejhjgLgm%2By6CReh80AeKubj2_mATysM7aig%40mail.gmail.com
>> >
>> <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NaFfjSYm2qejhjgLgm%2By6CReh80AeKubj2_mATysM7aig%40mail.gmail.com?utm_medium=email&utm_source=footer

>> <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NaFfjSYm2qejhjgLgm%2By6CReh80AeKubj2_mATysM7aig%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>>
>

[Fred Welland]

Wow!  

Thanks for the follow up on this;   I'd forgotten about that effort!

I will say I've now got like 6 or 8  BWF standalone MDB processors kicking around in our production work (and more cooking).       We also have BWF instances running some web-apps too. 

All  are derived from that example,  somewhere along the lines and I don't recall when and why;  but we pivoted to a slightly different approach. 

We don't do hollow bootables -- that never really took hold with our dev corps.   Also, there were enough variations in our MDB processors, so that  we could never pin down a single (or small number) for hollow bootable(s).    More or less each is a snowflake. 

But then in our CLI for BWF we actually do multiple deploy actions.    So in cased of an MDB we "cli-do" this: 

deploy --name=ActiveMQ-RAR --runtime-name=activemq-rar.rar build/activemq-client.rar
/subsystem=resource-adapters/resource-adapter=AMQBroker:add(archive=activemq-rar.rar, transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=AMQBroker/config-properties=ServerUrl/:add(value="$${env.AMQ_BROKER_URL}")
/subsystem=resource-adapters/resource-adapter=AMQBroker/config-properties=UserName/:add(value="$${env.AMQ_BROKER_USERNAME}")
/subsystem=resource-adapters/resource-adapter=AMQBroker/config-properties=Password/:add(value="$${env.AMQ_BROKER_PASSWORD}")

And then after some more CLI statements to make a QCF and admin-objects, log stuffs, shutdown undertow, timeout tweaks,   and re-assigning default rar to 'AMQBroker' at the bottom of the CLI will follow up with a CLI like: 

deploy build/my-mdb.ear

I recall, that in the pom -- we do actually tell mvn/bwf-plugin to be hollow.   But the final deploy 'locks' it in to a specific MDB (or WAR).    When I used the  mvn/bwf-plugin to deploy the ear;  it objected during CLI processing or perhaps as it added in the EAR,  something about:   'error:  there is already a deployment'.     (You know, there maybe a thread on this in the WF/BWF list, also ;)  ) 

Like I mentioned, this pattern is working really well for us at the moment. 

At some point, I want to go back and see if can omit the mvn stuff and do something different.  Perhaps a native gradle plugin, or maybe -- I am recalling something from thorntail (RIP) and there is no BWF tool for this --  a CLI processor that prepares the bootable.      Oh and well pivot from Java EE to Jakarta EE.     (Say, when is WF/BWF gonna make the jakarta 'mandatory'??) 

Thanks! 

-Fred

[Emmanuel Hugonnet]

Inline

Le 20/10/2022 à 16:20, Fred Welland a écrit :
> Wow!
>
> Thanks for the follow up on this;   I'd forgotten about that effort!
>
> I will say I've now got like 6 or 8  BWF standalone MDB processors kicking around in our production work (and more cooking).       We also
> have BWF instances running some web-apps too.
>
> All  are derived from that example,  somewhere along the lines and I don't recall when and why;  but we pivoted to a slightly different
> approach.
>
> We don't do hollow bootables -- that never really took hold with our dev corps.   Also, there were enough variations in our MDB
> processors, so that  we could never pin down a single (or small number) for hollow bootable(s).    More or less each is a snowflake.
>
> But then in our CLI for BWF we actually do multiple deploy actions.    So in cased of an MDB we "cli-do" this:
>
> deploy --name=ActiveMQ-RAR --runtime-name=activemq-rar.rar build/activemq-client.rar
> /subsystem=resource-adapters/resource-adapter=AMQBroker:add(archive=activemq-rar.rar, transaction-support=XATransaction)
> /subsystem=resource-adapters/resource-adapter=AMQBroker/config-properties=ServerUrl/:add(value="$${env.AMQ_BROKER_URL}")
> /subsystem=resource-adapters/resource-adapter=AMQBroker/config-properties=UserName/:add(value="$${env.AMQ_BROKER_USERNAME}")
> /subsystem=resource-adapters/resource-adapter=AMQBroker/config-properties=Password/:add(value="$${env.AMQ_BROKER_PASSWORD}")

Yes I didn't want to do that listing ;) but in the end we should.

>
> And then after some more CLI statements to make a QCF and admin-objects, log stuffs, shutdown undertow, timeout tweaks,  and re-assigning
> default rar to 'AMQBroker' at the bottom of the CLI will follow up with a CLI like:
>
> deploy build/my-mdb.ear
>
> I recall, that in the pom -- we do actually tell mvn/bwf-plugin to be hollow.   But the final deploy 'locks' it in to a specific MDB (or
> WAR).    When I used the mvn/bwf-plugin to deploy the ear;  it objected during CLI processing or perhaps as it added in the EAR, 
> something about:   'error:  there is already a deployment'.     (You know, there maybe a thread on this in the WF/BWF list, also ;)  )
>
> Like I mentioned, this pattern is working really well for us at the moment.
>
> At some point, I want to go back and see if can omit the mvn stuff and do something different.  Perhaps a native gradle plugin, or maybe
> -- I am recalling something from thorntail (RIP) and there is no BWF tool for this --  a CLI processor that prepares the bootable.      Oh
> and well pivot from Java EE to Jakarta EE.     (Say, when is WF/BWF gonna make the jakarta 'mandatory'??)

27 which should be released soon :) Thus the move form Activemq to Kafka.
>
> Thanks!
>
> -Fred
>
>
Thanks for the initial effort :)

>> wildfly+u...@googlegroups.com <mailto:wildfly%2Bunsu...@googlegroups.com>
>> >>>>             <mailto:wildfly+u...@googlegroups.com <mailto:wildfly%2Bunsu...@googlegroups.com>>.

>> >>>>             To view this discussion on the web visit
>> >>>> https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com
>> >>>>           
>>  <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com?utm_medium=email&utm_source=footer
>> <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NYDvVs7YnpFA%2BxwjFe_kfryJuHhoNww8KXcTuAzR55dRQ%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>> >>>
>> >>>
>> >>>             --
>> >>>             You received this message because you are subscribed to the Google Groups "WildFly" group.
>> >>>             To unsubscribe from this group and stop receiving emails from it, send an email to

>> wildfly+u...@googlegroups.com <mailto:wildfly%2Bunsu...@googlegroups.com>
>> >>>             <mailto:wildfly+u...@googlegroups.com <mailto:wildfly%2Bunsu...@googlegroups.com>>.

>> >>>             To view this discussion on the web visit
>> >>> https://groups.google.com/d/msgid/wildfly/1a2beddf-2e69-a8c6-6d21-a31233e804e3%40redhat.com
>> >>>           
>>  <https://groups.google.com/d/msgid/wildfly/1a2beddf-2e69-a8c6-6d21-a31233e804e3%40redhat.com?utm_medium=email&utm_source=footer
>> <https://groups.google.com/d/msgid/wildfly/1a2beddf-2e69-a8c6-6d21-a31233e804e3%40redhat.com?utm_medium=email&utm_source=footer>>.
>> >>>
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "WildFly" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com

>> <mailto:wildfly%2Bunsu...@googlegroups.com>
>> > <mailto:wildfly+u...@googlegroups.com <mailto:wildfly%2Bunsu...@googlegroups.com>>.

>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/wildfly/CAGO%3D3NaFfjSYm2qejhjgLgm%2By6CReh80AeKubj2_mATysM7aig%40mail.gmail.com
>> >
>> <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NaFfjSYm2qejhjgLgm%2By6CReh80AeKubj2_mATysM7aig%40mail.gmail.com?utm_medium=email&utm_source=footer

>> <https://groups.google.com/d/msgid/wildfly/CAGO%3D3NaFfjSYm2qejhjgLgm%2By6CReh80AeKubj2_mATysM7aig%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>>
>