I am traveling right now, but I will take a look at it when I am home. I think
we can do something, even if it is a temporary hack. This is precisely the type
of feedback I need, thanks.
-> richard
-----Original Message-----
From: "Felix Meschberger" <[EMAIL PROTECTED]>
Subj: Re: Framework changes
Date: Tue 23. Jan 2007 8:41
Size: 2K
To: felix-dev@incubator.apache.org
HI Richard,
I updated my local framework copy from SVN today and noticed, that
performance degraded remarkably for bundles using DynamicImport-Package.
After looking around a while, I saw, that
R4SearchPolicyCore.attemptDynamicImport looks after dynamic Requirements and
builds a filter from the requirement filter and the requested package. This
filter is then used to scan all bundles ... Using this over and over is very
expensive.
I wonder, whether this small (somewhat hacky) fix is legal [ at least it
does seem to work for me, yet I am not sure, whether this is acceptable)
--------------------------------
Index:
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
===================================================================
---
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
(revision 499005)
+++
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
(working copy)
@@ -510,6 +510,17 @@
// is necessary because we cannot easily determine which
// package name a given dynamic requirement matches, since
// it is only a filter.
+
+ // do not consider dynamic packags not matching the
requested
+ if ( ICapability.PACKAGE_NAMESPACE.equals(
dynamics[i].getNamespace() ) )
+ {
+ String dynPack = ( ( Requirement ) dynamics[i]
).getPackageName();
+ if ( !pkgName.equals( dynPack ) && !( pkgName + ".*"
).equals( dynPack ) )
+ {
+ continue;
+ }
+ }
+
IRequirement req = null;
try
{
-------------------------------
What do you think ?
Regards and Thanks
Felix
PS: Yes I know, that this is work in progress :-)
On 1/22/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>
> Steven E. Harris wrote:
> > "Richard S. Hall" <[EMAIL PROTECTED]> writes:
> >
> >
> >> In short, the module loader abstraction previously worked in terms
> >> of exports/imports, but now it has been generalized to work in terms
> >> of capabilities/requirements. A capability is simply a set of
> >> properties, while a requirement is a filter over a set of
> >> properties.
> >>
> >
> > Does this mean that some of the capabilities and requirements types
> > from the OBR bundle will be moved (or copied) into Felix proper?
> >
>
> Essentially, yes. I have had to make some modifications to their
> implementation for the time being, but I hope to continue to work on
> them to make them more generic like the original OBR types.
>
> -> richard
>
--- message truncated ---
