it has one drawback however, it becomes very difficult for external
folks to know what are the APIs they can use to extend the application
server with a guaranteed compatibility level between releases and the
APIs that are internal to our implementation. Also when developing
GlassFish extensions, its much simpler to have only one dependency
with all public APIs co-located. It is certainly is not optimum in
terms of modularization, yet we should make extending GlassFish as
easy as possible.
Once we complete the switch to OSGi, I think we can easily create a
bundle that would re-exports these public APIs in one convenient
location but that does not remove the hard work of understanding what
can or could be re-used by GlassFish extensions.
Jerome
On May 16, 2008, at 9:41 AM, Lloyd L Chambers wrote:
> AMX follows this model: amx-api and amx-impl. It works very well
> IMO\, and is easily understood, with clear ownership.
>
> On May 16, 2008, at 7:18 AM, Sahoo wrote:
>
>> Having a module internal-ee-api which hosts all kinds of APIs from
>> different containers is a bad idea, as there is no clear owner of
>> that module. Hence, I suggested hosting connector apis in connector
>> module. If you don't want the implementation module to be loaded
>> eagerly, then you can have two modules under connector: connector-
>> api and connector-impl.
>>
>> Thanks,
>> Sahoo
>>
>> Jagadish Prasath Ramu wrote:
>>> I am trying to move these api classes to internal-ee-api as these
>>> are
>>> meant to be used by other containers/modules like transaction, ejb,
>>> naming, jpa etc. These apis need to be in a separate module (other
>>> than
>>> connector-runtime implementation) so as to :
>>> 1) avoid loading the implementation module during appserver
>>> startup /
>>> startup of a module that depends on the api.
>>> 2) avoid any cyclic dependency issue.
>>>
>>> Thanks,
>>> -jagadish
>>>
>>>
>>> On Thu, 2008-05-15 at 11:10 -0700, Jerome Dochez wrote:
>>>
>>>> On May 15, 2008, at 11:06 AM, Sahoo wrote:
>>>>
>>>>
>>>>> Why are APIs that are exposed by connector-runtime not part of
>>>>> connector module?
>>>>>
>>>> right we should only move these APIs to an API module if we
>>>> expect different implementations (so we avoid repackaging them
>>>> each time) or plugability (feature may or may not be present, we
>>>> still need the interfaces even if the feature is absent).
>>>>
>>>> Jerome
>>>>
>>>>
>>>>> BTW, why is this discussion not happening on dev alias?
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>>
>>>>> Marina Vatkina wrote:
>>>>>
>>>>>> CC-ing Sahoo.
>>>>>>
>>>>>> -marina
>>>>>>
>>>>>> Jagadish Prasath Ramu wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> Based on the conventions for api's in GlassFIsh (attached mail
>>>>>>> from
>>>>>>> Jerome to dev_at_GF), I am planning to move the connector-
>>>>>>> runtime module
>>>>>>> exposed api from glassfish-ee-api to internal-ee-api.
>>>>>>>
>>>>>>> As of today, if a module is referring to glassfish-ee-api, it
>>>>>>> is only
>>>>>>> due to connector-runtime dependency. So, changing the
>>>>>>> dependency from
>>>>>>> glassfish-ee-api to internal-ee-api should be fine.
>>>>>>>
>>>>>>> I am planning to move these files early next week, I shall
>>>>>>> take care of
>>>>>>> updating all the necessary modules' dependencies.
>>>>>>>
>>>>>>> Please let me know if you have any queries by this week.
>>>>>>>
>>>>>>> I will be making necessary changes for the following modules.
>>>>>>>
>>>>>>> jpa-connector
>>>>>>> amx-impl
>>>>>>> container-common
>>>>>>> javaee-core
>>>>>>> jta
>>>>>>> ejb-container
>>>>>>> realm
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Jagadish
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> Subject:
>>>>>>> Shared modules
>>>>>>> From:
>>>>>>> Jerome Dochez <Jerome.Dochez_at_Sun.COM>
>>>>>>> Date:
>>>>>>> Fri, 07 Mar 2008 16:59:41 -0800
>>>>>>> To:
>>>>>>> dev_at_glassfish.dev.java.net
>>>>>>>
>>>>>>>
>>>>>>> Hi All
>>>>>>>
>>>>>>> Some have raised questions on how to package shared or public
>>>>>>> APIs in GlassFish V3. although there are no miracle recipe,
>>>>>>> there are a few modules that can be considered when packaging
>>>>>>> shared or public (including semi-public) classes.
>>>>>>> + common-util
>>>>>>>
>>>>>>> You should use this module when you need to package classes
>>>>>>> that do not depend on anything but JDK classes and that can
>>>>>>> be useful to other modules. Things like logging, common io
>>>>>>> routines and utility classes are a good fit for this module
>>>>>>>
>>>>>>> + common-ee-util
>>>>>>>
>>>>>>> This is a package for utility classes that are meant to be
>>>>>>> shared by Java EE containers, this module imports the Java EE
>>>>>>> APIs and can container common services like injection
>>>>>>> utilities, common security code etc.
>>>>>>>
>>>>>>> + internal-api
>>>>>>>
>>>>>>> these are semi public APIs of glassfish, meaning interfaces
>>>>>>> and contracts we used to implement GlassFish but are not
>>>>>>> meant to be the official extension point for external tools
>>>>>>> and plugins or extra containers. It's a free world so people
>>>>>>> can use it at their own risk but you don't have to provide
>>>>>>> backward compatibility to classes packaged in this module.
>>>>>>> Those internal APIs are meant to be integration points
>>>>>>> between the different part of the application, yet not part
>>>>>>> of the public extensibility APIs.
>>>>>>>
>>>>>>> + internal-ee-api
>>>>>>>
>>>>>>> same as internal-api but using depending on the Java EE APis.
>>>>>>> this module is empty for now, I will start moving some
>>>>>>> classes there soon.
>>>>>>>
>>>>>>> + glassfish-api
>>>>>>>
>>>>>>> These are the official blessed extensibility APIs internal/
>>>>>>> external folks can use to extend GlassFish, it contains
>>>>>>> contracts definition like Startup, AdminCommand and other
>>>>>>> hooks for container providers. None of these APIs are Java EE
>>>>>>> dependent as these APIs ship in nucleus which is the smallest
>>>>>>> glassfish distribution with no Java EE dependencies.
>>>>>>>
>>>>>>> + glassfish-ee-api
>>>>>>>
>>>>>>> Same as above but dependent on the JavaEE API, gives access
>>>>>>> to things like the InjectionManager, NamingManager for Java
>>>>>>> EE derived container access to GlassFish services.
>>>>>>>
>>>>>>> Let me know if you have any questions/issues.
>>>>>>>
>>>>>>> Thanks, Jerome
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>
>
> ---
> Lloyd L Chambers
> lloyd.chambers_at_sun.com
> Sun Microsystems, Inc
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>