Before I spend a lot of time figuring out why FactoryFinder works in geronimo, I wonder if there is any need for any of the impl classes to be exported for any reason other than making them visible to FactoryFinder? If not then either packaging api and impl in a single bundle or making the impl bundle a fragment and the api bundle the fragment host ought to work. Obviously with a single bundle you can also export anything you want.
I think either of these solutions would be a lot more reasonable than a require-bundle that goes the opposite direction from the package dependencies. thanks david jencks On Nov 8, 2010, at 10:25 AM, Leonardo Uribe wrote: > Hi > > 2010/11/5 David Jencks <david_jen...@yahoo.com> > I'm trying to understand why the require-bundle header is in the api bundle. > This is a pretty bizarre thing to do in what I've seen of osgi. > > > Could you be more explicit about this point? I don't see anything bizarre > here. > > I took it out and geronimo-tomcat appears to work OK. Maybe because this is > because geronimo has a somewhat extended thread context classloader, but > maybe not. > > > In theory, to make JSF run it is necessary to provide a thread context > classloader. The problem is javax.faces.FactoryFinder requires it to lookup > Factory classes. There is no known valid workaround available. > > I saw some vague claims in the comments to MYFACES-2911 that the api classes > need to load impl classes, but no details. Could someone point me to the > code where this happens? There must be a better way to do this.... > > In few words, the reasons why Require-Bundle header is ok are: > > - javax.faces.FactoryFinder load impl factory classes. > - myfaces-api jar are only tested against myfaces-impl with the same number > and pass TCK test only with this combination. It is not expected people use > myfaces-api 2.0.1 and myfaces-impl 2.0.2 for a web-app for example. > > regards, > > Leonardo Uribe > > > thanks > david jencks > >
