cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Heiden" <patrickhei...@gmx.de>
Subject Re: [HELP]: blocks and domainmodel
Date Thu, 20 Mar 2008 12:56:48 GMT
Hi Grzegorz,

I've just tested the approach of seperating domain/cocoon-blocks and it works fine. I will
follow your suggestion and put a dependency in every block wich will use the domain-model
(partly). Thank you for that!

One other issue: I am wondering a little bit, why a call to webbAppCtx.containsBeanDefinition("def")
returns null. I am able to use the bean through cocoon.getComponent("def"). I guess this is
one of the implementation-details again ;)

Best Greetings,
Patrick
-------- Original-Nachricht --------
> Datum: Thu, 20 Mar 2008 13:12:34 +0100
> Von: Grzegorz Kossakowski <grek@tuffmail.com>
> An: users@cocoon.apache.org
> Betreff: Re: [HELP]: blocks and domainmodel

> Patrick Heiden pisze:
> > Hello again!
> > 
> > So following your advised discussion, I am able to create the whole
> domainmodel as standalone
> > .jar and add this as dependency to webapp-block, right? Of course I also
> have to put the
> > domain-appCtx.xml into the META-INF/cocoon/spring directory. If I would
> do so, are all other
> > blocks automatically aware of my domain.jar, or do I have to put the
> dependency to every blocks
> > pom.xml wich is going to use it (besides testing!)?
> 
> Hello Patrick,
> 
> As it has been said earlier it will be visible because there is only one
> Global context and now 
> isolation. Anyway, it's just an _implementation detail_ and *not* a design
> goal. That means you 
> should always reflect dependencies of your code, logic in POM files.
> 
> Not doing so really breaks design and it's a great opportunity for serious
> problems to occur. The 
> great example is current situation in SSF described by COCOON-2176[1]
> issue. While adding dependency 
> on CocoonSourceResolver as a temporary solution we introduced dependency
> on cocoon-core but we 
> forgot to state this fact in POM. Everything was working fine because we
> were testing SSF mostly in 
> a Cocoon environment where cocoon-core dependency was present due to other
> artifacts. This lead to 
> the situation that we eventually forgot about this obscure dependency on
> cocoon-core and 
> rediscovered it just before final release of SSF.
> 
> Not stating dependencies in POM files can lead to the hidden circular
> dependencies which are even 
> more nastier. In short: always, always state all of your dependencies in
> all of your POMS, period.
> 
> [1] https://issues.apache.org/jira/browse/COCOON-2176
> 
> 
> -- 
> Grzegorz Kossakowski
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message