Good Thanks
2008/5/5 Mark Thomas <[EMAIL PROTECTED]>:
> Costin Manolache wrote:
>
> >
> > > From Rainer's email few days ago:
> > >
> > http://svn.apache.org/repos/asf/tomcat/trunk/
> >
> > I suppose after it's in it may be backported to the stable branches if it
> > works well and people like it.
Costin Manolache wrote:
From Rainer's email few days ago:
http://svn.apache.org/repos/asf/tomcat/trunk/
I suppose after it's in it may be backported to the stable branches if it
works well and people like it.
Exactly.
Mark
---
>From Rainer's email few days ago:
http://svn.apache.org/repos/asf/tomcat/trunk/
I suppose after it's in it may be backported to the stable branches if it
works well and people like it.
Costin
On Mon, May 5, 2008 at 8:26 AM, Henri Gomez <[EMAIL PROTECTED]> wrote:
> > Providing in is just addin
> Providing in is just adding a directory/file or two then trunk is the place
> for it.
Only adding files and directories
> If it requires re-organisation of the source tree (which if I have have
> understood the discussion to date it doesn't) it should probably go in a new
> branch.
No reorga
Henri Gomez wrote:
Question :
Where should be commited (for review), the stuff for mavenization ?
Providing in is just adding a directory/file or two then trunk is the place
for it.
If it requires re-organisation of the source tree (which if I have have
understood the discussion to date it
Question :
Where should be commited (for review), the stuff for mavenization ?
I'll have some time next week to works on
2008/5/1 Rainer Jung <[EMAIL PROTECTED]>:
> Costin Manolache schrieb:
>
>
> > I'm confused - there is a tomcat6/trunk repo - isn't this the trunk ?
> >
>
> trunk:http
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
Costin Manolache schrieb:
I'm confused - there is a tomcat6/trunk repo - isn't this the trunk ?
trunk:http://svn.apache.org/repos/asf/tomcat/trunk/
Tomcat 6.0.x: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
Regards,
Rainer
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
Costin Manolache wrote:
Aren't we in 'comit then review' mode for the trunk ?
Yes.
My understanding was that RTC is in effect for the stable releases, but not
the trunk,
and if there is no controversy ( and so far I think the only major issues
was
'don't touch file structure or break ant' ) -
Costin Manolache wrote:
Sorry, I haven't been paying attention to all the rule changes - if someone
could
post the short version, I'm quite interested - I plan to re-start
contributing few things and it
would be good to know the process.
trunk is CTR - normal veto rules apply
all release branch
any Manolache wrote:
BTW - can someone remove [EMAIL PROTECTED] from tomcat-dev ?
being done now.
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
BTW - can someone remove [EMAIL PROTECTED] from tomcat-dev ?
It's quite annoying, after each mail I get an auto-reply from them... I
don't think I have karma to do it.
Costin
On Wed, Apr 30, 2008 at 6:06 PM, Costin Manolache <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 30, 2008 at 5:32 PM, Filip
On Wed, Apr 30, 2008 at 5:32 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
wrote:
> Costin Manolache wrote:
>
> > Aren't we in 'comit then review' mode for the trunk ?
> >
> > My understanding was that RTC is in effect for the stable releases, but
> > not
> > the trunk,
> > and if there is no co
Costin Manolache wrote:
Aren't we in 'comit then review' mode for the trunk ?
My understanding was that RTC is in effect for the stable releases, but not
the trunk,
and if there is no controversy ( and so far I think the only major issues
was 'don't touch file structure or break ant' ) - he can
Aren't we in 'comit then review' mode for the trunk ?
My understanding was that RTC is in effect for the stable releases, but not
the trunk,
and if there is no controversy ( and so far I think the only major issues
was
'don't touch file structure or break ant' ) - he can just submit.
Sorry, I ha
Costin Manolache wrote:
On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists <
[EMAIL PROTECTED]> wrote:
Costin Manolache wrote:
We already have eclipse files checked in AFAIK - that counts as the
second
build system.
We used to have makefiles too, also in parallel with ant (in
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 11:31 AM, Filip Hanik - Dev Lists <
[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
>
> > We already have eclipse files checked in AFAIK - that counts as the
> > second
> > build system.
> > We used to have makefiles too, also in parallel with ant (in 3.0
> > times).
>
Costin Manolache wrote:
We already have eclipse files checked in AFAIK - that counts as the second
build system.
We used to have makefiles too, also in parallel with ant (in 3.0 times).
The goal IMO is that people who like to type mvn can do it - without any
guarantee that
the result will be id
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
We already have eclipse files checked in AFAIK - that counts as the second
build system.
We used to have makefiles too, also in parallel with ant (in 3.0 times).
The goal IMO is that people who like to type mvn can do it - without any
guarantee that
the result will be identical with the official
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
On Tue, 2008-04-29 at 22:28 -0400, Yoav Shapira wrote:
> On Tue, Apr 29, 2008 at 10:09 PM, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> > The current build scripts are fully tested and work well. Adding
> > additional methods of building or replacing these scripts altogether
> > would only provid
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
Yoav Shapira wrote:
Filip, this is a fairly rare case where I disagree with you ;)
On Tue, Apr 29, 2008 at 7:18 PM, Filip Hanik - Dev Lists
<[EMAIL PROTECTED]> wrote:
simply because it requires changes, I like to think we work according to
It can be done without requiring any changes
> This is just an alternative for those people who want to use a
> slightly easier / user-friendlier build system. We could do worse
> than lowering the barrier to entry for new contributors.
The idea is to :
- keep the current source layout
- keep the build.xml
- add some subdirs with pom.
On Tue, Apr 29, 2008 at 10:09 PM, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> The current build scripts are fully tested and work well. Adding
> additional methods of building or replacing these scripts altogether
> would only provide ways to create and/or release broken binaries.
Again, no one
On Tue, 2008-04-29 at 21:03 -0400, Yoav Shapira wrote:
> But like I said earlier, it's not worth disrupting the current Tomcat
> build or source layout. Only if it can be done without requiring any
> changes, which it can.
I will still vote against any inclusion of Maven usage in TC 6.0, 5.5
and
Filip, this is a fairly rare case where I disagree with you ;)
On Tue, Apr 29, 2008 at 7:18 PM, Filip Hanik - Dev Lists
<[EMAIL PROTECTED]> wrote:
> simply because it requires changes, I like to think we work according to
It can be done without requiring any changes.
> "if it aint broke, don't
Henri Gomez wrote:
-1 for any change to the build in Tomcat 6.0.
Why ?
simply because it requires changes, I like to think we work according to
"if it aint broke, don't fix it", and since the maven build doesn't give
us anything the ANT build already does, then there seems to be litt
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
On Tue, Apr 29, 2008 at 1:44 PM, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-04-29 at 22:09 +0200, Henri Gomez wrote:
> > Just a new thread to discuss about mavenizing Tomcat (OSGI Thread is
> > allready fully loaded and really interesting).
> >
> > Costin told us he didn't want to ch
Hi,
On Tue, Apr 29, 2008 at 4:09 PM, Henri Gomez <[EMAIL PROTECTED]> wrote:
> Costin told us he didn't want to change the current source layout.
I agree with Coston on this. But thankfully Maven is flexible in this
area. You can define any set of source folders.
> - add subdirs (for modules)
> 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
--
> -1 for any change to the build in Tomcat 6.0.
Why ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Tue, 2008-04-29 at 22:09 +0200, Henri Gomez wrote:
> Just a new thread to discuss about mavenizing Tomcat (OSGI Thread is
> allready fully loaded and really interesting).
>
> Costin told us he didn't want to change the current source layout.
>
> Alternative to mavenizing tomcat could be :
>
>
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
--
Just a new thread to discuss about mavenizing Tomcat (OSGI Thread is
allready fully loaded and really interesting).
Costin told us he didn't want to change the current source layout.
Alternative to mavenizing tomcat could be :
- add subdirs (for modules) and pom.xml and hack the source files
fil
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
ien
>
> -----
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Osgifing-Tomcat-tp16830131p16936517.h
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
in most cases, but not in Tomcat, and even in the cases it works,
>> the
>> output it produces into the manifest file is completely useless to the
>> human
>> eye. the amount of stuff it exports and imports is insane, in in most
>> cases
>> irrelevant to the data you actually wanna export/import
uman eye. the amount of stuff it exports and imports is insane, in
> in most cases irrelevant to the data you actually wanna export/import
>
> that's why I posted my combined version of the Export/Import, nice and
> clean, when/if we do it on a per jar basis, I would hope we aim to
the sandbox if people want to. As I
> said I really don't care.
>
> Rémy
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this mess
OSGification, but
> about jsrtwonineonification.
>
> Damien
>
> PS: usually only reader on this ML
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View
e load balancing/failover/multiple
> servers - you have a better/safer solution.
>
> Costin
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Osgifing-Tomcat-tp16830131p16930343.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ds, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional com
> 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
1 - 100 of 104 matches
Mail list logo
