Long thread, my summary:
1. Adding OSGI manifests to tomcat jars: there is interest, it will provide
benefits for people using tomcat in an OSGI environment. I don't think there
is any major controversy - it'll not affect any existing functionality. If
Henri or someone familiar with OSGi and inter
> I just don't have the time. If you keep your responses to a few short
paragraphs, you might get more input
Filip, hey. May I ask when you think the HttpOnly patch will go live?
And Mark, I've spammed you about this as well - I'm running my own
custom branch eager to back back inline with the
Peter Kriens wrote:
I must admit I feel I am walking on eggs ... and I am a bit surprised
how few others tune in.
there is a reason few others turn in, at this point, you have written,
and very well so, about 30 pages of responses.
It's just to hard keep up with long essays like that, not t
Regarding 'dynamic register/unregister' - the servlet API defines
one way to
do this, i.e. war and the deployment. There is no standard API to
install/uninstall/start/stop a .war
- but HttpService is not that either. Runtime config changes
( adding/removing servlets
without web.xml changes an
On Apr 30, 2008, at 10:28 AM, Costin Manolache wrote:
On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens <[EMAIL PROTECTED]>
wrote:
Regarding HttpService - I don't think it's a good idea for tomcat.
One of the major problems with OSGI ( and we need to make sure we
don't
fall
in this trap ) is t
On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens <[EMAIL PROTECTED]>
wrote:
> Regarding HttpService - I don't think it's a good idea for tomcat.
> > One of the major problems with OSGI ( and we need to make sure we don't
> > fall
> > in this trap ) is the re-invention of common APIs - logging, servle
On Tue, Apr 22, 2008 at 11:45 AM, Henri Gomez <[EMAIL PROTECTED]> wrote:
> Hi to all,
>
> Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
Quotes from http://www.infoq.com/news/2008/04/springsource-app-platform
"...the SpringSource Application Platform, an application server
Regarding HttpService - I don't think it's a good idea for tomcat.
One of the major problems with OSGI ( and we need to make sure we
don't fall
in this trap ) is the re-invention of common APIs - logging, servlet
interfaces, etc.
As a bit of background. The logging and Http Service API are fro
Well, IMHO the servlet spec is going from bad to worse in terms of
complexity and feature bloat, so
careful what you wish :-)
My point was mostly that we don't have to implement OSGI HttpService, it may
be ok to use them for
modularization but for servlet-specific APIs we should stick with the JSR
> You should try to read the article I think :) This is about a specific
> issue, where there's no actual disagreement (basically it is a publicity
> stunt).
I read it carefully Remy, don't worry.
There is open discussion on Servlet 3.0 and may be the opportunity to
discuss more than just disc
On Tue, 2008-04-29 at 22:12 +0200, Henri Gomez wrote:
> Read on serverside that JSR-315 needs ideas for servlet 3.0 specs.
You should try to read the article I think :) This is about a specific
issue, where there's no actual disagreement (basically it is a publicity
stunt).
Rémy
--
Read on serverside that JSR-315 needs ideas for servlet 3.0 specs.
http://www.theserverside.com/news/thread.tss?thread_id=49212
May be a good opportunity to send various requests about dynamic
reload purposes (with or without OSGI) to the JCR.
Regards
--
On Mon, Apr 28, 2008 at 11:25 PM, Peter Kriens <[EMAIL PROTECTED]>
wrote:
> Tomcat to really make a lot of sense. Providing OSGi headers seems to
> fulfill
> the immediate need of several groups. However, it would be really nice if
> you
> could provide a service interface like an Http Service (
Please, I think the audience is pretty much "mature" developpers
here :-)
I know, that is why it is scary and sounds complex because experienced
developers
know much better what can go wrong. Novices have much fewer qualms. :-)
Anyway, the dynamism is not Eclipse's strongest feature, but the
On Mon, Apr 28, 2008 at 12:52 PM, pkriens wrote:
> > To me, a webapp adds "entries" (aka Servlet) to menus (aka url patterns)
> > from a static file inside the war (web.xml). If it was not possible in 4
> > years to solve this problem in Eclipse, how will it be possible for
> > Tomcat?
> More and m
> To me, a webapp adds "entries" (aka Servlet) to menus (aka url patterns)
> from a static file inside the war (web.xml). If it was not possible in 4
> years to solve this problem in Eclipse, how will it be possible for
> Tomcat?
More and more code is supporting the dynamic life cycle model beca
pkriens wrote:
Just my 2c: Eclipse, OSGified since 3.2, still doesn't fully support
updates without a JVM restart; and they have full control about the
whole aspects.
Unfortunately there are tens of thousands of plugin writers out there that
are not aware of the dynamics. Eclipse migrated to OS
> Someone recently pointed out to me that the Bnd tool comes with ant
> tasks. I haven't tried that (we've used maven in commons) and I
> suspect that there isn't the option to just produce the manifest
> (rather than jar and manifest) as there is in the maven plugin. If
> that was required then i
> my feeling is though, is that you are going for the "mavenization" just
> to run the BND or BNE or whatever the plugin is called, that generates
> the OSGi manifests.
The project is called bnd (pronounce b and d). The jar can be used as an ant
task, command utility, eclipse plugin, and library
> I think the first main problem with these frameworks is how intrusive
> they are, esp compared with whet they provide :( I suppose there's no
> problem with doing a tomcat-osgi in the sandbox if people want to. As I
> said I really don't care.
We tried awfully hard to be not intrusive :-(
Actua
> Just my 2c: Eclipse, OSGified since 3.2, still doesn't fully support
> updates without a JVM restart; and they have full control about the
> whole aspects.
Unfortunately there are tens of thousands of plugin writers out there that
are not aware of the dynamics. Eclipse migrated to OSGi 4 years
The way the dynamics work in OSGi is only partly classloading. In the HTTP
examples, we have defined an HttpService where you register a servlet. When
a bundle (OSGi JAR) is started, it registers a servlet with the http
service. When it is stopped, the Http Service detects this and removes the
map
> I've heard various claims of this nature from osgi zealots, but when
> talking to apparent experts the only things resembling this they
> seemed to know about were grad student experiments that did not have
> production use as even a far-in-the-future goal. Do you know of any
> actual e
> But I think the main question is if it's worth it - there is a lot of
> complexity and many things that can go wrong. Very few advanced users
> will be able to use this - in particular if they have production
> environments and some release testing is required ( i.e. it would be
> quite hard
On Fri, Apr 25, 2008 at 12:49 AM, David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Apr 24, 2008, at 11:11 PM, Henri Gomez wrote:
>
>
> >
> > > I've heard various claims of this nature from osgi zealots, but when
> > > talking to apparent experts the only things resembling this they seemed
> to
> > >
David Jencks wrote:
> On Apr 24, 2008, at 11:11 PM, Henri Gomez wrote:
> > We'll see how OSGI works underload with Glassfish v3.
Are they planning to support "gapless" redeployment of web apps using
only osgi features, with no other servlet container support? If so is
can you point to an explan
> Since this requires state mutation (see the hooks that an Erlang OTP
> application will supply for state upgrade, for instance) there won't be
> a "no other hooks" version, I think :-)
>
> This is doable (I've done it, but only as a proof of concept - as
> pointed out, this is a long way awa
On Fri, 25 Apr 2008, David Jencks wrote:
> Are they planning to support "gapless" redeployment of web apps using only
> osgi features, with no other servlet container support? If so is can you
> point to an explanation of how they plan to do this?
Since this requires state mutation (see the hook
On Apr 24, 2008, at 11:11 PM, Henri Gomez wrote:
I've heard various claims of this nature from osgi zealots, but when
talking to apparent experts the only things resembling this they
seemed to
know about were grad student experiments that did not have
production use as
even a far-in-the-fut
> I've heard various claims of this nature from osgi zealots, but when
> talking to apparent experts the only things resembling this they seemed to
> know about were grad student experiments that did not have production use as
> even a far-in-the-future goal. Do you know of any actual examples of
> OSGI is good of having 2 versions of a bundle running at the same time
> - but it won't help you much, the servlet
> engine needs to know where to send the requests, it has no clue a
> request should go to the old version or the new.
May be additions to servlet specs should be planned, ie, b
I'm not an expert, but I think I can tell you that yes, "hello world"
applications can be upgraded without stopping, real
applications can't.
As long as you use sessions or statics or you make config changes -
you have to restart the webapp.
OSGI is good of having 2 versions of a bundle running at
On Apr 22, 2008, at 6:25 PM, Paul Benedict wrote:
Is that enough so that web applications, either as a whole or in
partial,
can be upgraded without stopping them? It's my understanding that if
web
applications are loaded in an OSGi classloader, these kind of things
are
possible.
I've hea
> That's maven's problem - I don't think there is any value in
> continuing this discussion,
> again - if you can support maven by adding a build/maven directory and
> whatever files
> inside - you have my +1, I'm all for making it easy to build - as long
> as the tools are not
> intrusive a
On Wed, Apr 23, 2008 at 1:38 PM, Henri Gomez <[EMAIL PROTECTED]> wrote:
> > And that would be the reason for -1.
> > If a build system requires intrusive changes and forces a particular code
> > organization - it shouldn't be used.
>
> that's maven phylosophy, not so bad.
The layout may be
Niall Pemberton wrote:
On Wed, Apr 23, 2008 at 6:56 PM, Filip Hanik - Dev Lists
<[EMAIL PROTECTED]> wrote:
Henri Gomez wrote:
I'm not sure it's the best idea, my goal is to move it out of sandbox,
it already has enough experiments
that need completion. and the main goal is to be 'li
On Wed, Apr 23, 2008 at 6:56 PM, Filip Hanik - Dev Lists
<[EMAIL PROTECTED]> wrote:
>
> Henri Gomez wrote:
>
> >
> > > I'm not sure it's the best idea, my goal is to move it out of sandbox,
> > > it already has enough experiments
> > > that need completion. and the main goal is to be 'lite' :-).
I grab jackrabbit and apacheds right now from eclipse :
- added their repositories to eclipse
- checkout maven project from SVN
- got the main project and modules in the eclipse workspace
- mvn package and voila it works !
Hard to be simpler :)
Just a note, I'm not a maven evangelist :)
Henri Gomez wrote:
First define 'mavenizing' please :-)
Yes
If you mean exporting tomcat components in maven repository - fine with me.
It's allready done (by hand) ?
If you mean building tomcat with maven instead of ant - the opposite,
absolutely not fine.
it wa
> > it was the idea.
>
> Sorry, -1 from me ( again ).
Sic...
> And that would be the reason for -1.
> If a build system requires intrusive changes and forces a particular code
> organization - it shouldn't be used.
that's maven phylosophy, not so bad.
> It is a choice each project can ma
On Wed, Apr 23, 2008 at 1:17 PM, Henri Gomez <[EMAIL PROTECTED]> wrote:
> > First define 'mavenizing' please :-)
>
> Yes
>
>
> > If you mean exporting tomcat components in maven repository - fine with
> me.
>
> It's allready done (by hand) ?
>
>
> > If you mean building tomcat with maven ins
> First define 'mavenizing' please :-)
Yes
> If you mean exporting tomcat components in maven repository - fine with me.
It's allready done (by hand) ?
> If you mean building tomcat with maven instead of ant - the opposite,
> absolutely not fine.
it was the idea.
> Maintaining a separate
First define 'mavenizing' please :-)
If you mean exporting tomcat components in maven repository - fine with me.
If you mean building tomcat with maven instead of ant - the opposite,
absolutely not fine.
Maintaining a separate maven build file - unofficial, i.e. the default
build instructions sti
hi Henri,
Henri Gomez wrote:
So nobody object for some experimentation around mavenizing Tomcat 6 ?
no one can object what you do on your own time. It's your given right.
However, if you look at the previous discussions around the Maven topic,
you will see it is highly unlikely that the Tom
So nobody object for some experimentation around mavenizing Tomcat 6 ?
Of course no commit just testing on my own eclipse/m2 workspace.
>2008/4/23 Filip Hanik - Dev Lists <[EMAIL PROTECTED]>:
>
> Henri Gomez wrote:
>
> >
> > > I'm not sure it's the best idea, my goal is to move it out of sandbox
Henri Gomez wrote:
I'm not sure it's the best idea, my goal is to move it out of sandbox,
it already has enough experiments
that need completion. and the main goal is to be 'lite' :-). It has a
simple Addon mechanism, and I don't mind
having an optional addon manager impl using OSGI - but I
- Original Message -
From: "Henri Gomez" <[EMAIL PROTECTED]>
To: "Tomcat Developers List"
Sent: Wednesday, April 23, 2008 2:24 PM
Subject: Re: Osgifing Tomcat
Yes, the modular aspect is for sure a better choice. So we can have a
smaller Tomcat (by
Henri Gomez wrote:
Indeed
I'll try to spend some time on mavenize tomcatlight first and how it
could be done then for tomcat trunk.
Next how to OSGIfy the mavenized tomcats, experiences and advices welcomed here
Once Tomcat has been mavenized, with maven-bundle-plugin you can produce
bundl
> I'm not sure it's the best idea, my goal is to move it out of sandbox,
> it already has enough experiments
> that need completion. and the main goal is to be 'lite' :-). It has a
> simple Addon mechanism, and I don't mind
> having an optional addon manager impl using OSGI - but I don't want
On Wed, Apr 23, 2008 at 8:36 AM, Henri Gomez <[EMAIL PROTECTED]> wrote:
>
> Silly question, but did experiments with OSGI could be done, first, in
> tomcatlight ?
>
I'm not sure it's the best idea, my goal is to move it out of sandbox,
it already has enough experiments
that need completion. and
> Well, adding OSGI-compatible manifests to the existing jars is not
> that intrusive,
> and could be easily done in the trunk. AFAIK an Activator is not required -
> i.e.
> if you don't need the BundleContext or to add services, you can have a bundle
> that just imports/exports packages.
>
>
Well, adding OSGI-compatible manifests to the existing jars is not
that intrusive,
and could be easily done in the trunk. AFAIK an Activator is not required - i.e.
if you don't need the BundleContext or to add services, you can have a bundle
that just imports/exports packages.
I agree with Remy th
On Wed, 2008-04-23 at 16:00 +0200, Florent.BENOIT wrote:
> Also, for OSGi, as all is done by package (import/export) the first step
> is to be sure that API and Implementation are never in the same package
> name. So we can export APIs and keep private the implementation.
I think the first main
> I'm actually working in sandbox, and I plan to propose stuff for the
> trunk - and thus become active ( I'm very slow those days - I don't have a
> lot of free time ).
Ditto.
I don't have a lot of free time, but I willing to take on my spare
time for OSGIfying Tomcat.
More all contributio
> I share your concern about OSGI and hype :-)
As a regular Eclipse user, I like OSGI, but from the plugin altitude.
> I spent few years working on a project using OSGI heavily, with people
> buying the hype. It was a big disaster, most time was spent
> reinventing the wheels and turning perf
Remy - please consider the Apache guidelines about being respectful on the
public lists.
Key word: please.
- Jim
-Original Message-
From: Remy Maucherat <[EMAIL PROTECTED]>
Sent: Wednesday, April 23, 2008 7:35 AM
To: Tomcat Developers List
Subject: Re: Osgifing Tomcat
On Tue, 2
Yes, that looks great.
Also, for OSGi, as all is done by package (import/export) the first step
is to be sure that API and Implementation are never in the same package
name. So we can export APIs and keep private the implementation.
Florent
Henri Gomez wrote:
Yes, the modular aspect
> I don't know if you noticed, but I have not really been participating in
> Tomcat's trunk development for months, and am only dealing with Tomcat
> 6.0. In trunk or any other future developments, at the moment my plan is
> only to comment (pretty much like Costin does).
I'm actually working
On Wed, Apr 23, 2008 at 4:35 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote:
> > Hi to all,
> >
> > Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
>
> The only thing which ever attracts you is pointless hype, it's quit
On Wed, 2008-04-23 at 14:23 +0200, Henri Gomez wrote:
> > The only thing which ever attracts you is pointless hype, it's quite
> > funny ;)
>
> Remy, I, and many others, will be happy, at least one time, see you
> discuss technicals and usage aspects of a Tomcat evolution.
>
> * What's the pros
>Yes, the modular aspect is for sure a better choice. So we can have a
> smaller Tomcat (by only using few bundles) or bundles loaded on demand.
+1
And select which part of the engine to be used.
What make HTTPD server so successfull was its modular approach and openess.
---
> The only thing which ever attracts you is pointless hype, it's quite
> funny ;)
Remy, I, and many others, will be happy, at least one time, see you
discuss technicals and usage aspects of a Tomcat evolution.
* What's the pros and cons ?
* Interest, usage, openess
OSGI is not buzz, it's rea
On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote:
> Hi to all,
>
> Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
The only thing which ever attracts you is pointless hype, it's quite
funny ;)
Rémy
-
Yes, the modular aspect is for sure a better choice. So we can have
a smaller Tomcat (by only using few bundles) or bundles loaded on demand.
Regards,
Florent
Filip Hanik - Dev Lists wrote:
Henri Gomez wrote:
2008/4/23 Florent.BENOIT <[EMAIL PROTECTED]>:
Hello,
As part of OW2 JOn
Henri Gomez wrote:
2008/4/23 Florent.BENOIT <[EMAIL PROTECTED]>:
Hello,
As part of OW2 JOnAS 5.0 OSGi based application server we're interested to
have Tomcat packaged as an OSGi bundle.
All our modules are bundles and if tomcat is already a bundle we won't have
to wrap it into a bundle
Our bundle of Tomcat is exposing JOnAS service API. I think that from a
tomcat bundle view it should expose its own interface like API for
registering/deploying a war component, etc.
If you want to see some source code, it's in the SVN.
http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/jonas
2008/4/23 Florent.BENOIT <[EMAIL PROTECTED]>:
>Hello,
>
> As part of OW2 JOnAS 5.0 OSGi based application server we're interested to
> have Tomcat packaged as an OSGi bundle.
> All our modules are bundles and if tomcat is already a bundle we won't have
> to wrap it into a bundle on our side.
> I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt
> my original plan was just to make sure all the MANIFEST.MF for each file
> would have enough in it so that each JAR can be a OSGi bundle.
Well it shouldn't hurt updating MANIFEST.MF. Could you update some so
we could take a
Hello,
As part of OW2 JOnAS 5.0 OSGi based application server we're interested
to have Tomcat packaged as an OSGi bundle.
All our modules are bundles and if tomcat is already a bundle we won't
have to wrap it into a bundle on our side.
Regards,
Florent
Henri Gomez wrote:
Hi to all,
Did
Is that enough so that web applications, either as a whole or in partial,
can be upgraded without stopping them? It's my understanding that if web
applications are loaded in an OSGi classloader, these kind of things are
possible.
Paul
On Tue, Apr 22, 2008 at 7:24 PM, Filip Hanik - Dev Lists <[EMA
Henri Gomez wrote:
Hi to all,
Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt
my original plan was just to make sure all the MANIFEST.MF for each file
would have enough in it so that each JAR can be a
2008/4/22, Costin Manolache <[EMAIL PROTECTED]>:
> I think OSGI has some good ideas - it is pretty good at handling class
> loaders and loading/unloading modules. On the other side, they are
> very 'framework' - and like all other frameworks you have to do all
> things their way and they re-inv
I think OSGI has some good ideas - it is pretty good at handling class
loaders and loading/unloading modules. On the other side, they are
very 'framework' - and like all other frameworks you have to do all
things their way and they re-invent a lot of wheels ( from logging
APIs to almost everything
73 matches
Mail list logo
