Walid "jo" Gedeon wrote:
Hello Richard,
I think the logic is correct. You cannot dynamically attach a fragment to
an already
resolved host. Thus, the potential hosts for the fragment are only those
that are not
yet resolved.
Hmm... ok, I wasnt aware of that.

So be clear, the spec is purposely vague here. So, it doesn't forbid or mandate dynamic attachment.

Are you resolving the host first before installing the fragment?
Yes I am.

So the steps would be:
- install log4j -> Installed
- install config fragment -> Installed
- start config fragment -> Active (log4j now resolved)
- start log4j -> Active.

But what would happen if the host bundle has many fragments?

Install the host and all fragments then start the host. That is all you need to do. All fragments will be attached when resolving the host. You don't need to start fragments, because they don't have an activator in the first place.

-> richard

Thanks,
w

On Mon, Nov 17, 2008 at 7:27 PM, Richard S. Hall <[EMAIL PROTECTED]>wrote:

I think the logic is correct. You cannot dynamically attach a fragment to
an already resolved host. Thus, the potential hosts for the fragment are
only those that are not yet resolved.

Are you resolving the host first before installing the fragment?

-> richard

Walid "jo" Gedeon wrote:

Hello all,

I was struggling to get a fragment installed for log4j configuration,
setup as a fragment with host=org.apache.log4j.
However, I would keep getting the error:

org.osgi.framework.BundleException: Unresolved constraint in bundle 21:
host; (bundle-symbolic-name=org.apache.log4j)

(bundle 21 is my log4jconfig-fragment), and the log4j bundle (7) seems
correctly installed:

-> headers 7

Apache Jakarta log4j Plug-in (7)
--------------------------------
Bundle-ClassPath = .
Bundle-RequiredExecutionEnvironment = J2SE-1.4
Export-Package =
org.apache.log4j,org.apache.log4j.chainsaw,org.apache.log4j.config,org.apache.log4j.helpers,org.apache.log4j.jdbc,org.apache.log4j.jmx,org.apac

he.log4j.lf5,org.apache.log4j.lf5.config,org.apache.log4j.lf5.util,org.apache.log4j.lf5.viewer,org.apache.log4j.lf5.viewer.categoryexplorer,org.apache.log4j.lf5
.viewer.configure,org.apache.log4j.lf5.viewer.images,org.apache.log4j.net<
http://org.apache.log4j.net
,org.apache.log4j.nt,org.apache.log4j.or,org.apache.log4j.or.jms,
org.apache.log4j.or.sa <http://org.apache.log4j.or.sa>

x,org.apache.log4j.spi,org.apache.log4j.varia,org.apache.log4j.xml
Bundle-Version = 1.2.13.v200806030600
Manifest-Version = 1.0
Bundle-Vendor = Eclipse.org
Bundle-ManifestVersion = 2
Eclipse-BuddyPolicy = registered
Bundle-Name = Apache Jakarta log4j Plug-in
Bundle-Localization = plugin
Bundle-SymbolicName = org.apache.log4j

In all case, stepping through the code (in
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore), it looks like
the boolean checks have been reversed?

private List getPotentialHosts(IModule fragment)
{ // ...
       IModule[] modules = m_factory.getModules();
       for (int modIdx = 0; (hostReq != null) && (modIdx <
modules.length); modIdx++)
       {
           if (!fragment.equals(modules[modIdx]) &&
!isResolved(modules[modIdx])) { ...
I'm thinking this should be            if
(!fragment.equals(modules[modIdx]) && isResolved(modules[modIdx])) {
the host bundle is resolved and it's not the same as the fragment bundle,
and can be selected as a potential host:
               ICapability[] caps =
modules[modIdx].getDefinition().getCapabilities();
               for (int capIdx = 0; (caps != null) && (capIdx <
caps.length); capIdx++)
               {
                   if
(caps[capIdx].getNamespace().equals(ICapability.HOST_NAMESPACE)
                       && hostReq.isSatisfied(caps[capIdx])
                       && !modules[modIdx].isStale())
                   {
                       hostList.add(modules[modIdx]);
                       break;
                   }
               }

I've attached a patch for that change... Do you guys agree? or did I
misunderstand some part of the logic?
I can raise a defect and attach the patch if no one disagrees.

Cheers,
w


Reply via email to