You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2006/02/02 11:31:57 UTC
Re: [RT] The environment abstraction, part II
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
>> Upayavira skrev:
>>
>>> Daniel Fagerstrom wrote:
>>>
>>>> Upayavira wrote:
...
>> We can also release with non OSGi blocks. The blocks are ongoing work,
>> the most important thing that lacks is "two level configuration". As
>> discussed before the component configuration is part of the block and
>> constant, so they need to be parametrized in some way for making them
>> user configurable. We have not had much discussion about how to do
>> this yet.
>
> My understanding is that a user can parameterize a block at deployment
> (which is supported by the block deployer) if he wants. Otherwise the
> default values are taken.
Yes, but that says nothing about the details about parametrization of
components (which isn't implemented yet), does it?
>> Also the APIs and concepts for blocks need to actually be used for
>> some real life examples before we can be convinced that we got it right.
>
> Of course. I'm working on getting trunk as far as making it very simple
> to use it for custom projects. Then I will start to rework at least one
> of my projects to use blocks and learn more about their real life usage.
> We should make it easy that at least we developers (and some brave
> users) can start to experiment.
Hope to be able to use it in my projects as well.
>>> Gradual steps, release often is good.
>>
>> Agree, but as it will be the first release from trunk the threshold is
>> higher.
>
> IMO we should consolidate the current status and make trunk useable for
> projects again which should result in agreeing on our external contracts.
Yes
>>> Making life harder for future
>>> exciting developments by releasing too early isn't good.
>>
>> Exactly, one point i that trunk contains nice mechanisms for
>> parameterizing components and sitemaps at a global level and also for
>> having foreign component managers within sitemaps. While very usefull
>> for the current development style in Cocoon they are not very relevant
>> for blocks. For blocks we should avoid global configurations as it is
>> in the way for splitting Cocoon in small reusable parts. And also
>> component configurations in sitemaps is rather unnecessary when we
>> have component configurations on the block level.
>>
>> So what should we do about introducing things that we know that we
>> will want to remove in a later release?
>
> As long as we have milestone releases, I have no problem with sitemap
> classloaders and sitemap application containers. If both features become
> block functionality, people have to migrate. (IIRC also Eclipse had some
> incompatible changes in their 3.0 milestone series.)
I have not that much problem with the sitemap stuff, it shouldn't be
that hard to migrate them. I'm more concerned about the Core and
Settings objects, that is part of the trunk contract and that doesn't
fit well into a splited up non-monolithic architecture.
>>>>> If this is the case, then it would seem timely to improve these
>>>>> interfaces now, as 2.2 given the greater flexibility could become
>>>>> _the_
>>>>> future Cocoon, and we may miss the boat if we don't make this
>>>>> change now.
>>>>
>>>> Yes, I feel some urgency. With enough focus and dedication on
>>>> refactoring Cocoon and finish the blocks Cocoon can be the Rich Server
>>>> Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And
>>>> regain its momentum. Focusing on 2.2 seem more like losing valuable
>>>> time
>>>> for me.
>>>
>>>
>>> Well, define 2.2 :-)
>>>
>>> I presume you mean releasing a Maven based Cocoon without a ready blocks
>>> system would loose valuable momentum.
>>
>>
>> Yes.
>
> Do you have a roadmap on what's open?
* Component handling - design issues
* Logging - I put it in the BlocksManager but didn't give it much
thought, here is a new chance for all logging enthusiasts to discuss ;)
* Multi part MIME handling - not part of the blocks architecture to
simplify things, would make most sense to put in a ServletFilter IMO
* Error handling - there is sophisticated creation of error messages in
the CocoonServlet, where is the right place for it in the blocks
architecture?
* JARed blocks - the BlocksManager assumes that the wiring location
points to unpacked blocks, implement support for packed blocks.
I think these are the main issues.
/Daniel
Re: Component parameterization
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
>> Do you mean how the parameters from wiring.xml finally arrive in the
>> component configuration?
>>
> Yes.
>
> Parameters from the wiring get to the servlet as servlet context
> parameters, but how to solve it for components is unclear. Not talking
> about that I don't think that the servlet and the individual components
> should be parametrized as a collective, they should be parametrized
> separately. But that is another question.
Isn't it enough that you can reference block parameters in your component
declaration, e.g.
<continuations-manager>
<expiration-time>{expiration-time}</expiration-time>
</continuations-manager>
And in block.xml you have
<block>
...
<parameters>
<parameter name="expiration-time" default="1000"/>
</parameters>
...
</block>
What am I missing?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Component parameterization
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
>> Reinhard Poetz skrev:
>>
>>> Daniel Fagerstrom wrote:
>>>> We can also release with non OSGi blocks. The blocks are ongoing
>>>> work, the most important thing that lacks is "two level
>>>> configuration". As discussed before the component configuration is
>>>> part of the block and constant, so they need to be parametrized in
>>>> some way for making them user configurable. We have not had much
>>>> discussion about how to do this yet.
>>>
>>>
>>> My understanding is that a user can parameterize a block at
>>> deployment (which is supported by the block deployer) if he wants.
>>> Otherwise the default values are taken.
>>
>>
>> Yes, but that says nothing about the details about parametrization of
>> components (which isn't implemented yet), does it?
>
> Do you mean how the parameters from wiring.xml finally arrive in the
> component configuration?
>
Yes.
Parameters from the wiring get to the servlet as servlet context
parameters, but how to solve it for components is unclear. Not talking
about that I don't think that the servlet and the individual components
should be parametrized as a collective, they should be parametrized
separately. But that is another question.
/Daniel
Component parameterization
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz skrev:
>
>> Daniel Fagerstrom wrote:
>>> We can also release with non OSGi blocks. The blocks are ongoing
>>> work, the most important thing that lacks is "two level
>>> configuration". As discussed before the component configuration is
>>> part of the block and constant, so they need to be parametrized in
>>> some way for making them user configurable. We have not had much
>>> discussion about how to do this yet.
>>
>>
>> My understanding is that a user can parameterize a block at deployment
>> (which is supported by the block deployer) if he wants. Otherwise the
>> default values are taken.
>
>
> Yes, but that says nothing about the details about parametrization of
> components (which isn't implemented yet), does it?
Do you mean how the parameters from wiring.xml finally arrive in the component
configuration?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Futher block-fw development
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
...
>>> Do you have a roadmap on what's open?
>>
>>
>> * Component handling - design issues
>
> ok, that's the main question that needs to be answered
>
>> * Logging - I put it in the BlocksManager but didn't give it much
>> thought, here is a new chance for all logging enthusiasts to discuss ;)
>
> hehe
>
>> * Multi part MIME handling - not part of the blocks architecture to
>> simplify things, would make most sense to put in a ServletFilter IMO
>
> ok (haven't thought about this yet)
>
>> * Error handling - there is sophisticated creation of error messages
>> in the CocoonServlet, where is the right place for it in the blocks
>> architecture?
>
> ok (haven't thought about this yet either)
>
>> * JARed blocks - the BlocksManager assumes that the wiring location
>> points to unpacked blocks, implement support for packed blocks.
>
> ok, IMHO a nice to have for me and transparent for the user.
>
> Do you mind if I create JIRA tasks for them? I would like to use the
> roadmap feature of JIRA to make it visible for lurkes on what we are doing.
I forgot that role handling needs some attention also. The concept of
role handling is Avalon specific, so it doesn't work that well if we
want to register e.g. our sitemap components as OSGi services or Spring
components. Maybe we could just put the role info in the container as
well so that we don't need to maintain a parallel set of rolemanagers
for the blocks.
/Daniel
Re: Futher block-fw development
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Quite the opposite, JIRA issues would be good.
Done
(https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310170&sorter/order=DESC&sorter/field=priority&resolution=-1&component=12310706).
As you probably know, you can create sub-tasks for each issue to split an issue
up into smaller working packages.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Futher block-fw development
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
>
>> I have not that much problem with the sitemap stuff, it shouldn't be
>> that hard to migrate them. I'm more concerned about the Core and
>> Settings objects, that is part of the trunk contract and that doesn't
>> fit well into a splited up non-monolithic architecture.
>
> Hmm, which external contracts are affected by how the "framework" works?
> The only contract I see is where block.xml is located
> (/META-INF/block.xml) and which XML (defined by the namespace). This way
> the framework (and the deployer) find out whether they can work with a
> given block or not. Do you see any other dependencies?
Ok, I talked about a 2.2 release in general, the block fw is a separate
concern and shouldn't be affected by the mentioned objects (except that
it has been a real pain to refactor away the dependence on them and that
there still is some work to be done).
> Currently you can configure the deployer which blocks-fw you want to use
> (which is the actual core IMHO) and blocks-fw depends on the legacy
> core. As said, this is completly unrelated to the blocks.
My intension is to remove the block fw dependencies on cocoon-core,
still some work left.
>>> Do you have a roadmap on what's open?
>>
>>
>> * Component handling - design issues
>
> ok, that's the main question that needs to be answered
>
>> * Logging - I put it in the BlocksManager but didn't give it much
>> thought, here is a new chance for all logging enthusiasts to discuss ;)
>
> hehe
I don't know that much about logging. But my main thoughts is that
logging need to be a centralized service, common for all blocks
(separate logging solutions for each block would be a pain).
The logging implementation is contained in a block (that is installed
early) and makes the logger available as a service that other block can
get through the service manager. This way the logging implementation is
chosen by the choice of logging block. Observe that I only is talking
about the blocks fw, within a block an ordinary ECM can be set up and it
will inject the logger in its managed objects through the usual Avalon
style.
Using the same logger interface everywhere is also practical I guess we
continue to use the o.a.avalon.framework.logger.Logger one.
>> * Multi part MIME handling - not part of the blocks architecture to
>> simplify things, would make most sense to put in a ServletFilter IMO
>
> ok (haven't thought about this yet)
I think it makes most sense to let multi part MIME be centralized and at
the start of the call chain, it doesn't make sense to have it at the
block level AFAICS. So we could make it part of the BlocksManager, but I
prefer to keep the BlocksManager focused, so a filter before the
BlocksManager seem to be a good alternative.
That also means that the multi part MIME handler is reusable for others
(or that we can use another implementation if we want). Setting up a
filter isn't such a big deal, so it is easy to do even outside a servlet
container.
>> * Error handling - there is sophisticated creation of error messages
>> in the CocoonServlet, where is the right place for it in the blocks
>> architecture?
>
> ok (haven't thought about this yet either)
Neither have I.
>> * JARed blocks - the BlocksManager assumes that the wiring location
>> points to unpacked blocks, implement support for packed blocks.
>
> ok, IMHO a nice to have for me and transparent for the user.
>
> Do you mind if I create JIRA tasks for them? I would like to use the
> roadmap feature of JIRA to make it visible for lurkes on what we are doing.
Quite the opposite, JIRA issues would be good.
/Daniel
Futher block-fw development
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> I have not that much problem with the sitemap stuff, it shouldn't be
> that hard to migrate them. I'm more concerned about the Core and
> Settings objects, that is part of the trunk contract and that doesn't
> fit well into a splited up non-monolithic architecture.
Hmm, which external contracts are affected by how the "framework" works? The
only contract I see is where block.xml is located (/META-INF/block.xml) and
which XML (defined by the namespace). This way the framework (and the deployer)
find out whether they can work with a given block or not. Do you see any other
dependencies?
Currently you can configure the deployer which blocks-fw you want to use (which
is the actual core IMHO) and blocks-fw depends on the legacy core. As said, this
is completly unrelated to the blocks.
>> Do you have a roadmap on what's open?
>
>
> * Component handling - design issues
ok, that's the main question that needs to be answered
> * Logging - I put it in the BlocksManager but didn't give it much
> thought, here is a new chance for all logging enthusiasts to discuss ;)
hehe
> * Multi part MIME handling - not part of the blocks architecture to
> simplify things, would make most sense to put in a ServletFilter IMO
ok (haven't thought about this yet)
> * Error handling - there is sophisticated creation of error messages in
> the CocoonServlet, where is the right place for it in the blocks
> architecture?
ok (haven't thought about this yet either)
> * JARed blocks - the BlocksManager assumes that the wiring location
> points to unpacked blocks, implement support for packed blocks.
ok, IMHO a nice to have for me and transparent for the user.
Do you mind if I create JIRA tasks for them? I would like to use the roadmap
feature of JIRA to make it visible for lurkes on what we are doing.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de