---
Kedar Mhaswade wrote:
> Hi Mike,
>
> I am afraid, I was not aware of this (yet another) way of extending
> GlassFish. Thank you for letting me know. I was under the impression
> that some work you guys did for GlassFish V2 ESB console is part
> of GlassFish V2.
The JBI Console is integrated into 9.1FCS.  Anissa, Ken, and others have
been aware of our JBI Console extension plans (for 9.1ur1 and SailFin)
for some time;  I routinely attend admin-gui ITeam meetings to discuss this.
>
> There are a bunch of questions in this regard:
> - Where do your implementation artifacts (e.g. the XML descriptors,
>   Java classes etc.) go on the disk? IOW, how does the file layout
>   look like?
Our implementation is mostly in publish/glassfish/jbi/lib/jbi-*.jar 
filles, see diagram here:
 > 
http://wiki.open-esb.java.net/Wiki.jsp?page=SierraUpdateWebConsoleGfIt3571Review
with minimal "hook" and configuration in glassfish/admin-gui files found in
publish/glassfish/lib/install/applications/admingui/adminGUI_war/WEB-INF
>
> - Is this veneer available as a separate download from OpenESB web-site
>   that can be installed atop an existing GlassFish installation?
No.  The open-esb mplementation jars are promoted into GlassFish.  It is 
a goal
that one could simply overlay the publish/glassfish/jbi/lib/jbi*.jar 
files to get a
different version, but this wouldn't necessarily be a published/stable 
interface,
and only used by our installer(s).
>
> - What other forms of integration are available? 
Different installers install different GlassFish/Open ESB/JBI Component 
configurations,
but the difference is usually for which components are bundled.  Future 
installers may
support different versions of GlassFish (and different versions of the 
console).  I'm not
sure if I'm answering your question... if not, can you ask a more 
specific question?
> Is GlassFish V2
>   update center aware of this?
I don't think so (nor do I think this is needed).  The extension mechanism
is mainly to support the Sierra product installer (without being tied to
GlassFish feature/code freeze schedule for current or future GlassFish 
work).
>
> - Do you use any API to enable this? Is that a public API of V2?
>   This is critical because it is better to rely only on public API.
Our JBI (not general) "extension" is a private contract between JBI code 
integrated in glassfish cvs and JBI code integrated in open-esb cvs.  
BTW, the "APIs" we use are provided by: JavaServer Faces, Woodstock, 
Jsftemplating, admin/admin-gui/AMX MBeans, JBI 1.0, open-esb, JMX, 
JavaEE, etc. 
>
> - Have you looked at the current addon framework?
For 9.1 FCS, the decision was made for JBI *not* to be an add-on, so no, 
we have not looked at the addon framework for use by the JBI console.  
Does the addon framework address the integration points needed by the  
JBI console?   I had the impression that it does not.
We have met with GlassFish engineering many times on this and 
implemented the agreed-to 9.1FCS  JBI Console changes in GlassFish cvs.  
The JBI console is considered to be tightly integrated with GlassFish 
(as are the CLI commands), for at least the "core" JBI commands.   As we 
evolve to support Sierra (Java CAPS5.2) there are requirements for 
extensions beyond this.
>
> Finally, yes, we do need to be on the same page as far as the 
> extensibility
> of GlassFish V2 administration is concerned. So, we need your help 
> since you
> are the guys who are going to extend V2. It's not only command line 
> interface. 
This is a worthwhile goal, but given resource/time constraints, we may 
not be on the same page until V3.
>
> Please subscribe to this alias and we will let you know when we should
> discuss this. It's likely to be Monday, October 1.
I'm already subscribed to admin_at_glassfish.dev.java.net.  I might be 
available to meet on Monday.
>
> Regards,
> Kedar
>
> Mike Wright wrote:
>> Hi Kedar,
>>  
>>     In simple terms, the JBI Console Extension mechanism was created 
>> so that our builds, automated tests, and product installer can more 
>> easily upgrade the JBI implementation in any GlassFish (starting with 
>> 9.1ur1).     Without this we'd have to patch several admin-gui files, 
>> creating potential maintenance problems.  (BTW, our approach works 
>> for asant and admin-gui, but not yet for asadmin CLI, because the JBI 
>> commands are tightly coupled with asadmin code and not part of our 
>> open-esb promoted .jar files.)
>>
>>
>>     There was no formal admin-gui extension mechanism in existence 
>> for 9.1ur1, so we've implemented "hooks" for our JBI pages at 
>> previously-agreed-to integration points (navigation tree, 
>> common-tasks page, cluster nodes, and online-help keys) and use the 
>> open-esb promoted JBI jars to contain the implementation.  We are 
>> just "extending" our existing JBI screens, not the console in 
>> general.  In GF V3 we could perhaps use a generalized console 
>> extension mechanism, if it were available.  But we need this 
>> capability now to facilitate our QE/QA/Doc work for already completed 
>> Sierra Milestone 1 (9.1ur1) and 2 (SailFin) features and to address 
>> the future concern that Sierra, 9.1ur1, and SailFin releases are on 
>> different schedules.
>>
>>
>>     BTW, our JBI console extension mechanism detects the case where 
>> JBI is "missing" and then simply doesn't render JBI externals in the 
>> admin-gui console (except for online-help, which we are trying to 
>> address in SailFin, so that the help reflects the capabilities that 
>> are present).    Perhaps the work we've done can help the admin-gui 
>> console develop a more generalized add-on architecture in the SailFin 
>> timeframe?
>>
>>
>> Regards,
>> Mike
>> ---
>> Kedar Mhaswade wrote:
>>> Mark,
>>>
>>> Thanks. We will look into this.
>>>
>>> BTW, what is admin console extension mechanism? Shouldn't it be the
>>> similar addon mechanism. Moreover, shouldn't all admin interfaces be
>>> part of one addon installation?
>>>
>>> - Kedar
>>>
>>> Mark S White wrote:
>>>> Kedar,
>>>> Responses inline:
>>>>
>>>> Kedar Mhaswade wrote:
>>>>> Suresh, Mark,
>>>>>
>>>>> We will need to plan for this. We need to take this up for 
>>>>> discussion at
>>>>> admin iteam meeting. Jane/Prashanth, please add it to agenda.
>>>>>
>>>>> Few questions though:
>>>>>
>>>>> - Some of the JBI admin commands were added in core GlassFish V2
>>>>>   offering, while the new proposed commands are to be added as
>>>>>   addons. Is that acceptable or would you like to have all the
>>>>>   JBI commands integrated as addon in a future JBI release?
>>>> This is acceptable. We can live with the new commands being part of 
>>>> an addon while
>>>> keeping the old commands as they are. For V3 we would probably like 
>>>> to migrate all of the
>>>> commands to the addon mechanism for consistency and ease of use.
>>>>> - What about admin console screens for the functionality 
>>>>> corresponding
>>>>>   to new commands?
>>>> This has been taken care of, we have a console extension mechanism 
>>>> that has been approved
>>>> by the console team, and is being integrated this week.
>>>>> - Is there a tentative schedule for your next release?
>>>> Dec 17, 2007: Feature complete
>>>> Feb 11, 2008: Beta
>>>> Apr 21, 2008: FCS
>>>>>
>>>>> - Kedar
>>>>>
>>>>> Suresh Potiny wrote:
>>>>>> Kedar,
>>>>>>
>>>>>> We need a solution for v2. We are okay modifying this strategy 
>>>>>> for v3 (we have to look at a number
>>>>>> of things for v3 anyway).
>>>>>>
>>>>>> Suresh
>>>>>>
>>>>>> Kedar Mhaswade wrote:
>>>>>>> Hi Mark,
>>>>>>>
>>>>>>> This is available in some shape and form and we need to finalize 
>>>>>>> it before
>>>>>>> making it a public interface. Personally, I prefer to call it 
>>>>>>> the admin
>>>>>>> addons. This is because what is true with commands is also true 
>>>>>>> with admin
>>>>>>> console or any programmatic interface that an addon would like 
>>>>>>> to provide.
>>>>>>>
>>>>>>> Unfortunately, we are still trying to decide what the best way 
>>>>>>> forward is,
>>>>>>> because we have to look for promise of V3 in this regard. There 
>>>>>>> are differences
>>>>>>> in how you would do in V2 and V3.
>>>>>>>
>>>>>>> Is your next release planned along with V3 release? If it is, 
>>>>>>> then we will
>>>>>>> certainly have a way to do this. If not, we might have to do 
>>>>>>> some work in
>>>>>>> releasing a solution that may not work with V3.
>>>>>>>
>>>>>>> Please let me know ...
>>>>>>>
>>>>>>> Regards,
>>>>>>> Kedar
>>>>>>>
>>>>>>> Mark S White wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I am the engineering manager for the team responsible for the 
>>>>>>>> JBI / Open ESB runtime and
>>>>>>>> the associated ant, asadmin, and admin console support. Our 
>>>>>>>> runtime is integrated into the
>>>>>>>> GlassFish runtime, and in the past we have added new ant tasks, 
>>>>>>>> asadmin commands, and
>>>>>>>> admin console screens to support our product.
>>>>>>>>
>>>>>>>> For our next release, we need to add a number of new commands 
>>>>>>>> to asadmin. We understand
>>>>>>>> that some work has been done to create an extension mechanism 
>>>>>>>> for asadmin whereby
>>>>>>>> commands can be added dynamically without changes to the base 
>>>>>>>> asadmin code. We would
>>>>>>>> very much like to use this mechanism to add asadmin commands in 
>>>>>>>> support of our next release.
>>>>>>>>
>>>>>>>> Could someone provide us information on whether or not this 
>>>>>>>> mechanism exists or is planned,
>>>>>>>> and how we might be able to use it? This is a critical issue 
>>>>>>>> for allowing us to implement new
>>>>>>>> functionality in a time frame that aligns with our product 
>>>>>>>> release schedule.
>>>>>>>>
>>>>>>>> thanks very much,
>>>>>>>> Mark White
>>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>