In general, a module will be shared by all its user's while a plain
old jar file will be loaded by all the importing modules classloaders
with no sharing. This can be inefficient but can also obviously lead
to ClassCastException if you end up passing around instances.
My advice on this matter is to have everything packaged as a module
even if it does not use HK2 services. That does not apply to jars
which need to be used in different executable environment that do not
rely on a modular subsystem. That's the case of universal so we could
leave it as jar if it is not used in multiple modules in the appserver.
Another way to fix that that problem is to leave code in a plain old
jar like grizzly (grizzly.jar) and have a module definition that wraps
the grizzly jar and its jar dependencies in a module. That's what we
do in grizzly-module for instance. That way, when using grizzly on non
modular env, you use the jar, when using a modular subsystem, you use
the grizzly module.
Jerome
On Mar 14, 2008, at 12:43 PM, Kedar Mhaswade wrote:
> Sahoo wrote:
>> What stops a HK2 module jar from being used in a non-HK2 environment?
>> Thanks,
>> Sahoo
>
> Sahoo,
>
> I think the basic question is if I delivering some utility code that
> - does not use HK-2 facilities, annotations etc.
> - provides simple API and implementation to do something,
>
> what is the best way to "package" it -- as a "jar" or "hk2-jar"?
>
> For such a module, what additional benefits would you get by
> packaging it as an hk2-jar?
>
> Regards,
> Kedar
>
>> Byron Nevins wrote:
>>> Yes.
>>> So that it can be used by non-hk2 clients as well as hk2-modules.
>>>
>>>
>>> Sahoo wrote:
>>>> Byron,
>>>>
>>>> Have you authored org.glassfish.common:universal module? Why is
>>>> it not a HK2 module?
>>>>
>>>> Thanks,
>>>> Sahoo
>>>
>> ---------------------------------------------------------------------
>> 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
>