[Proposal] Dyanmic console module loading for multi-product in EAP6*

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

[Proposal] Dyanmic console module loading for multi-product in EAP6*

jtgreene
Administrator
In order to support multiple derived products based on EAP, we need a solution that allows the console to "emulate" plug-ability. By "emulate", I mean that until we have a dynamic rendering engine (AS8/EAP7), we still have to deal with the fact that GWT requires static compilation.

The first component of the proposal is that the console have a serial version stream which includes *all* plugins. Every derivative product will need to contribute a plugin which is pulled into the serial version stream via reference. This means that every console release will need to verify compatibility with old and new versions of all products. This should not be too big of a deal because the management policies require that we maintain compatibility anyway.

The second component is that every product (and its patch updates if features are added) will bundle a version of the console which includes support for the product. At runtime the server will then simply pick the most recent version available. This will allow for every copy to maintain a clear ownership. So for example, if you install a patch which brings in console version 1.7, that version can be removed and the other available versions can be used.

An example is:

/consoles/1.1 (Installed by EAP)
/consoles/1.2 (Installed by Portal)
/consoles/1.3 (Installed by BRMS)
/consoles/1.4 (installed by a Portal patch)

So in this case the server would start with 1.4. If BRMS was removed, 1.4 would be picked. If the portal patch was then rolled back, 1.2 would be picked.

Alternatively we could always just leave all versions, and always pick the most recent console version, however rollbacks would be an issue. We would need some way for the user to manually revert if there was a bug (perhaps just having them delete the bad version).

-Jason


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

jtgreene
Administrator

On Dec 17, 2012, at 4:12 PM, Jason Greene <[hidden email]> wrote:

> In order to support multiple derived products based on EAP, we need a solution that allows the console to "emulate" plug-ability. By "emulate", I mean that until we have a dynamic rendering engine (AS8/EAP7), we still have to deal with the fact that GWT requires static compilation.

For reference I recommend looking at this current proposal for multiple product handling:
https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization

Note that the "add-on" product case is what makes this capability important (you can have N add-on products side by side).

-Jason
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

Rob Cernich
In reply to this post by jtgreene
Hey Jason,

This sounds great.  Just a few questions:

Will there be some sort of process for updating the references?  For example, a new version of the SwitchYard extension is released, how do I communicate that the reference needs to be updated to point to the latest version?  Would creating a JIRA and submitting a patch suffice?  How would I know when a new version of the console is available, specifically the one that references the updated SwitchYard extension?

Best,
Rob

----- Original Message -----

> In order to support multiple derived products based on EAP, we need a
> solution that allows the console to "emulate" plug-ability. By
> "emulate", I mean that until we have a dynamic rendering engine
> (AS8/EAP7), we still have to deal with the fact that GWT requires
> static compilation.
>
> The first component of the proposal is that the console have a serial
> version stream which includes *all* plugins. Every derivative
> product will need to contribute a plugin which is pulled into the
> serial version stream via reference. This means that every console
> release will need to verify compatibility with old and new versions
> of all products. This should not be too big of a deal because the
> management policies require that we maintain compatibility anyway.
>
> The second component is that every product (and its patch updates if
> features are added) will bundle a version of the console which
> includes support for the product. At runtime the server will then
> simply pick the most recent version available. This will allow for
> every copy to maintain a clear ownership. So for example, if you
> install a patch which brings in console version 1.7, that version
> can be removed and the other available versions can be used.
>
> An example is:
>
> /consoles/1.1 (Installed by EAP)
> /consoles/1.2 (Installed by Portal)
> /consoles/1.3 (Installed by BRMS)
> /consoles/1.4 (installed by a Portal patch)
>
> So in this case the server would start with 1.4. If BRMS was removed,
> 1.4 would be picked. If the portal patch was then rolled back, 1.2
> would be picked.
>
> Alternatively we could always just leave all versions, and always
> pick the most recent console version, however rollbacks would be an
> issue. We would need some way for the user to manually revert if
> there was a bug (perhaps just having them delete the bad version).
>
> -Jason
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

jtgreene
Administrator

On Dec 17, 2012, at 4:30 PM, Rob Cernich <[hidden email]> wrote:

> Hey Jason,
>
> This sounds great.  Just a few questions:
>
> Will there be some sort of process for updating the references?  For example, a new version of the SwitchYard extension is released, how do I communicate that the reference needs to be updated to point to the latest version?  Would creating a JIRA and submitting a patch suffice?  How would I know when a new version of the console is available, specifically the one that references the updated SwitchYard extension?


That process would depend on what Heiko uses for the console, but in theory it would be a "component" update to the console. I imagine something along the lines of sending in a pull request to the console which does a pom.xml update to include the latest switchyard extension. This would probably be backed by JIRA for that console project using it's own version stream.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

Heiko Braun
In reply to this post by jtgreene


I am not sure I fully understand the proposal.

Serial version stream that includes all plugins? Can you elaborate on that?
You mean one console project, containing all possible extensions?

Every product bundles a version of the console:
I think that is what we have atm, no? What's wrong with that?

Generally speaking ("emulate pluggability"):
Why is everybody so worried about the compile time extensions? It's a perfectly valid use case IMO, that fully leverages all benefits we gain from using GWT in the first place. Can you elaborate why this should be done differently?

Regards, Heiko

On Dec 17, 2012, at 11:12 PM, Jason Greene <[hidden email]> wrote:

> In order to support multiple derived products based on EAP, we need a solution that allows the console to "emulate" plug-ability. By "emulate", I mean that until we have a dynamic rendering engine (AS8/EAP7), we still have to deal with the fact that GWT requires static compilation.
>
> The first component of the proposal is that the console have a serial version stream which includes *all* plugins. Every derivative product will need to contribute a plugin which is pulled into the serial version stream via reference. This means that every console release will need to verify compatibility with old and new versions of all products. This should not be too big of a deal because the management policies require that we maintain compatibility anyway.
>
> The second component is that every product (and its patch updates if features are added) will bundle a version of the console which includes support for the product. At runtime the server will then simply pick the most recent version available. This will allow for every copy to maintain a clear ownership. So for example, if you install a patch which brings in console version 1.7, that version can be removed and the other available versions can be used.
>
> An example is:
>
> /consoles/1.1 (Installed by EAP)
> /consoles/1.2 (Installed by Portal)
> /consoles/1.3 (Installed by BRMS)
> /consoles/1.4 (installed by a Portal patch)
>
> So in this case the server would start with 1.4. If BRMS was removed, 1.4 would be picked. If the portal patch was then rolled back, 1.2 would be picked.
>
> Alternatively we could always just leave all versions, and always pick the most recent console version, however rollbacks would be an issue. We would need some way for the user to manually revert if there was a bug (perhaps just having them delete the bad version).
>
> -Jason
>


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

Heiko Braun
In reply to this post by jtgreene


In these examples, why would product A and product B install two different consoles that overlay each other?
If a product console requires functionality for both A and B it would be in the same console, no?


On Dec 17, 2012, at 11:12 PM, Jason Greene <[hidden email]> wrote:

An example is:

/consoles/1.1 (Installed by EAP)
/consoles/1.2 (Installed by Portal)
/consoles/1.3 (Installed by BRMS)
/consoles/1.4 (installed by a Portal patch)

So in this case the server would start with 1.4. If BRMS was removed, 1.4 would be picked. If the portal patch was then rolled back, 1.2 would be picked.


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

jtgreene
Administrator
In reply to this post by Heiko Braun

On Dec 19, 2012, at 12:50 PM, Heiko Braun <[hidden email]> wrote:

>
>
> I am not sure I fully understand the proposal.
>
> Serial version stream that includes all plugins? Can you elaborate on that?
> You mean one console project, containing all possible extensions?

Yes so like following my example below console 1.2 contains Portal and EAP support, then in 1.3 you add BRMS and 1.4 you improve portal support.

1.4 then includes Portal, EAP, and BRMs plugins.

>
> Every product bundles a version of the console:
> I think that is what we have atm, no? What's wrong with that?

Sort of. The problem is you can only have one console for each product. So like this is to support an "add-on" which adds portal capability to EAP. If I install portal i need the console to support it, so it would include 1.2 with it. Then later on if I install BRMS into the same install as well, the console needs to support both Portal and BRMS and EAP (all supportable in the same process).

* Small disclaimer that BRMS has not yet decided if it will be a completely separate product or add on like thing such as portal *

>
> Generally speaking ("emulate pluggability"):
> Why is everybody so worried about the compile time extensions? It's a perfectly valid use case IMO, that fully leverages all benefits we gain from using GWT in the first place. Can you elaborate why this should be done differently?

Because you can't drop in new capabilities without recompiling. If an ISV or user decides to write a subsystem, they have to recompile the console with all of the appropriate plugins to get the functionality, which sucks. So EAP7 we have to be more data-driven and dynamic.

>
> Regards, Heiko
>
> On Dec 17, 2012, at 11:12 PM, Jason Greene <[hidden email]> wrote:
>
>> In order to support multiple derived products based on EAP, we need a solution that allows the console to "emulate" plug-ability. By "emulate", I mean that until we have a dynamic rendering engine (AS8/EAP7), we still have to deal with the fact that GWT requires static compilation.
>>
>> The first component of the proposal is that the console have a serial version stream which includes *all* plugins. Every derivative product will need to contribute a plugin which is pulled into the serial version stream via reference. This means that every console release will need to verify compatibility with old and new versions of all products. This should not be too big of a deal because the management policies require that we maintain compatibility anyway.
>>
>> The second component is that every product (and its patch updates if features are added) will bundle a version of the console which includes support for the product. At runtime the server will then simply pick the most recent version available. This will allow for every copy to maintain a clear ownership. So for example, if you install a patch which brings in console version 1.7, that version can be removed and the other available versions can be used.
>>
>> An example is:
>>
>> /consoles/1.1 (Installed by EAP)
>> /consoles/1.2 (Installed by Portal)
>> /consoles/1.3 (Installed by BRMS)
>> /consoles/1.4 (installed by a Portal patch)
>>
>> So in this case the server would start with 1.4. If BRMS was removed, 1.4 would be picked. If the portal patch was then rolled back, 1.2 would be picked.
>>
>> Alternatively we could always just leave all versions, and always pick the most recent console version, however rollbacks would be an issue. We would need some way for the user to manually revert if there was a bug (perhaps just having them delete the bad version).
>>
>> -Jason
>>
>


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

Heiko Braun


so you are saying it will be possible to install different addons on a given EAP installation?
i.e. customers can begin with EAP6 then put Portal and BRMS on it? I was thinking these are always  products on their own?

On Dec 19, 2012, at 7:57 PM, Jason Greene <[hidden email]> wrote:

Sort of. The problem is you can only have one console for each product. So like this is to support an "add-on" which adds portal capability to EAP. If I install portal i need the console to support it, so it would include 1.2 with it. Then later on if I install BRMS into the same install as well, the console needs to support both Portal and BRMS and EAP (all supportable in the same process).


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

jtgreene
Administrator
That's correct. We are going to support both additional product features we call "add-ons", as well as completely separate installations which are truly different. The longer term goal (around EAP7) is that all "layered" products will be add-ons such that users can mix and match the features between them.

On Dec 19, 2012, at 1:00 PM, Heiko Braun <[hidden email]> wrote:

>
>
> so you are saying it will be possible to install different addons on a given EAP installation?
> i.e. customers can begin with EAP6 then put Portal and BRMS on it? I was thinking these are always  products on their own?
>
> On Dec 19, 2012, at 7:57 PM, Jason Greene <[hidden email]> wrote:
>
>> Sort of. The problem is you can only have one console for each product. So like this is to support an "add-on" which adds portal capability to EAP. If I install portal i need the console to support it, so it would include 1.2 with it. Then later on if I install BRMS into the same install as well, the console needs to support both Portal and BRMS and EAP (all supportable in the same process).
>


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

jtgreene
Administrator
In reply to this post by jtgreene

On Dec 19, 2012, at 12:57 PM, Jason Greene <[hidden email]> wrote:

>>
>> Generally speaking ("emulate pluggability"):
>> Why is everybody so worried about the compile time extensions? It's a perfectly valid use case IMO, that fully leverages all benefits we gain from using GWT in the first place. Can you elaborate why this should be done differently?
>
> Because you can't drop in new capabilities without recompiling. If an ISV or user decides to write a subsystem, they have to recompile the console with all of the appropriate plugins to get the functionality, which sucks. So EAP7 we have to be more data-driven and dynamic.

I think we agreed on this part right. I mean the last discussions we had with you Stan and David etc was that this is where we are going? Although maybe you just meant it was worth looking into and you hadn't made up your mind.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

Heiko Braun
In reply to this post by jtgreene
ok, in that case what you suggested makes complete sense.

On Dec 19, 2012, at 8:04 PM, Jason Greene <[hidden email]> wrote:

> That's correct. We are going to support both additional product features we call "add-ons", as well as completely separate installations which are truly different. The longer term goal (around EAP7) is that all "layered" products will be add-ons such that users can mix and match the features between them.
>
> On Dec 19, 2012, at 1:00 PM, Heiko Braun <[hidden email]> wrote:
>
>>
>>
>> so you are saying it will be possible to install different addons on a given EAP installation?
>> i.e. customers can begin with EAP6 then put Portal and BRMS on it? I was thinking these are always  products on their own?
>>
>> On Dec 19, 2012, at 7:57 PM, Jason Greene <[hidden email]> wrote:
>>
>>> Sort of. The problem is you can only have one console for each product. So like this is to support an "add-on" which adds portal capability to EAP. If I install portal i need the console to support it, so it would include 1.2 with it. Then later on if I install BRMS into the same install as well, the console needs to support both Portal and BRMS and EAP (all supportable in the same process).
>>
>


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

Heiko Braun
In reply to this post by jtgreene
Yes that's correct. It's what I presented at the last developer meeting for AS8. 

I just wasn't aware that we think about product plugins in general. Because up to this point, the current extension mechanism fits the product reality quiet well. But I agree, once products can be enriched by adding components at will, we need an alternative solution.


 
On Dec 19, 2012, at 8:06 PM, Jason Greene <[hidden email]> wrote:

Because you can't drop in new capabilities without recompiling. If an ISV or user decides to write a subsystem, they have to recompile the console with all of the appropriate plugins to get the functionality, which sucks. So EAP7 we have to be more data-driven and dynamic.

I think we agreed on this part right. I mean the last discussions we had with you Stan and David etc was that this is where we are going? Although maybe you just meant it was worth looking into and you hadn't made up your mind.


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

Brian Stansberry
In reply to this post by Heiko Braun
For more details on some thinking on things like this "add-on" notion, see

https://community.jboss.org/docs/DOC-47927


On 12/19/12 1:07 PM, Heiko Braun wrote:

> ok, in that case what you suggested makes complete sense.
>
> On Dec 19, 2012, at 8:04 PM, Jason Greene <[hidden email]> wrote:
>
>> That's correct. We are going to support both additional product features we call "add-ons", as well as completely separate installations which are truly different. The longer term goal (around EAP7) is that all "layered" products will be add-ons such that users can mix and match the features between them.
>>
>> On Dec 19, 2012, at 1:00 PM, Heiko Braun <[hidden email]> wrote:
>>
>>>
>>>
>>> so you are saying it will be possible to install different addons on a given EAP installation?
>>> i.e. customers can begin with EAP6 then put Portal and BRMS on it? I was thinking these are always  products on their own?
>>>
>>> On Dec 19, 2012, at 7:57 PM, Jason Greene <[hidden email]> wrote:
>>>
>>>> Sort of. The problem is you can only have one console for each product. So like this is to support an "add-on" which adds portal capability to EAP. If I install portal i need the console to support it, so it would include 1.2 with it. Then later on if I install BRMS into the same install as well, the console needs to support both Portal and BRMS and EAP (all supportable in the same process).
>>>
>>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

Tristan Tarrant
Brian,

the "add-on" should also be able to affect the CLI.
for JDG we need to disable some CLI functionality while also addding our
own.

Tristan

On 12/19/2012 08:15 PM, Brian Stansberry wrote:

> For more details on some thinking on things like this "add-on" notion, see
>
> https://community.jboss.org/docs/DOC-47927
>
>
> On 12/19/12 1:07 PM, Heiko Braun wrote:
>> ok, in that case what you suggested makes complete sense.
>>
>> On Dec 19, 2012, at 8:04 PM, Jason Greene <[hidden email]> wrote:
>>
>>> That's correct. We are going to support both additional product features we call "add-ons", as well as completely separate installations which are truly different. The longer term goal (around EAP7) is that all "layered" products will be add-ons such that users can mix and match the features between them.
>>>
>>> On Dec 19, 2012, at 1:00 PM, Heiko Braun <[hidden email]> wrote:
>>>
>>>>
>>>> so you are saying it will be possible to install different addons on a given EAP installation?
>>>> i.e. customers can begin with EAP6 then put Portal and BRMS on it? I was thinking these are always  products on their own?
>>>>
>>>> On Dec 19, 2012, at 7:57 PM, Jason Greene <[hidden email]> wrote:
>>>>
>>>>> Sort of. The problem is you can only have one console for each product. So like this is to support an "add-on" which adds portal capability to EAP. If I install portal i need the console to support it, so it would include 1.2 with it. Then later on if I install BRMS into the same install as well, the console needs to support both Portal and BRMS and EAP (all supportable in the same process).
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Dyanmic console module loading for multi-product in EAP6*

Brian Stansberry
We do need to make the CLI dynamically extendable; that's a good point.
Alexey has been looking at that; I'll have a think about the module
loading implication of doing that.

If you are disabling functionality, you are by definition not an add-on.
I can't see EDG/JDG fitting into this scheme until what I describe as
the "distribution base" in that wiki is re-scoped to something smaller
than the current full-EE AS7 appserver. Perhaps some disabling could be
done by installing as a layered distribution on top of AS7, but I
suspect that won't be sufficient for everything you guys want to disable.

On 12/20/12 7:09 AM, Tristan Tarrant wrote:

> Brian,
>
> the "add-on" should also be able to affect the CLI.
> for JDG we need to disable some CLI functionality while also addding our
> own.
>
> Tristan
>
> On 12/19/2012 08:15 PM, Brian Stansberry wrote:
>> For more details on some thinking on things like this "add-on" notion,
>> see
>>
>> https://community.jboss.org/docs/DOC-47927
>>
>>
>> On 12/19/12 1:07 PM, Heiko Braun wrote:
>>> ok, in that case what you suggested makes complete sense.
>>>
>>> On Dec 19, 2012, at 8:04 PM, Jason Greene <[hidden email]>
>>> wrote:
>>>
>>>> That's correct. We are going to support both additional product
>>>> features we call "add-ons", as well as completely separate
>>>> installations which are truly different. The longer term goal
>>>> (around EAP7) is that all "layered" products will be add-ons such
>>>> that users can mix and match the features between them.
>>>>
>>>> On Dec 19, 2012, at 1:00 PM, Heiko Braun <[hidden email]> wrote:
>>>>
>>>>>
>>>>> so you are saying it will be possible to install different addons
>>>>> on a given EAP installation?
>>>>> i.e. customers can begin with EAP6 then put Portal and BRMS on it?
>>>>> I was thinking these are always  products on their own?
>>>>>
>>>>> On Dec 19, 2012, at 7:57 PM, Jason Greene <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Sort of. The problem is you can only have one console for each
>>>>>> product. So like this is to support an "add-on" which adds portal
>>>>>> capability to EAP. If I install portal i need the console to
>>>>>> support it, so it would include 1.2 with it. Then later on if I
>>>>>> install BRMS into the same install as well, the console needs to
>>>>>> support both Portal and BRMS and EAP (all supportable in the same
>>>>>> process).
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev