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
>
>