On Feb 6, 2008, at 9:49 PM, Kedar Mhaswade wrote:
>
>
> Jerome Dochez wrote:
>> Kedar Mhaswade wrote:
>>>
>>>
>>> Jerome Dochez wrote:
>>>> Sreenivas Munnangi wrote:
>>>>> Bill Shannon wrote:
>>>>>> Sreenivas Munnangi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> The issue of workspace, specifically organizing admin source
>>>>>>> code corresponding to v3 modularization has been discussed
>>>>>>> among admin team members and arrived at the final structure.
>>>>>>> Following link provides details.
>>>>>>>
>>>>>>> http://wiki.glassfish.java.net/Wiki.jsp?page=V3AdminWorkspaceStructure
>>>>>>>
>>>>>>> Pl. let us know if you have any suggestions.
>>>>>>
>>>>>> Is each module in your list a separate HK2 module?
>>>>>> Or do the submodules correspond to HK2 modules?
>>>>> In the following, admin is a HK2 module with pacakages
>>>>> org.glassfish.web.admin.cli, org.glassfish.web.admin.amx,
>>>>> org.glassfish.web.admin.amx.impl, etc.
>>>> I think you meant admin-web is an HK2 module... we need to have
>>>> different names for admin module per container...
>>>
>>> Sorry for the confusion, but I am still not sure if admin code in
>>> every container needs to be an HK2 module on its own. I don't
>>> think it satisfies
>>> the criteria for Module definition:
>>> http://wiki.glassfish.java.net/Wiki.jsp?page=V3EngineersGuide#section-V3EngineersGuide-1.1WhatIsAModule
>>>
>>> Given that, is it logical to make admin part of every container
>>> (or other
>>> module) an HK2 module?
>>>
>>> For example, I don't think the admin classes/interfaces for the
>>> web-tier would
>>> go in its separate jar file like webtier-admin.jar. A more logical
>>> place for
>>> them is webtier.jar itself. That's why I was leaning more towards
>>> not making the
>>> admin code for a container/module a separate module.
>>>
>> good point...
>> Some these interfaces might actually rely on features not present
>> in a particular distributions, like AMX or most likely the GUI so
>> as you mention, mandatory admin interfaces of a module like the CLI
>> and monitor could be in the webtier.jar to follow your example. The
>> other ones might be in an admin-optional module. I don't think we
>> need to necessary resolve this today as we are not sure what is
>> mandatory/optional yet.
>> my suggestion about using a different module was to stick more with
>> areas of responsibilities with different development teams working
>> on a single module like webtier. This might be easier
>> organizationally.
>> what do you think ?
>
> I was under the impression that a particular module's admin part would
> contain any number of admin interfaces out of: CLI, AMX, GUI, Monitor.
> A (sort of) mandatory admin part of every module is "Config" or the
> config
> beans that all are familiar with. An example of such a bean is
> VirtualServer.java that defines the configuration of a virtual
> server. Thus,
> webtier.jar will always contain
> com.sun.enterprise.config.serverbeans.VirtualServer and the like.
>
> For the GF webtier, I also assumed that we will be bundling all
> these interfaces
> with the module itself. Thus, webtier.jar will contain all the
> necessary webtier
> runtime functionality + its config, commands, GUI, AMX interfaces,
> monitoring
> interfaces.
>
> An independently developed module that leverages V3 and HK2 may or
> may not have all the above admin interfaces provided with its jar.
> It may
> choose to provide only commands, for instance. But for
> webtier (and all the other modules like ejb-container, jdbc-ra, jms-
> ra,
> jpa implementation ... that form V3 product) we would define,
> implement and
> bundle all the above admin interfaces as mandatory ones.
>
it's not that easy ... if a module implements some admin GUI
functionality and imports some gui related classes, chances are this
module will import admin gui common module... if the admin gui is not
there, we have a problem.
Now having said that, if the only external APIs a module admin
services would import are the glassfish-api, your approach will work.
> From a size/embeddability considerations, if any of the above
> interfaces is
> deemed "unnecessary", then probably a "distribution" emerges at that
> point
> which excludes the artifacts of that particular interface. For
> example, we
> might want to build a webtier-light distribution that does not
> contain the
> GUI/AMX interfaces.
right so would not that call for separating those at the module level ?
>
>
> With these assumptions, I think making admin interfaces of webtier a
> part
> of webtier module is probably the way to go.
If our admin services only use Java EE and glassfish-api, i am fine
with that solution for now.
Just check with relevant owners, jan. mahesh and jagadish that they
are ok with the approach too.
Jerome
>
>
>> Jerome
>>>>>
>>>>> /v3
>>>>> /v3/web
>>>>> /v3/web/<core modules>
>>>>> /v3/web/admin
>>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/cli
>>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/amx
>>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/amx/impl
>>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/monitor
>>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/plugin/impl
>>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/common
>>>>>>
>>>>>> How do the modules relate to Maven projects? Which
>>>>>> modules are sub-projects and what is the parent project?
>>>>> For distribution/packaging purposes, web is the parent project
>>>>> with admin being the sub-project. So whenever web is built,
>>>>> admin is also built as part of it.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>