felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [DISCUSS] Containerisms
Date Mon, 11 Oct 2010 14:36:38 GMT
On Mon, Oct 11, 2010 at 16:25, Richard S. Hall <heavy@ungoverned.org> wrote:

>  On 10/11/10 10:05, Guillaume Nodet wrote:
>
>> On Mon, Oct 11, 2010 at 15:38, Richard S. Hall<heavy@ungoverned.org>
>>  wrote:
>>
>>   On 10/11/10 3:32, Guillaume Nodet wrote:
>>>
>>>  What I don't get is why we don't get rid of the existing containerims in
>>>> Felix:
>>>>   * the reference: and inputstream: url protocol for installing bundles
>>>>
>>>>  There is no inputstream: URL for installing bundles. The reference: URL
>>> is
>>> there largely because Equinox has it and it was created specifically to
>>> match their containerism.
>>>
>>>  Right, the inputstream stuff seems like an internal way to pass a
>> parameter.
>>  I may be wrong, but I guess it could be removed alltogether by simply
>> checking if the input stream parameter is null  in
>> BundleArchive#createRevisionFromLocation ...
>>
>
> Yeah, possibly. I'd have to look at it.
>
>
>     * the pluggable cache
>>> We could. I'm not aware of anyone using it. But in reality, I'd like to
>>> find a completely different way to handle the cache. Making it pluggable
>>> is
>>> only good design, since it allows us to change our own implementation
>>> too.
>>>
>>>
>>     * implicit boot delegation
>>> This isn't really a containerism as much as it is trying to faithfully
>>> implement the spec. It tries to workaround stupid assumptions in the JRE.
>>>
>>
>> Out of curiosity, why can it be disabled then if the purpose is to be
>> close
>> to the spec?
>>
>
> We added the ability to disable it not that long ago, but we affectionately
> refer to as the "magic hack" has existed for many years. We allow you to
> disable it because it is a best effort to approximate the spec, but it is
> not 100% correct, therefore you can disable it if it is causing you some
> difficulty. However, we've tried to constantly evolve it over time to
> incorporate more failing use cases as we uncover them. So, I'd expect the
> need to disable it continues to shrink.
>
>
>
>>>  I suppose there are some more hidden throughout the code.
>>> Probably, but given this list, it looks like we're doing a pretty good
>>> job.
>>>
>>> As I said in another message, we look at everything on a case-by-case
>>> basis. There is no blanket answer, but typically things that break
>>> abstractions or encapsulation will be frowned upon.
>>>
>>> Certainly there are places were we have container-specific behavior, but
>>> it
>>> is often due to leeway in the spec. In other cases, I can almost assure
>>> you
>>> that I discuss them with Tom Watson to make sure we can align such areas
>>> if
>>> possible.
>>>
>>>  Yeah, I can see the purpose of trying to not introduce containerism, but
>> can't at the same time oppose to any change in the spec and oppose to any
>> containerism.   Users have some needs and there must be a way for Felix to
>> fullfill those.
>>
>> What I don't get is why can't Felix Framework be a source of innovation
>> for
>> solving real problems in OSGi, like AOP or such.   You can't certainly
>> believe the OSGi spec is perfect and that all use cases have been
>> addressed,
>> else it would not evolve anymore.  Having to wait 2 years for the OSGi
>> alliance for publish an update to the spec, then 6 months for Felix to
>> implement and release it  isn't really a good solution for Felix users.
>>
>
> Again, we are willing to look at anything. Where do you think the standard
> launching and embedding API came from in R4.2? You should've seen the
> Virtual Bundle stuff I was cooking up before it was shelved. If you have a
> proposal for some great way to do AOP in a modular way, I'd definitely like
> to hear it. (Especially given the not so great byte code weaving RFC.)
>

I'm aware of the virtual bundles thing you've done.  I just find given it's
in a private unreleased branch and only a handful of people are aware of it,
it's hard to gather real use feedback on that, but i'm actually planning to
have a look at those in the coming weeks and implement a vb manager.

I guess i'm more an agile kind of developer, and i tend to prefer releasing
something even if not fully functional to gather feedback, even if this
means having to refactor things later.  Those kind of features are really
those that the average osgi users won't use (at least directly), so i don't
necessarily feel bound to an api forever.   For virtual bundles, the use
case is real, so even if people have to rewrite things a bit when they
upgrade from felix 3.1 to 3.2, having such a feature in trunk would seem to
me a really nice thing.


>
> I assume you are not equating getting real URLs with innovation, because to
> me it is just a hack even if/when it becomes standardized.
>
>
That's very true and I agree to call that a hack.  Our disagreement comes
from that fact that I think hacks can be enablers and are not necessarily
evils.


>
>  My original problem isn't really solved by the jarurl dir (if implemented
>> as
>> drafted, meaning that Bundle#getResource.
>> I've been pointed to the Wiring#listResources() in the 4.3 draft which is
>> closer to my needs actually, but that looks like a much bigger work.
>>
>
> Yeah, tell me about it. I'm not looking forward to it. Originally, that was
> planned to be outside the framework, which I thought was a great idea. ;-)
>
> -> richard
>
>
>
>>
>>
>>
>>  ->  richard
>>>
>>>
>>>  On Fri, Oct 8, 2010 at 20:17, Richard S. Hall<heavy@ungoverned.org>
>>>
>>>>  wrote:
>>>>
>>>>   On 10/8/10 14:08, Guillaume Nodet wrote:
>>>>
>>>>>  On Fri, Oct 8, 2010 at 18:43, Felix Meschberger<fmeschbe@gmail.com>
>>>>>
>>>>>>  wrote:
>>>>>>
>>>>>>  Hi,
>>>>>>
>>>>>>  First of all: I agree with Richard in that we should at all cost
>>>>>>> prevent
>>>>>>> containerisms.
>>>>>>>
>>>>>>> Second: I do not really understand what the problem is, that
must be
>>>>>>> solved with this containerism and which cannot be solved with
regular
>>>>>>> OSGi API.
>>>>>>>
>>>>>>>  The real problem is to be able to discover resources in the
bundle
>>>>>>> class
>>>>>>>
>>>>>>>  space. For example, i want to know all resources in foo/bar/**/*.xml
>>>>>> The
>>>>>> OSGi API does not provide any way to do that atm and a lot of
>>>>>> libraries
>>>>>> use
>>>>>>  some custom things based on jars / file urls to actually iterate
and
>>>>>> discover those resources.
>>>>>>
>>>>>> The problem is just about a way to actually do things.  It seems
in
>>>>>> the
>>>>>> enterprise world (JEE, middleware),  we're more keen on bending the
>>>>>> purity
>>>>>> a
>>>>>> bit to the benfit of being able to achieve our goals and we're also
>>>>>> more
>>>>>> keen on doing that for third party libraries.
>>>>>>
>>>>>> It's true that if you write the whole osgi application from scratch,
>>>>>> you
>>>>>> don't really care about supporting third party libraries.
>>>>>>  Unfortunately,
>>>>>> people just won't rewrite a third party product they already use
just
>>>>>> because they want to play nicely in OSGi.  That's my use case, and
it
>>>>>> seems
>>>>>> it doesn't fit well with Felix goals, so I guess i'll have to support
>>>>>> a
>>>>>> custom felix version in order to do that or only support equinox.
>>>>>>
>>>>>> I think I'll revert my commit as if the plan is to ditch it in the
>>>>>> next
>>>>>> felix version, there's really no point in even using such a hack
from
>>>>>> my
>>>>>> pov.
>>>>>>
>>>>>>  Which is precisely the point from my perspective. Not only do you
>>>>>> want
>>>>>>
>>>>> the
>>>>> hack, but you want it maintained forever. That's precisely what I think
>>>>> we
>>>>> should avoid.
>>>>>
>>>>> If you are keen on having your own custom version of Felix, we can
>>>>> always
>>>>> start a new subproject so you can work on one that you think is better.
>>>>> It
>>>>> doesn't bother me to have two framework impls...as I've said many
>>>>> times,
>>>>> the
>>>>> framework is just a subproject like any other. Just create a fork and
>>>>> call
>>>>> it something completely different so there is no confusion.
>>>>>
>>>>> ->   richard
>>>>>
>>>>>
>>>>>
>>>>>   Third: For us outsiders of the specification process it is very hard
>>>>> to
>>>>>
>>>>>> understand what insiders are talking of with respect to upcoming
>>>>>>> specifications (I only learned 5 minutes ago, that there is a
public
>>>>>>> draft for 4.3). This issue must probably be solved by OSGi...
>>>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>> On 08.10.2010 16:37, Guillaume Nodet wrote:
>>>>>>>
>>>>>>>  I was planning to start a discussion around that, so let's do
that
>>>>>>>
>>>>>>>> now.
>>>>>>>>
>>>>>>>> I'm not convinced we should remove this hack when classpath
scanning
>>>>>>>> is
>>>>>>>> implemented, mostly because even if then ultimately try to
solve the
>>>>>>>> same
>>>>>>>> problem, they will certainly do it in a different way.  What
I mean
>>>>>>>> is
>>>>>>>>
>>>>>>>>  that
>>>>>>>>
>>>>>>>  AFAIK, the classpath scanning stuff will result in a new api
on the
>>>>>>>
>>>>>>>>  bundle
>>>>>>>>
>>>>>>>  or bundleContext to iterate through resources, which means that
in
>>>>>>>
>>>>>>>> order
>>>>>>>>
>>>>>>>>  to
>>>>>>>>
>>>>>>>  support existing libraries, you kinda have to rewrite the whole
>>>>>>> thing
>>>>>>>
>>>>>>>> in
>>>>>>>> order to accomodate those apis (especially if they are written
so
>>>>>>>> that
>>>>>>>>
>>>>>>>>  they
>>>>>>>>
>>>>>>>  work outside of osgi).
>>>>>>>
>>>>>>>> I think the hack i've written allows a smoother integration
of those
>>>>>>>> libraries, with the drawback that you know it can break in
certain
>>>>>>>> conditions.
>>>>>>>>
>>>>>>>> Also, your comment says "Do not make containerisms public."
>>>>>>>> In that case, it's not really public because the public face
of the
>>>>>>>> Felix
>>>>>>>> Framework is the OSGi api.
>>>>>>>> I guess the question comes down to wether we want Felix to
remain
>>>>>>>> pure
>>>>>>>> (without containerisms) or make it easier for people to use
it (by
>>>>>>>>
>>>>>>>>  bending
>>>>>>>>
>>>>>>>  the edges when it makes sense to allow people to deploy their
>>>>>>> existing
>>>>>>>
>>>>>>>> libraries without rewriting the whole thing).
>>>>>>>> Imho, Felix is not a research prototype, nor supposed to
be the
>>>>>>>> cleaneest
>>>>>>>> reference implementation of OSGi, so adapting to the users
makes
>>>>>>>> sense
>>>>>>>>
>>>>>>>>  imho,
>>>>>>>>
>>>>>>>  provided that it's done conciensouly by the user by activating
a
>>>>>>> flag
>>>>>>>
>>>>>>>> or
>>>>>>>> accessing a non public api (we fall in that case here imho).
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> On Fri, Oct 8, 2010 at 16:22,<rickhall@apache.org>
   wrote:
>>>>>>>>
>>>>>>>>  Author: rickhall
>>>>>>>>
>>>>>>>>  Date: Fri Oct  8 14:22:39 2010
>>>>>>>>> New Revision: 1005843
>>>>>>>>>
>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=1005843&view=rev
>>>>>>>>> Log:
>>>>>>>>> Do not make containerisms public. (FELIX-2645)
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  felix/trunk/framework/src/main/java/org/apache/felix/framework/ExtensionManager.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  felix/trunk/framework/src/main/java/org/apache/felix/framework/ModuleImpl.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  felix/trunk/framework/src/main/java/org/apache/felix/framework/URLHandlersBundleURLConnection.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/ContentDirectoryContent.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/DirectoryContent.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/JarContent.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  felix/trunk/framework/src/main/java/org/apache/felix/framework/resolver/Content.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  felix/trunk/framework/src/main/java/org/apache/felix/framework/resolver/Module.java
>>>>>>>>>
>>>>>>>>>  Modified:
>>>>>>>>
>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/ExtensionManager.java
>>>>>>>>>
>>>>>>>>>  URL:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/ExtensionManager.java?rev=1005843&r1=1005842&r2=1005843&view=diff
>>>>>>>
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/ExtensionManager.java
>>>>>>>>>
>>>>>>>>>  (original)
>>>>>>>>
>>>>>>>>  +++
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/ExtensionManager.java
>>>>>>>>>
>>>>>>>>>  Fri Oct  8 14:22:39 2010
>>>>>>>>
>>>>>>>>  @@ -610,6 +610,7 @@ class ExtensionManager extends URLStream
>>>>>>>>>         return null;
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>> +    // TODO: REMOVE - Remove when class path scanning
is
>>>>>>>>> implemented.
>>>>>>>>>     public URL getEntryAsURL(String name)
>>>>>>>>>     {
>>>>>>>>>         return null;
>>>>>>>>> @@ -763,6 +764,7 @@ class ExtensionManager extends URLStream
>>>>>>>>>             return
>>>>>>>>> getClass().getClassLoader().getResourceAsStream(urlPath);
>>>>>>>>>         }
>>>>>>>>>
>>>>>>>>> +        // TODO: REMOVE - Remove when class path scanning
is
>>>>>>>>>
>>>>>>>>>  implemented.
>>>>>>>>>
>>>>>>>>         public URL getLocalURL(int index, String urlPath)
>>>>>>>>
>>>>>>>>          {
>>>>>>>>>             return
>>>>>>>>> getClass().getClassLoader().getResource(urlPath);
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/ModuleImpl.java
>>>>>>>>>
>>>>>>>>>  URL:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/ModuleImpl.java?rev=1005843&r1=1005842&r2=1005843&view=diff
>>>>>>>
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/ModuleImpl.java
>>>>>>>>>
>>>>>>>>>  (original)
>>>>>>>>
>>>>>>>>  +++
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/ModuleImpl.java
>>>>>>>>>
>>>>>>>>>  Fri Oct  8 14:22:39 2010
>>>>>>>>
>>>>>>>>  @@ -1091,6 +1091,7 @@ public class ModuleImpl implements
Modul
>>>>>>>>>         return getContentPath()[index -
>>>>>>>>> 1].getEntryAsStream(urlPath);
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>> +    // TODO: REMOVE - Remove when class path scanning
is
>>>>>>>>> implemented.
>>>>>>>>>     public URL getLocalURL(int index, String urlPath)
>>>>>>>>>     {
>>>>>>>>>         if (urlPath.startsWith("/"))
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/URLHandlersBundleURLConnection.java
>>>>>>>>>
>>>>>>>>>  URL:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/URLHandlersBundleURLConnection.java?rev=1005843&r1=1005842&r2=1005843&view=diff
>>>>>>>
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/URLHandlersBundleURLConnection.java
>>>>>>>>>
>>>>>>>>>  (original)
>>>>>>>>
>>>>>>>>  +++
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/URLHandlersBundleURLConnection.java
>>>>>>>>>
>>>>>>>>>  Fri Oct  8 14:22:39 2010
>>>>>>>>
>>>>>>>>  @@ -28,7 +28,7 @@ import org.apache.felix.framework.resolv
>>>>>>>>>
>>>>>>>>>  import org.apache.felix.framework.util.Util;
>>>>>>>>>
>>>>>>>>> -public class URLHandlersBundleURLConnection extends
URLConnection
>>>>>>>>> +class URLHandlersBundleURLConnection extends URLConnection
>>>>>>>>>  {
>>>>>>>>>     private Felix m_framework;
>>>>>>>>>     private Module m_targetModule;
>>>>>>>>> @@ -201,7 +201,8 @@ public class URLHandlersBundleURLConnect
>>>>>>>>>      *
>>>>>>>>>      * @return the local URL
>>>>>>>>>      */
>>>>>>>>> -    public URL getLocalURL()
>>>>>>>>> +    // TODO: REMOVE - Remove when class path scanning
is
>>>>>>>>> implemented.
>>>>>>>>> +    URL getLocalURL()
>>>>>>>>>     {
>>>>>>>>>         if ((m_targetModule == null) || (m_classPathIdx<
   0))
>>>>>>>>>         {
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/ContentDirectoryContent.java
>>>>>>>>>
>>>>>>>>>  URL:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/ContentDirectoryContent.java?rev=1005843&r1=1005842&r2=1005843&view=diff
>>>>>>>
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/ContentDirectoryContent.java
>>>>>>>>>
>>>>>>>>>  (original)
>>>>>>>>
>>>>>>>>  +++
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/ContentDirectoryContent.java
>>>>>>>>>
>>>>>>>>>  Fri Oct  8 14:22:39 2010
>>>>>>>>
>>>>>>>>  @@ -82,6 +82,7 @@ public class ContentDirectoryContent imp
>>>>>>>>>         return m_content.getEntryAsStream(m_rootPath
+ name);
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>> +    // TODO: REMOVE - Remove when class path scanning
is
>>>>>>>>> implemented.
>>>>>>>>>     public URL getEntryAsURL(String name)
>>>>>>>>>     {
>>>>>>>>>         return m_content.getEntryAsURL(m_rootPath + name);
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/DirectoryContent.java
>>>>>>>>>
>>>>>>>>>  URL:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/DirectoryContent.java?rev=1005843&r1=1005842&r2=1005843&view=diff
>>>>>>>
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/DirectoryContent.java
>>>>>>>>>
>>>>>>>>>  (original)
>>>>>>>>
>>>>>>>>  +++
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/DirectoryContent.java
>>>>>>>>>
>>>>>>>>>  Fri Oct  8 14:22:39 2010
>>>>>>>>
>>>>>>>>  @@ -133,6 +133,7 @@ public class DirectoryContent implements
>>>>>>>>>         return new FileInputStream(new File(m_dir, name));
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>> +    // TODO: REMOVE - Remove when class path scanning
is
>>>>>>>>> implemented.
>>>>>>>>>     public URL getEntryAsURL(String name)
>>>>>>>>>     {
>>>>>>>>>         if ((name.length()>    0)&&    (name.charAt(0)
== '/'))
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/JarContent.java
>>>>>>>>>
>>>>>>>>>  URL:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/JarContent.java?rev=1005843&r1=1005842&r2=1005843&view=diff
>>>>>>>
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/JarContent.java
>>>>>>>>>
>>>>>>>>>  (original)
>>>>>>>>
>>>>>>>>  +++
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/cache/JarContent.java
>>>>>>>>>
>>>>>>>>>  Fri Oct  8 14:22:39 2010
>>>>>>>>
>>>>>>>>  @@ -192,6 +192,7 @@ public class JarContent implements Conte
>>>>>>>>>         return is;
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>> +    // TODO: REMOVE - Remove when class path scanning
is
>>>>>>>>> implemented.
>>>>>>>>>     public URL getEntryAsURL(String name)
>>>>>>>>>     {
>>>>>>>>>         try
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/resolver/Content.java
>>>>>>>>>
>>>>>>>>>  URL:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/resolver/Content.java?rev=1005843&r1=1005842&r2=1005843&view=diff
>>>>>>>
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/resolver/Content.java
>>>>>>>>>
>>>>>>>>>  (original)
>>>>>>>>
>>>>>>>>  +++
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/resolver/Content.java
>>>>>>>>>
>>>>>>>>>  Fri Oct  8 14:22:39 2010
>>>>>>>>
>>>>>>>>  @@ -120,5 +120,6 @@ public interface Content
>>>>>>>>>      * @return A URL using a standard protocol such as
file, jar
>>>>>>>>>      *           or null if not possible.
>>>>>>>>>      */
>>>>>>>>> +    // TODO: REMOVE - Remove when class path scanning
is
>>>>>>>>> implemented.
>>>>>>>>>     URL getEntryAsURL(String name);
>>>>>>>>>  }
>>>>>>>>> \ No newline at end of file
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/resolver/Module.java
>>>>>>>>>
>>>>>>>>>  URL:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/resolver/Module.java?rev=1005843&r1=1005842&r2=1005843&view=diff
>>>>>>>
>>>>>>>
>>>>>>> ==============================================================================
>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/resolver/Module.java
>>>>>>>>>
>>>>>>>>>  (original)
>>>>>>>>
>>>>>>>>  +++
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> felix/trunk/framework/src/main/java/org/apache/felix/framework/resolver/Module.java
>>>>>>>>>
>>>>>>>>>  Fri Oct  8 14:22:39 2010
>>>>>>>>
>>>>>>>>  @@ -72,5 +72,6 @@ public interface Module
>>>>>>>>>         throws IOException;
>>>>>>>>>     InputStream getInputStream(int index, String urlPath)
>>>>>>>>>         throws IOException;
>>>>>>>>> +    // TODO: REMOVE - Remove when class path scanning
is
>>>>>>>>> implemented.
>>>>>>>>>     URL getLocalURL(int index, String urlPath);
>>>>>>>>>  }
>>>>>>>>> \ No newline at end of file
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message