Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
snip/
We should also consider if blocks should be _similar_ to Eclipse
plugins, of if they should _be_ such plugins, which would remove us
a log of work, both for code, docs and support.
I have read some Eclipse docu,
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
AFAIU only some work on cForms is missing (flowscript API and
repeater binding)
That's far from the only work to do IMO, as there are a lot of
semi-finished core features. Some that come to mind:
-Original Message-
From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 24. Mai 2005 13:40
To: dev@cocoon.apache.org
Subject: Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
snip/
We should also
Nathaniel Alfred wrote:
Instead of a micro kernel which is going to have again a large footprint to do
anything useful I'd rather prefer a small kernel to do just what Cocoon needs.
After all Cocoon is just a super-servlet which needs a bit of container
services for managing component reuse
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
On that point, I proposed to write a new implementation of the
flowscript implementation. This is certainly not a total rewrite, but
a refactoring of the existing code to have an overally consistent
object model, and also introduce a flow
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
On that point, I proposed to write a new implementation of the
flowscript implementation. This is certainly not a total rewrite, but
a refactoring of the existing code to have an overally consistent
object model, and
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Uh? What are these features? Would you mind sharing this with us?
Sure; I already mentioned this months ago and even asked on this list
for help; but noone was interested :(
Actually, I was and am interested. I just can't get my boss
Sylvain Wallez wrote:
Actually, OSGi is a key point in the performance improvements in the
upcoming Eclipse 3.1. It was introduced in 3.0 but many plugins were
still written on the previous kernel API, and the more plugins move to
the OSGi API, the more startup time increases and memory used
Ralph Goers wrote:
Why is updating more difficult. We have MBeans that do both. Creating an
operation that updates isn't that hard. The hard part is figuring out
what you want to manage.
And what happens after you updated a value. Changing pool sizes or
something like that is easy. But
Carsten Ziegeler wrote:
Ralph Goers wrote:
Why is updating more difficult. We have MBeans that do both. Creating an
operation that updates isn't that hard. The hard part is figuring out
what you want to manage.
And what happens after you updated a value. Changing pool sizes or
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
All current blocks, the core and libraries that are used by several
bundles are packaged as bundles. These are deployed in a OSGi kernel.
During development the Cocoon bundles can be deployed within the OSGi
kernel of Eclipse together with
Sylvain Wallez wrote:
Reinhard Poetz wrote:
AFAIU only some work on cForms is missing (flowscript API and
repeater binding)
That's far from the only work to do IMO, as there are a lot of
semi-finished core features. Some that come to mind: refactored object
model,
Here the main
Sylvain Wallez wrote:
snip/
We should also consider if blocks should be _similar_ to Eclipse
plugins, of if they should _be_ such plugins, which would remove us a
log of work, both for code, docs and support.
I have read some Eclipse docu, but it is not obvious to me what Eclipse
plugins
Ralph Goers wrote:
However, I wouldn't go looking for operations to perform just
because you can. I would start by identifying the operations you would
find valuable and then prioritize them by need and difficulty to
implement. Would your hypotheical of changing the working directory
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
Ok, so far so good - now, what do I have to do if I'm developing my own
application and want to use let's say the cron block: I want to add my
own scheduled task? Currently I have to know a little bit about Avalon:
using the service manager to
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
[...mostly off topic...]
You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans
means easier integration with/into Geronimo, which is significant
advantage.
Well, is it really?
So which point do you want to argue, that it
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
AFAIU only some work on cForms is missing (flowscript API and
repeater binding)
That's far from the only work to do IMO, as there are a lot of
semi-finished core features. Some that come to mind: refactored
object
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
snip/
We should also consider if blocks should be _similar_ to Eclipse
plugins, of if they should _be_ such plugins, which would remove us a
log of work, both for code, docs and support.
I have read some Eclipse docu, but it is not obvious
On 5/23/05, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
Le 23 mai 05, à 07:13, Reinhard Poetz a écrit :
...Let's release Cocoon 2.2 alpha1 as soon as possible. When the
contracts are stable we use the beta postfix. This will increase the
number of people who use and test the release and
Sylvain Wallez wrote:
Reinhard Poetz wrote:
AFAIU only some work on cForms is missing (flowscript API and repeater
binding)
That's far from the only work to do IMO, as there are a lot of
semi-finished core features. Some that come to mind: refactored object
model, sitemap listeners, VPCs,
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
[...mostly off topic...]
You forgot that since GBeans used in Geronimo, basing Cocoon on
GBeans means easier integration with/into Geronimo, which is
significant advantage.
Well, is it really?
So which point do
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
IMO, OSGi seem to be the best choice for kernel for Cocoon's block
architecture and there is (if I haven't missed something important) a
low risk, incremental and evolutionary way to get there.
Hmm, I'm currently not
Reinhard Poetz wrote:
- breaking up the monolitic Cocoon
- getting over the Java jar hell
- making development of Cocoon extensions outside of the
Cocoon project much easier (why there are hardly any Cocoon based
projects out, except Daisy, Lenya, Forrest and two or three others)
-
Carsten Ziegeler wrote:
SNIP/
But again, if I'm the only one with these feelings, I can simply shut up
and watch the show :(
Just to clarify: of course, this doesn't mean that I would not help or
contribute.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
- breaking up the monolitic Cocoon
- getting over the Java jar hell
- making development of Cocoon extensions outside of the
Cocoon project much easier (why there are hardly any Cocoon based
projects out, except Daisy, Lenya, Forrest and two
Leszek Gawron wrote:
snip/
I tried to find any starters for eclipse's OSGi implementation. Not a
single useful page. If we are to make users read OSGi specification,
then seek for help in external projects that are hardly documented we
get the same problem in a fancy new outfit.
OSGi is a
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
- breaking up the monolitic Cocoon
- getting over the Java jar hell
- making development of Cocoon extensions outside of the
Cocoon project much easier (why there are hardly any Cocoon based
projects out, except Daisy, Lenya, Forrest and two
Daniel Fagerstrom wrote:
IMO it will. AFAIU the plugin concept in Eclipse is considered straight
forward for most people. The blocks will be very similar to plugins.
Ok, but even if it's simple, you have to learn it :)
Its not an exchange of Avalon with OSGi.
I know, I didn't mean a
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
IMO it will. AFAIU the plugin concept in Eclipse is considered straight
forward for most people. The blocks will be very similar to plugins.
Ok, but even if it's simple, you have to learn it :)
Its not an exchange of Avalon with OSGi.
I
Carsten Ziegeler wrote:
snip/
I'm currently still missing the *big picture*. What are blocks, how does
Cocoon look like with them. Can I develop something without blocks? What
do I have to learn? And so on. This might be because I didn't have so
much time for Cocoon in the last weeks, don't
Daniel Fagerstrom wrote:
All current blocks, the core and libraries that are used by several
bundles are packaged as bundles. These are deployed in a OSGi kernel.
During development the Cocoon bundles can be deployed within the OSGi
kernel of Eclipse together with various Cocoon
Carsten Ziegeler wrote:
In my opinion, 2.2 is more or less feature complete; there are *many* things to
cleanup
Definitely.
and I'm currently playing with adding administration and monitoring.
Uh? What are these features? Would you mind sharing this with us?
Sylvain
--
Sylvain
Reinhard Poetz wrote:
AFAIU only some work on cForms is missing (flowscript API and repeater
binding)
That's far from the only work to do IMO, as there are a lot of
semi-finished core features. Some that come to mind: refactored object
model, sitemap listeners, VPCs, third-party
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
Users never really understood Avalon; but interestingly everyone
understands Spring - which is the same concepts of Avalon but done
differently (I know, I simplify here a little bit, please, all Spring
lovers forgive me for now!).
Adding a
Le 23 mai 05, à 07:13, Reinhard Poetz a écrit :
...Let's release Cocoon 2.2 alpha1 as soon as possible. When the
contracts are stable we use the beta postfix. This will increase the
number of people who use and test the release and finally we can
release Cocoon 2.2.0 final...
Releasing 2.2
Sylvain Wallez wrote:
Uh? What are these features? Would you mind sharing this with us?
Sure; I already mentioned this months ago and even asked on this list
for help; but noone was interested :(
Anyways, I'm thinking of adding a JMX interface, so you can monitor your
Cocoon instance using
Le 22 mai 05, à 20:24, Daniel Fagerstrom a écrit :
...It would require quite a lot of work to give a fair overview of
what we have discussed about this in the last three or so years. You
find some info in http://wiki.apache.org/cocoon/Blocks...
Would it be possible to come up with a (small)
Le 23 mai 05, à 07:32, Carsten Ziegeler a écrit :
..I'm thinking of adding a JMX interface, so you can monitor your
Cocoon instance using JMX...
...The second part - which is much more difficult - would be to allow
to
change some values during runtime...
Hmm...maybe this second part
Le 20 mai 05, à 15:38, Daniel Fagerstrom a écrit :
Sylvain proposed [1] to base blocks on the OSGi service platform
[2][3]. After having studied it in more detail I'm completely
convinced that it is the way to go...
After reading some of the knopflerfish and osgi.org material I agree
that
Daniel Fagerstrom wrote:
Sylvain proposed [1] to base blocks on the OSGi service platform
[2][3]. After having studied it in more detail I'm completely
convinced that it is the way to go.
Yeah! Kewl :-)
OSGi
The OSGi service platform is a standarized, component oriented,
computing
Thor Heinrichs-Wolpert wrote:
Daniel:
Check out RIO, which is a QoS oriented system based upon Jini. It has
either completed its relicensing or will have completed its relicensing
to use the Apache 2.0 license. This is the infrastructure used in
Sun's RFID initiative and in their
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
The Cocoon servlet bundle
-
At last we need to have a Cocoon servlet bundle it looks up the Cocoon
service and a HTTP service [10] (both Tomcat and Jetty implementations
are available), embeds the Cocoon service in
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
The Cocoon servlet bundle
-
At last we need to have a Cocoon servlet bundle it looks up the
Cocoon service and a HTTP service [10] (both Tomcat and Jetty
implementations are
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
So GBeans seem like the only serious alternative. I don't know enough
about GBeans to be able to evaluate it. But its much earlier in its
development, it is not a standard and there is only one
implementation, so it should IMO have a
On Vie, 20 de Mayo de 2005, 8:38, Daniel Fagerstrom dijo:
Sylvain proposed [1] to base blocks on the OSGi service platform [2][3].
After having studied it in more detail I'm completely convinced that it
is the way to go.
OSGi
The OSGi service platform is a standarized, component
Daniel Fagerstrom wrote:
IMO, OSGi seem to be the best choice for kernel for Cocoon's block
architecture and there is (if I haven't missed something important) a
low risk, incremental and evolutionary way to get there.
Hmm, I'm currently not sure if we really need such an infrastructure
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
IMO, OSGi seem to be the best choice for kernel for Cocoon's block
architecture and there is (if I haven't missed something important) a
low risk, incremental and evolutionary way to get there.
Hmm, I'm currently not sure if we really need
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
The Cocoon servlet bundle
-
At last we need to have a Cocoon servlet bundle it looks up the Cocoon
service and a HTTP service [10] (both Tomcat and Jetty implementations
are available), embeds the Cocoon service in the
Sylvain proposed [1] to base blocks on the OSGi service platform [2][3].
After having studied it in more detail I'm completely convinced that it
is the way to go.
OSGi
The OSGi service platform is a standarized, component oriented,
computing environment for networked services. It handled
An interesting read. Where does the servlet container sit within this
picture? Do you need to have an OSGi servlet? Eclipse could by the sound
of it load these bundles, but wouldn't be able to run them due to a lack
of servlet container.
Regards, Upayavira
Daniel Fagerstrom wrote:
Sylvain
Daniel Fagerstrom wrote:
Sylvain proposed [1] to base blocks on the OSGi service platform [2][3].
After having studied it in more detail I'm completely convinced that it
is the way to go.
Alternatives
So GBeans seem like the only serious alternative. I don't know enough
about
Upayavira wrote:
An interesting read. Where does the servlet container sit within this
picture?
Simplest way is to use an implementation of the HTTP service [1], there
is a Jetty version http://oscar-osgi.sourceforge.net/repo/http/, a
version with (AFAICS) an own servlet conatiner
Daniel:
Check out RIO, which is a QoS oriented system based upon Jini. It
has either completed its relicensing or will have completed its
relicensing to use the Apache 2.0 license. This is the
infrastructure used in Sun's RFID initiative and in their Formula1
Race Car monitoring system.
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Sylvain proposed [1] to base blocks on the OSGi service platform
[2][3]. After having studied it in more detail I'm completely
convinced that it is the way to go.
Alternatives
So GBeans seem like the only serious alternative. I don't
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans
means easier integration with/into Geronimo, which is significant
advantage.
Might be, I don't have enough knowledge (or interest for, at least yet
;) ) about Geronimo to be
Daniel Fagerstrom wrote:
OSGi specification is currently at its 3rd release. It is used as
kernel for Eclipse (since 3.0), each plugin is a bundle. It is used
for embeded applications e.g. BMWs 5 series, mobile phones etc.
There are 12 compliant implementations and at least 3 with friendly
56 matches
Mail list logo
