[
https://issues.apache.org/jira/browse/MYFACES-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933657#action_12933657
]
Leonardo Uribe commented on MYFACES-2976:
-----------------------------------------
I have reviewed the patch and it looks good. It is a very clever solution the
one used on FactoryFinder. Since all classes are in a single bundle, just
fallback to FactoryFinder classLoader is enough. In MyFaces
javax.faces.FactoryFinder class we have two maps:
/**
* used as a monitor for itself and _factories. Maps in this map are used
as monitors for themselves and the
* corresponding maps in _factories.
*/
private static Map<ClassLoader, Map<String, List<String>>>
_registeredFactoryNames = new HashMap<ClassLoader, Map<String, List<String>>>();
/**
* Maps from classLoader to another map, the container (i.e. Tomcat) will
create a class loader for each web app
* that it controls (typically anyway) and that class loader is used as the
key.
*
* The secondary map maps the factory name (i.e.
FactoryFinder.APPLICATION_FACTORY) to actual instances that are
* created via getFactory. The instances will be of the class specified in
the setFactory method for the factory
* name, i.e. FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
MyFactory.class).
*/
private static Map<ClassLoader, Map<String, Object>> _factories = new
HashMap<ClassLoader, Map<String, Object>>();
In theory we use the webapp classloader as a "key" to diferentiate between
Factories created by different webapp living on a same server. This solution
keeps using webapp classloader as a key, but since not all packages are
exported from the bundle, the fallback just try to find them inside myfaces
bundle and do the magic in a better way.
I tried long time ago on MYFACES-2290 different alternatives, but those ones
involves have an alternate javax.faces.FactoryFinder class (because we was
thinking on keep myfaces-api and myfaces-impl jars in different bundles). But
this solution has the advantage that we will only have one
javax.faces.FactoryFinder implementation, and we just need to rewrite the
MANIFEST.MF file for the specific bundle.
The only thing to get better is instead add this package as Export-Package in
MANIFEST.MF:
org.apache.myfaces.config.impl.digester.elements
use this one:
org.apache.myfaces.config.element
In MYFACES-2945, I'll add some code to make these interfaces public, so please
use this package instead.
> Support hiding myfaces impl classes in osgi, and provide a single osgi bundle
> for api + impl
> --------------------------------------------------------------------------------------------
>
> Key: MYFACES-2976
> URL: https://issues.apache.org/jira/browse/MYFACES-2976
> Project: MyFaces Core
> Issue Type: Improvement
> Components: Extension Feature
> Affects Versions: 2.0.3-SNAPSHOT
> Reporter: David Jencks
> Assignee: Jakob Korherr
> Attachments: MYFACES-2976.diff
>
>
> The current osgi solution of using require-bundle between the api and impl
> jars is generally thought of as osgi worst-practice and just doesn't work
> with snapshot versions (presumably a bug in the bundle plugin).
> Also this does not easily support hiding the impl classes.
> Geronimo would like to use a single bundle containing both api and impl and
> hide the impl classes as much as possible. This requires some slight
> modifications to the FactoryFinder so that impl classes can be loaded from
> the same classloader as FactoryFinder if they are not visible to the context
> class loader.
> I think myfaces would be the best place for this combined bundle but geronimo
> can build it if necessary. The FactoryFinder classloader changes are
> therefore more important.
> I've suggested a module name which maps to the bundle symbolic name well, as
> this seems to be the preferred maven/osgi strategy at apache.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
