[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: Block deployment: working with blocks from a user's point of
From:       Reinhard Poetz <reinhard () apache ! org>
Date:       2006-01-13 6:15:49
Message-ID: 43C74595.2020002 () apache ! org
[Download RAW message or body]

Giacomo Pati wrote:

<snip/>

> In Reinhards document it is META-INF/block.xml on the Wiki it's 
> COB-INF/block.xml. So we need to make a decision:-)

Please use META-INF/block.xml, AFAIK we agreed on making our blocks valid JAR 
files. The skeleton in my tutorial should be compiled and packaged to an archive 
having following content:

/JAR-FILE-ROOT
  +-com
  | +-mycompany
  |   +-blocks
  |     +-myblock
  |       +-MyCocoonAction.class
  +-META-INF
  | +-block.xml
  |   +-com
  |   +-mycompany
  |     +-blocks
  |       +-myblock
  |         +-pom.xml
  +-cocoon-app
    +-sitemap.xmap
    +-test.xml

If we follow the default Maven directory structure as outlined in my tutorial, 
the archive will be created automatically for us.

>> Now to answer your question ;) the position of the .xconf of a block 
>> is defined in the components element of block.xml.
> 
> 
> Ok, looking at [1] it is defined in the block.xconf file, which is 
> located in COB-INF (or WEB-INF or META-INF respectively). Is that still 
> correct?

I'm not sure where block.xconf should go to. I'd put it under cocoon-app and not 
under META-INF. WDOT?

> 
>>>  Do we need a different mechanism to include those (is copying over 
>>> to the
>>>  Cocoon WEB-INF/xconf an option for rapid development)?
>>
>>
>> For blocks the component configuration file is intended to be fixed 
>> and included in the block jar. So it is never copied anywhere as in 
>> 2.2 before M2. User configurability is solved with using block 
>> properties in the configuration file instead. Whether this will be 
>> enough is an open question. But I guess most agree with that the copy 
>> and modify approach to configurations in 2.1 not is the way to go.
>>
>> For rapid development the wiring.xml (or some development time 
>> equivalent) should point to the source code of the respective blocks, 
>> rather than on some packaged and deployed blocks.
> 
> 
> Forget it. The current inclusion mechanism with the xconf directory in 
> WEB-INF is obsolete I guess.

yes

> 
>>>  How can one ev. define logkit.xml stuff if they want to have their own
>>>  logging factory/target/category for the components defined in the block
>>>  (asuming logkit is still the main logging system in Cocoon)?
>>
>>
>> That is an open question, we have not discussed that much. In the 
>> current implementation I have just reused the existing Cocoon 
>> mechanism with centralized log configurations in /WEB-INF, and is 
>> feeding the Logger to all the blocks. But I would much prefer to 
>> distribute configurations and maybe even choice of logging framework 
>> to the individual blocks. OTH completely distributed logging with 
>> numerous log strategies in the same applications, will be nightmare 
>> when trying to see what got wrong so some level of centralization is 
>> required.
>>
>> WDYT?
> 
> 
> I'd pretty much like distributed logging configuration (whereas
> distributed logging implementation might be overkill).

I want to see this too. But I think we should wait a bit with finding solutions 
for this.

>>>  Same applies to stuff going into web.xmlof the context?
>>
>>
>> After the refactoring I actually use the ServletContext, with a few 
>> extra methods for all block context information and inter block 
>> communication. Everything isn't implemented yet, but the idea is that 
>> the individual blocks get a context object that wrapps the servlet 
>> context from the container and in some cases add and in some cases 
>> overide the content of that.
>>
>> But this is also a rather open question. The current implementation 
>> uses the o.a.c.core.Settings interface that Carsten have developed and 
>> that have a rather neat impelemntation where you can combine the 
>> web.xml parameters with Java properties. But the bad thing about it in 
>> the block context is that it is centralized. We need to discuss what 
>> settings that need to be centralized and what we want to handle on the 
>> block level.
> 
> 
> One thing of the web.xml is configuration stuff that is passed to the 
> Servlet (which is Cocoon) deployed. This is not troubling me (we do have 
> other mechanisms to pass down configuration values as you've described).
> 
> The other thing is container configuration as defined by the Servlet 
> Spec (security, mime types, and alike). Blocks might want to define 
> security policies for the URL they are mounted on.

good points, but same again here: we should wait until we have a simple block 
based application running and then we can talk about this, logging configuration 
and settings/property management.

> [1] http://wiki.apache.org/cocoon/BlocksDefinition

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]