Re: [DISCUSS] Containerisms

Mon, 11 Oct 2010 07:50:58 -0700 

 On 10/11/10 10:36, Guillaume Nodet wrote:

On Mon, Oct 11, 2010 at 16:25, Richard S. Hall<[email protected]>  wrote:


  On 10/11/10 10:05, Guillaume Nodet wrote:


On Mon, Oct 11, 2010 at 15:38, Richard S. Hall<[email protected]>
  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.
Well, for now it has been put on the back burner, if not permanently shelved. There might still be some good ideas in there, but I'm not sure what to do with it anymore. I think there are some issues that would need to be improved for it to really be what we need. Specifically, I think we need to think of some way to allow there to be multiple managers per bundle...if that even makes sense. 


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 would have likely released it if I knew for sure it was "the" direction to go. At this point, I'm not sure, although I really do like aspects of it. I was toying with the idea of making the behavior of a bundle implemented as a vb manager, so the core would be more of a generic module system...largely just the resolver. Would be kind of cool, but as I said above, there are other issues that would be more important to resolve. 


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.
I would tend to agree if it weren't for the fact that a) we are never allowed to get rid of the hacks and b) people continue to create dependencies on the hacks because they're familiar with it. 

-> richard




  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<[email protected]>


  wrote:

   On 10/8/10 14:08, Guillaume Nodet wrote:


  On Fri, Oct 8, 2010 at 18:43, Felix Meschberger<[email protected]>


  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,<[email protected]>     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

Reply via email to