Standalone environment

[Jesper Pedersen]

Hi,

Our initial standalone environment has been merged as part of https://github.com/ironjacamar/ironjacamar/pull/514

This means that early adopters can start to run their deployments on what will become IronJacamar 2.0 - Woo !

There are some changes, as compared with our 1.2 branch

• Using Jetty 9.3 in order support Java8 (previously 8.1)
• Enabled Jetty/JMX integration
• Renamed container environment from "iron.jacamar" to "ironjacamar"

I had to keep the version numbers in the lib/jetty directory, as there are multiple artifacts called the same. But I don't see that as a major problem, as we don't publish our web artifact.

Otherwise there shouldn't anything else, so speak up if you find something. Also, contributions to enhance our Jetty integration are most welcome.

Our documentation will of course explain this in more detail - once we get going on that.

So, go forth and start testing - we need your feedback :)

Best regards,

  Jesper

[Stefano Maestri]

As said in PR in general this approach (Jetty+Fungal) is the only one we have to (try to) respect our release plan. Even thought I'm wondering if we should not fork an experimental branch and spend a bit of time to understand how to use WF-core and Undertow as containers. I perfectly know it could be a lot of pain, but I still think we should spend time on this at this stage, eventually discussing w/ WF-core and Undertow "community" to be sure our current architecture would fit in those containers at least for the future w/o too many changes. It would be a great help also to predict WFLY/EAP integration effort.

regards

S.

[Jesper Pedersen]

I have been looking at adding a management environment to our standalone distribution, like we had for the 1.x series.

I think it still makes sense to have the implementation based on JMX - just as 1.x - as that would limit the number of dependencies, and it is still a widely used management model.

However, in 1.x we based the management model directly on the actual object instances of the deployment, as it provided an easy to map attributes/operations to JMX.

In 2.x we want to have all management models be backed by our DeploymentRepository and friends, and thereby have a clear management interface to our deployments. But DeploymentRepository doesn't really expose itself as a MBean - f.ex. ConfigProperty has getName() / getType() / getValue() / setValue() instead of a standard getter/setter pair.

My suggestion is that we generate a JMX facade to the Deployment instance at run-time such that the MBean instances follow the standard JMX way of doing things, but is backed by the underlying Deployment methods. And I suggest that we use ByteBuddy (http://bytebuddy.net/) for this. It should be possible to write test cases for the JMX facade too in order to verify that the generation is ok.

Of course this is a "bit" more work than we had in 1.x, so I suggest that we push the management model to our Beta2 release.

We can think about if we want to enable management for embedded too - I think it could make sense for certain environments.

Thoughts ?

[Stefano Maestri]

On Tue, May 24, 2016 at 8:00 PM, Jesper Pedersen <jesper....@comcast.net> wrote:

I have been looking at adding a management environment to our standalone distribution, like we had for the 1.x series.

I think it still makes sense to have the implementation based on JMX - just as 1.x - as that would limit the number of dependencies, and it is still a widely used management model.

However, in 1.x we based the management model directly on the actual object instances of the deployment, as it provided an easy to map attributes/operations to JMX.

In 2.x we want to have all management models be backed by our DeploymentRepository and friends, and thereby have a clear management interface to our deployments. But DeploymentRepository doesn't really expose itself as a MBean - f.ex. ConfigProperty has getName() / getType() / getValue() / setValue() instead of a standard getter/setter pair.

My suggestion is that we generate a JMX facade to the Deployment instance at run-time such that the MBean instances follow the standard JMX way of doing things, but is backed by the underlying Deployment methods. And I suggest that we use ByteBuddy (http://bytebuddy.net/) for this. It should be possible to write test cases for the JMX facade too in order to verify that the generation is ok.

​An alternative could be use Groovy and it's natural dynamic nature to react runtime at JMX event and map calls into our model. It would permit us to generate code runtime using groovy and should be easy to test it. Since version 1.6 JMX builder is part of groovy​ core

https://code.google.com/archive/p/groovy-jmx-builder/

 

Of course this is a "bit" more work than we had in 1.x, so I suggest that we push the management model to our Beta2 release.

​Yup I think we could postpone this to B2​

 

We can think about if we want to enable management for embedded too - I think it could make sense for certain environments.

​+1​

 

​regards

S.​

[Jesper Pedersen]

​An alternative could be use Groovy and it's natural dynamic nature to react runtime at JMX event and map calls into our model. It would permit us to generate code runtime using groovy and should be easy to test it. Since version 1.6 JMX builder is part of groovy​ core

https://code.google.com/archive/p/groovy-jmx-builder/

It looks like it uses the underlying object directly, like

http://jesperpedersen.github.io/fungal/api/0.11/com/github/fungal/api/util/JMX.html

But maybe something will the call events could make it work.

Lets look in detail during Beta2.