[jboss-as7-dev] AS7-1807

[Heiko Braun]

To what degree would this impact the web management interface?

Regards, Heiko

On Dec 30, 2011, at 6:33 AM, Jason T. Greene wrote:

> I have committed a slightly different solution that is triggered by 
> creating an optional product.conf in the bin directory. This file 
> specifies the "slot" to load for the product definition module 
> (org.jboss.as.product). This module includes a MANIFEST.MF which defines 
> a product name, a product version, and also the slot to use for the 
> console. These values are used to compute startup log messages and are 
> also present as root attributes in the management model. The use of the 
> indirection file avoids forcing IDEs or other launchers to know the 
> product to pass as a parameter, and it also allows for multiple 
> different product definitions modules.
> 
> If there is no product.conf, standard community behavior is exhibited.
> 
> I compiled a mock EAP 6.0 example using the EAP L&F build of the console:
> 
> Just extract the following in jboss.home:
> http://dl.dropbox.com/u/712508/prod-example.zip
> 
> On 12/13/11 10:06 AM, Jason T. Greene wrote:
>> I think we are intermixing maven modules and jboss modules here. I think
>> it's very desirable that we have a *different* jboss module per product
>> so that there is no delta required between the AS7 core platform build
>> and the product. However we still need that common name, so a jboss
>> module alias works well.
>> 
>> The code inside of AS somewhere does
>> moduleLoader.findModule("org.jboss.as.product") or whatever, and we just
>> have one tiny module.xml that aggregates the community product module.
>> 
>> None of this though needs a maven module, it can all just be built from
>> build. The product process simply has to replace that one "alias"
>> module.xml.
>> 
>> 
>> On 12/13/11 9:59 AM, Brian Stansberry wrote:
>>> I have a feeling this isn't really answering your question, but here goes...
>>> 
>>> I vaguely envisioned this as being based on a ServiceLoader. So we would
>>> define an interface. In an artifact that will pretty much never change.
>>> So products can depend on version 1.0 of that interface pretty much
>>> forever. Different products would have a module that implements that
>>> interface and exposes its impl via ServiceLoader. The build would deal
>>> with deal with getting the correct module in place.
>>> 
>>> Since the interface can pretty much never change, it should be real
>>> generic. Probably just provides a properties map.
>>> 
>>> Map<String, String>   getProductConfigurationSettings()
>>> 
>>> On 12/12/11 5:19 PM, Paul Gier wrote:
>>>> I started working on a way to modularize the product name and version in
>>>> the startup/shutdown logs of AS7 [1][2].  There is a new module called
>>>> "product" which contains the product name and version.  However this
>>>> approach doesn't seem good to me because the "host-controller",
>>>> "process-controller", and "server" modules all now have dependencies on
>>>> this new module.
>>>> 
>>>> Ideally, I want to set this up so that there is sort of a placeholder
>>>> product name/version used during the build or these modules, but then
>>>> this can be overridden by the product module later in the build.  Anyone
>>>> have suggestions about how to do this?
>>>> 
>>>> Thanks!
>>>> 
>>>> [1]https://github.com/pgier/jboss-as/commits/AS7-1807
>>>> [2]https://issues.jboss.org/browse/AS7-1807
>>>> 
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

--

Heiko Braun
Senior Software Engineer
JBoss by Red Hat
http://about.me/hbraun





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20120109/d9c1be1c/attachment.html