You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2006/11/02 09:26:38 UTC
Restructuring directory structure[was [Vote] Block artifact directory
structure]
Ok, it seems that we are all in favour of restructuring our directory
structure for 2.2.
Could someone please write/run a script that does the work? The final
result should be:
>> META-INF/cocoon/xconf/**
>> META-INF/cocoon/spring/**
>> META-INF/cocoon/properties/**
Thanks
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Leszek Gawron wrote:
>> Carsten Ziegeler wrote:
>>> Giacomo Pati wrote:
>>>> Just to clear things:
>>> :)
>>>
>>>> Carsten Ziegeler wrote:
>>>>>> Done - with the additional change discussed recently, so now we have:
>>>>>>
>>>>>>>>> META-INF/cocoon/avalon/**
>>>>>>>>> META-INF/cocoon/spring/**
>>>> plus ev. mode subdir {dev,test,proc}
>>>>
>>> Yes, but only for the properties! It's simple to add this for reading
>>> avalon and spring configurations, if desired?!?
>> I heard somewhere on the list that some developers (Giacomo?) where
>> using property placeholders for defining mock beans.
>
> Yup,that was me. Before one could do that which has been handy together
> with different modes:
>
>> I could also find this useful. Especially when 'new CLI':
>>
>> ApplicationContext = new ClasspathXmlApplicationContext(
>> "applicationContext.xml" );
>>
>> will finally create full blown cocoon container. I suppose 'when' might
>> have changed to 'already' after the changes from last two days.
>
> Whatever you mean by that !?!?
I meant:
- create a maven project
- add cocoon-template-impl dependency
get applicationContext.xml from
core/cocoon-webapp/src/main/webapp/WEB-INF/applicationContext.xml:
> <beans xmlns="http://www.springframework.org/schema/beans"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:util="http://www.springframework.org/schema/util"
> xmlns:cocoon="http://cocoon.apache.org/core"
> xmlns:avalon="http://cocoon.apache.org/avalon"
> xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
> http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd
> http://cocoon.apache.org/core http://cocoon.apache.org/core.xsd
> http://cocoon.apache.org/avalon http://cocoon.apache.org/avalon.xsd">
> <!-- Load all the properties for Cocoon -->
> <cocoon:settings/>
>
> <!-- Load Avalon configurations
> If you want to use a different logger than the default log4j logger,
> add a bean conforming to the Avalon Logger interface to this definition
> and leave out the loggingConfiguration attribute.
> If you have an own cocoon.xconf specify the location attribute,
> like location="/WEB-INF/cocoon/cocoon.xconf".
> -->
> <avalon:avalon loggingConfiguration="/WEB-INF/cocoon/log4j.xconf"/>
> </beans>
create a simple application:
public class Test {
public static void main( String[] args ) {
ApplicationContext context = new ClassPathXmlApplicationContext(
"applicationContext.xml" );
}
}
you *should* have your cocoon up and running. It's easy now to lookup
beans, fairly easy to setup a pipeline, run it and get the results.
Unfortunately it still breaks:
> INFO (2006-11-04) 14:28.03:392 [org.springframework.core.CollectionFactory] JDK 1.4+ collections available
> INFO (2006-11-04) 14:28.03:407 [org.springframework.core.CollectionFactory] Commons Collections 3.x available
> INFO (2006-11-04) 14:28.03:485 [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] Loading XML bean definitions from class path resource [applicationContext.xml]
> INFO (2006-11-04) 14:28.04:485 [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] Loading XML bean definitions from URL [file:C:/dev/projects/viessmann-pi/server/core/src/main/resources/META-INF/cocoon/spring/acegi-authentication.xml]
> INFO (2006-11-04) 14:28.04:595 [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] Loading XML bean definitions from URL [file:C:/dev/projects/viessmann-pi/server/core/src/main/resources/META-INF/cocoon/spring/acegi-web.xml]
> INFO (2006-11-04) 14:28.04:642 [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] Loading XML bean definitions from URL [file:C:/dev/projects/viessmann-pi/server/core/src/main/resources/META-INF/cocoon/spring/acegi.xml]
> INFO (2006-11-04) 14:28.04:767 [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] Loading XML bean definitions from URL [jar:file:/C:/Documents%20and%20Settings/lgawron/.m2/repository/org/apache/cocoon/cocoon-core/2.2.0-M2-SNAPSHOT/cocoon-core-2.2.0-M2-SNAPSHOT.jar!/META-INF/cocoon/spring/cocoon-core-applicationContext.xml]
> INFO (2006-11-04) 14:28.04:813 [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] Loading XML bean definitions from URL [file:C:/dev/projects/viessmann-pi/server/core/src/main/resources/META-INF/cocoon/spring/core-services.xml]
> INFO (2006-11-04) 14:28.04:892 [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] Loading XML bean definitions from URL [file:C:/dev/projects/viessmann-pi/server/core/src/main/resources/META-INF/cocoon/spring/core.xml]
> INFO (2006-11-04) 14:28.05:017 [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] Loading XML bean definitions from URL [file:C:/dev/projects/viessmann-pi/server/pi-api/src/main/resources/META-INF/cocoon/spring/pi-api.xml]
> INFO (2006-11-04) 14:28.06:001 [org.springframework.context.support.ClassPathXmlApplicationContext] Bean factory for application context [org.springframework.context.support.ClassPathXmlApplicationContext;hashCode=15532856]: org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [org.apache.cocoon.configuration.Settings,org.apache.cocoon.core.container.spring.CocoonPropertyOverrideConfigurer,javax.servlet.ServletContext,userDetailsService,filterChainProxy,httpSessionContextIntegrationFilter,basicProcessingFilter,basicProcessingFilterEntryPoint,exceptionTranslationFilter,filterSecurityInterceptor,roleVoter,accessDecisionManager,testingAuthenticationProvider,daoAuthenticationProvider,authenticationManager,org.apache.cocoon.processing.ProcessInfoProvider,investmentDao,partnerDao,regionDao,userDao,investmentService,partnerService,regionService,userService,org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor,dataSource,
sessionFactory,baseHibernateDao,transactionManager,org.springframework.aop.config.internalAutoProxyCreator,org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor,xmlRequestApple,storeInvestmentApple,investmentParser,org.apache.avalon.framework.context.Context,org.apache.avalon.framework.service.ServiceManager,org.apache.avalon.framework.logger.Logger,org.apache.cocoon.serialization.Serializer/htmlPooled,org.apache.cocoon.serialization.Serializer/html,org.apache.cocoon.acting.Action/session-state,org.apache.cocoon.acting.Action/session-validator,org.apache.cocoon.generation.Generator/directoryPooled,org.apache.cocoon.generation.Generator/directory,org.apache.cocoon.generation.Generator/imagedirectoryPooled,org.apache.cocoon.generation.Generator/imagedirectory,org.apache.cocoon.transformation.Transformer/<gatherer>Pooled,org.apache.cocoon.transformation.Transformer/<gatherer>,org.apache.cocoon.components.flow.Interpreter/service-apples,org.apache.cocoon.c
omponents.modules.input.InputModule/request,org.apache.cocoon.components.modules.input.InputModule/flow-attribute,org.apache.cocoon.selection.Selector/exception,org.apache.cocoon.reading.ReaderSelector,org.apache.excalibur.store.Store,org.apache.cocoon.acting.Action/set-header,org.apache.cocoon.components.pipeline.ProcessingPipeline/caching-pointPooled,org.apache.cocoon.components.pipeline.ProcessingPipeline/caching-point,org.apache.excalibur.xml.xslt.XSLTProcessorPooled,org.apache.excalibur.xml.xslt.XSLTProcessor,org.apache.excalibur.xml.dom.DOMSerializer,org.apache.cocoon.serialization.Serializer/sxdPooled,org.apache.cocoon.serialization.Serializer/sxd,org.apache.cocoon.selection.Selector/header,org.apache.cocoon.components.modules.input.InputModule/nullinput,org.apache.cocoon.generation.Generator/jxPooled,org.apache.cocoon.generation.Generator/jx,org.apache.cocoon.components.pipeline.ProcessingPipelineSelector,org.apache.cocoon.components.modules.input.InputModule/mapmeta,
org.apache.cocoon.classloader.reloading.Monitor,org.apache.cocoon.transformation.Transformer/filterPooled,org.apache.cocoon.transformation.Transformer/filter,org.apache.cocoon.components.modules.output.OutputModule/request-attr,org.apache.cocoon.components.flow.InterpreterSelector,org.apache.excalibur.source.SourceResolver,org.apache.excalibur.source.SourceFactory/cocoon,org.apache.cocoon.components.modules.output.OutputModule/session-attr,org.apache.cocoon.transformation.Transformer/cincludePooled,org.apache.cocoon.transformation.Transformer/cinclude,org.apache.cocoon.serialization.Serializer/xmlPooled,org.apache.cocoon.serialization.Serializer/xml,org.apache.cocoon.acting.Action/resource-exists,org.apache.cocoon.matching.Matcher/parameter,org.apache.cocoon.components.modules.input.InputModule/raw-request-param,org.apache.cocoon.template.script.ScriptManager,org.apache.cocoon.serialization.Serializer/xhtml11Pooled,org.apache.cocoon.serialization.Serializer/xhtml11,org.apache
.cocoon.matching.Matcher/cookie,org.apache.cocoon.selection.Selector/session-attribute,org.apache.cocoon.generation.Generator/requestPooled,org.apache.cocoon.generation.Generator/request,org.apache.cocoon.transformation.Transformer/includePooled,org.apache.cocoon.transformation.Transformer/include,org.apache.cocoon.matching.MatcherSelector,org.apache.cocoon.components.expression.ExpressionFactory,org.apache.cocoon.matching.Matcher/locale,org.apache.cocoon.components.flow.Interpreter/javascript,org.apache.excalibur.xml.xpath.XPathProcessor,org.apache.cocoon.selection.Selector/request-attribute,org.apache.cocoon.reading.Reader/imagePooled,org.apache.cocoon.reading.Reader/image,org.apache.cocoon.matching.Matcher/sessionstate,org.apache.cocoon.components.thread.RunnableManager,org.apache.cocoon.generation.GeneratorSelector,org.apache.cocoon.transformation.Transformer/xalanPooled,org.apache.cocoon.transformation.Transformer/xalan,org.apache.cocoon.components.modules.input.InputMod
ule/request-scoped-attr,org.apache.cocoon.components.modules.input.InputModule/url-decode,org.apache.cocoon.selection.Selector/resource-exists,org.apache.excalibur.source.SourceFactory/*,org.apache.cocoon.acting.ActionSelector,org.apache.cocoon.components.modules.input.InputModule/global,org.apache.cocoon.classloader.ClassLoaderFactory,org.apache.cocoon.i18n.BundleFactory,org.apache.cocoon.components.notification.NotifyingBuilderPooled,org.apache.cocoon.components.notification.NotifyingBuilder,org.apache.cocoon.serialization.Serializer/xhtmlPooled,org.apache.cocoon.serialization.Serializer/xhtml,org.apache.cocoon.components.modules.input.InputModule/flow-attr,org.apache.cocoon.components.expression.ExpressionCompilerSelector,org.apache.cocoon.components.flow.Interpreter/apples,org.apache.cocoon.transformation.Transformer/write-sourcePooled,org.apache.cocoon.transformation.Transformer/write-source,org.apache.cocoon.components.pipeline.ProcessingPipeline/expiresPooled,org.apach
e.cocoon.components.pipeline.ProcessingPipeline/expires,org.apache.cocoon.components.modules.input.InputModule/request-param,org.apache.cocoon.transformation.Transformer/jpathPooled,org.apache.cocoon.transformation.Transformer/jpath,org.apache.cocoon.matching.Matcher/request-parameter,org.apache.cocoon.components.modules.input.InputModule/session-attr,org.apache.excalibur.source.SourceFactorySelector,org.apache.cocoon.components.treeprocessor.TreeBuilder/sitemap-1.0Pooled,org.apache.cocoon.components.treeprocessor.TreeBuilder/sitemap-1.0,org.apache.cocoon.matching.Matcher/referer-match,org.apache.cocoon.serialization.Serializer/zipPooled,org.apache.cocoon.serialization.Serializer/zip,org.apache.cocoon.acting.Action/session-invalidator,org.apache.cocoon.components.modules.input.InputModuleSelector,org.apache.cocoon.transformation.Transformer/paginatePooled,org.apache.cocoon.transformation.Transformer/paginate,org.apache.cocoon.transformation.Transformer/encodeURLPooled,org.apa
che.cocoon.transformation.Transformer/encodeURL,org.apache.cocoon.transformation.Transformer/readDOMsessionPooled,org.apache.cocoon.transformation.Transformer/readDOMsession,org.apache.cocoon.components.expression.ExpressionCompiler/jxpath,org.apache.cocoon.components.expression.ExpressionCompiler/jexl,org.apache.cocoon.generation.Generator/<aggregator>Pooled,org.apache.cocoon.generation.Generator/<aggregator>,org.apache.cocoon.transformation.Transformer/xsltPooled,org.apache.cocoon.transformation.Transformer/xslt,org.apache.cocoon.transformation.Transformer/xincludePooled,org.apache.cocoon.transformation.Transformer/xinclude,org.apache.excalibur.xml.dom.DOMParserPooled,org.apache.excalibur.xml.dom.DOMParser,org.apache.cocoon.components.modules.input.InputModule/naming,org.apache.cocoon.template.expression.StringTemplateParser,org.apache.cocoon.serialization.Serializer/textPooled,org.apache.cocoon.serialization.Serializer/text,org.apache.cocoon.components.modules.input.InputM
odule/chain,org.apache.cocoon.components.modules.input.InputModule/date,org.apache.excalibur.store.StoreJanitor,org.apache.cocoon.transformation.TransformerSelector,org.apache.cocoon.template.expression.StringTemplateParser/jxtg,org.apache.cocoon.generation.Generator/mp3directoryPooled,org.apache.cocoon.generation.Generator/mp3directory,org.apache.cocoon.serialization.Serializer/sxwPooled,org.apache.cocoon.serialization.Serializer/sxw,org.apache.cocoon.components.modules.input.InputModule/xmlmeta,org.apache.cocoon.components.modules.input.InputModule/datemeta,org.apache.cocoon.generation.Generator/filePooled,org.apache.cocoon.generation.Generator/file,org.apache.cocoon.acting.Action/session-isvalid,org.apache.cocoon.transformation.Transformer/jxPooled,org.apache.cocoon.transformation.Transformer/jx,org.apache.cocoon.transformation.helpers.IncludeCacheManager,org.apache.cocoon.serialization.SerializerSelector,org.apache.cocoon.selection.Selector/request-method,org.apache.cocoo
n.components.modules.input.InputModule/digest,org.apache.cocoon.acting.Action/request,org.apache.cocoon.components.modules.input.InputModule/url-encode,org.apache.cocoon.selection.Selector/host,org.apache.cocoon.components.modules.input.InputModule/constant,org.apache.cocoon.transformation.Transformer/logPooled,org.apache.cocoon.transformation.Transformer/log,org.apache.excalibur.xml.xslt.XSLTProcessor/xalanPooled,org.apache.excalibur.xml.xslt.XSLTProcessor/xalan,org.apache.excalibur.source.SourceFactory/module,org.apache.cocoon.matching.Matcher/wildcard,org.apache.cocoon.components.modules.input.InputModule/simplemap,org.apache.cocoon.caching.Cache,org.apache.excalibur.store.Store/TransientStore,org.apache.cocoon.template.expression.StringTemplateParser/default,org.apache.cocoon.generation.Generator/notifyingPooled,org.apache.cocoon.generation.Generator/notifying,org.apache.cocoon.matching.Matcher/mount-table,org.apache.cocoon.components.modules.input.InputModule/locate,org.
apache.cocoon.Processor,org.apache.cocoon.serialization.Serializer/wmlPooled,org.apache.cocoon.serialization.Serializer/wml,org.apache.cocoon.serialization.Serializer/svgxmlPooled,org.apache.cocoon.serialization.Serializer/svgxml,org.apache.cocoon.template.expression.StringTemplateParserSelector,org.apache.cocoon.transformation.Transformer/xsltcPooled,org.apache.cocoon.transformation.Transformer/xsltc,org.apache.cocoon.generation.Generator/<notifier>Pooled,org.apache.cocoon.generation.Generator/<notifier>,org.apache.cocoon.components.modules.input.InputModule/cocoon-properties,org.apache.excalibur.source.SourceFactory/zip,org.apache.cocoon.components.pipeline.ProcessingPipeline/noncachingPooled,org.apache.cocoon.components.pipeline.ProcessingPipeline/noncaching,org.apache.cocoon.components.modules.input.InputModule/session,org.apache.cocoon.generation.Generator/statusPooled,org.apache.cocoon.generation.Generator/status,org.apache.cocoon.generation.Generator/exceptionPooled,or
g.apache.cocoon.generation.Generator/exception,org.apache.excalibur.source.SourceFactory/context,org.apache.cocoon.components.persistence.RequestDataStore,org.apache.cocoon.serialization.Serializer/linksPooled,org.apache.cocoon.serialization.Serializer/links,org.apache.cocoon.acting.Action/form-validator,org.apache.cocoon.serialization.Serializer/sxcPooled,org.apache.cocoon.serialization.Serializer/sxc,org.apache.cocoon.generation.Generator/streamPooled,org.apache.cocoon.generation.Generator/stream,org.apache.excalibur.xml.xslt.XSLTProcessor/xsltcPooled,org.apache.excalibur.xml.xslt.XSLTProcessor/xsltc,org.apache.cocoon.components.modules.input.InputModule/cookie,org.apache.cocoon.reading.Reader/resourcePooled,org.apache.cocoon.reading.Reader/resource,org.apache.cocoon.transformation.Transformer/<translator>Pooled,org.apache.cocoon.transformation.Transformer/<translator>,org.apache.cocoon.components.modules.input.InputModule/request-header,org.apache.cocoon.components.modules
.input.InputModule/realpath,org.apache.cocoon.classloader.ClassLoaderFactory/reloading,org.apache.cocoon.selection.Selector/request-parameter,org.apache.cocoon.generation.Generator/xpathdirectoryPooled,org.apache.cocoon.generation.Generator/xpathdirectory,org.apache.cocoon.components.expression.ExpressionCompiler/js,org.apache.cocoon.acting.Action/clear-persistent-store,org.apache.cocoon.components.modules.input.InputModule/environment-attr,org.apache.cocoon.acting.Action/locale,org.apache.excalibur.source.SourceFactory/resource,org.apache.cocoon.transformation.Transformer/writeDOMsessionPooled,org.apache.cocoon.transformation.Transformer/writeDOMsession,org.apache.excalibur.xml.sax.SAXParserPooled,org.apache.excalibur.xml.sax.SAXParser,org.apache.cocoon.selection.Selector/parameter,org.apache.cocoon.matching.Matcher/header,org.apache.cocoon.components.modules.output.OutputModuleSelector,org.apache.cocoon.components.pipeline.ProcessingPipeline/cachingPooled,org.apache.cocoon.
components.pipeline.ProcessingPipeline/caching,org.apache.cocoon.selection.Selector/simple,org.apache.cocoon.components.modules.input.InputModule/request-attr,org.apache.excalibur.source.SourceFactory/empty,org.apache.excalibur.xml.EntityResolver,org.apache.cocoon.components.expression.ExpressionCompiler/default,org.apache.cocoon.serialization.Serializer/sxiPooled,org.apache.cocoon.serialization.Serializer/sxi,org.apache.cocoon.components.modules.output.OutputModule/request-attr-map,org.apache.cocoon.components.modules.input.InputModule/random,org.apache.cocoon.components.modules.input.InputModule/flow-continuation,org.apache.cocoon.serialization.Serializer/chtmlPooled,org.apache.cocoon.serialization.Serializer/chtml,org.apache.cocoon.acting.Action/req-params,org.apache.cocoon.components.modules.input.InputModule/jxpath,org.apache.cocoon.components.modules.input.InputModule/contextpath,org.apache.cocoon.template.script.InstructionFactory,org.apache.excalibur.source.SourceFact
ory/file,org.apache.excalibur.xmlizer.XMLizer,org.apache.excalibur.source.SourceFactory/upload,org.apache.cocoon.acting.Action/clear-cache,org.apache.cocoon.selection.SelectorSelector,org.apache.excalibur.source.SourceFactory/xmodule,org.apache.cocoon.matching.Matcher/regexp,org.apache.cocoon.components.flow.ContinuationsManager,org.apache.cocoon.components.modules.input.InputModule/baselink,org.apache.cocoon.selection.Selector/browser,org.apache.cocoon.components.modules.input.InputModule/system-property,org.apache.cocoon.serialization.Serializer/vrmlPooled,org.apache.cocoon.serialization.Serializer/vrml,org.apache.cocoon.generation.Generator/virtualPooled,org.apache.cocoon.generation.Generator/virtual,org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo,org.apache.cocoon.core.container.spring.avalon.ConfigurationInfo,org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor]; root of BeanFactory hierarchy
> INFO (2006-11-04) 14:28.06:048 [org.springframework.context.support.ClassPathXmlApplicationContext] 283 beans defined in application context [org.springframework.context.support.ClassPathXmlApplicationContext;hashCode=15532856]
> INFO (2006-11-04) 14:28.06:345 [org.springframework.beans.factory.support.DefaultListableBeanFactory] Destroying singletons in {org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [org.apache.cocoon.configuration.Settings,org.apache.cocoon.core.container.spring.CocoonPropertyOverrideConfigurer,javax.servlet.ServletContext,userDetailsService,filterChainProxy,httpSessionContextIntegrationFilter,basicProcessingFilter,basicProcessingFilterEntryPoint,exceptionTranslationFilter,filterSecurityInterceptor,roleVoter,accessDecisionManager,testingAuthenticationProvider,daoAuthenticationProvider,authenticationManager,org.apache.cocoon.processing.ProcessInfoProvider,investmentDao,partnerDao,regionDao,userDao,investmentService,partnerService,regionService,userService,org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor,dataSource,sessionFactory,baseHibernateDao,transactionManager,org.springframework.aop.config.internalAutoPro
xyCreator,org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor,xmlRequestApple,storeInvestmentApple,investmentParser,org.apache.avalon.framework.context.Context,org.apache.avalon.framework.service.ServiceManager,org.apache.avalon.framework.logger.Logger,org.apache.cocoon.serialization.Serializer/htmlPooled,org.apache.cocoon.serialization.Serializer/html,org.apache.cocoon.acting.Action/session-state,org.apache.cocoon.acting.Action/session-validator,org.apache.cocoon.generation.Generator/directoryPooled,org.apache.cocoon.generation.Generator/directory,org.apache.cocoon.generation.Generator/imagedirectoryPooled,org.apache.cocoon.generation.Generator/imagedirectory,org.apache.cocoon.transformation.Transformer/<gatherer>Pooled,org.apache.cocoon.transformation.Transformer/<gatherer>,org.apache.cocoon.components.flow.Interpreter/service-apples,org.apache.cocoon.components.modules.input.InputModule/request,org.apache.cocoon.components.modules.input.InputModul
e/flow-attribute,org.apache.cocoon.selection.Selector/exception,org.apache.cocoon.reading.ReaderSelector,org.apache.excalibur.store.Store,org.apache.cocoon.acting.Action/set-header,org.apache.cocoon.components.pipeline.ProcessingPipeline/caching-pointPooled,org.apache.cocoon.components.pipeline.ProcessingPipeline/caching-point,org.apache.excalibur.xml.xslt.XSLTProcessorPooled,org.apache.excalibur.xml.xslt.XSLTProcessor,org.apache.excalibur.xml.dom.DOMSerializer,org.apache.cocoon.serialization.Serializer/sxdPooled,org.apache.cocoon.serialization.Serializer/sxd,org.apache.cocoon.selection.Selector/header,org.apache.cocoon.components.modules.input.InputModule/nullinput,org.apache.cocoon.generation.Generator/jxPooled,org.apache.cocoon.generation.Generator/jx,org.apache.cocoon.components.pipeline.ProcessingPipelineSelector,org.apache.cocoon.components.modules.input.InputModule/mapmeta,org.apache.cocoon.classloader.reloading.Monitor,org.apache.cocoon.transformation.Transformer/filt
erPooled,org.apache.cocoon.transformation.Transformer/filter,org.apache.cocoon.components.modules.output.OutputModule/request-attr,org.apache.cocoon.components.flow.InterpreterSelector,org.apache.excalibur.source.SourceResolver,org.apache.excalibur.source.SourceFactory/cocoon,org.apache.cocoon.components.modules.output.OutputModule/session-attr,org.apache.cocoon.transformation.Transformer/cincludePooled,org.apache.cocoon.transformation.Transformer/cinclude,org.apache.cocoon.serialization.Serializer/xmlPooled,org.apache.cocoon.serialization.Serializer/xml,org.apache.cocoon.acting.Action/resource-exists,org.apache.cocoon.matching.Matcher/parameter,org.apache.cocoon.components.modules.input.InputModule/raw-request-param,org.apache.cocoon.template.script.ScriptManager,org.apache.cocoon.serialization.Serializer/xhtml11Pooled,org.apache.cocoon.serialization.Serializer/xhtml11,org.apache.cocoon.matching.Matcher/cookie,org.apache.cocoon.selection.Selector/session-attribute,org.apache
.cocoon.generation.Generator/requestPooled,org.apache.cocoon.generation.Generator/request,org.apache.cocoon.transformation.Transformer/includePooled,org.apache.cocoon.transformation.Transformer/include,org.apache.cocoon.matching.MatcherSelector,org.apache.cocoon.components.expression.ExpressionFactory,org.apache.cocoon.matching.Matcher/locale,org.apache.cocoon.components.flow.Interpreter/javascript,org.apache.excalibur.xml.xpath.XPathProcessor,org.apache.cocoon.selection.Selector/request-attribute,org.apache.cocoon.reading.Reader/imagePooled,org.apache.cocoon.reading.Reader/image,org.apache.cocoon.matching.Matcher/sessionstate,org.apache.cocoon.components.thread.RunnableManager,org.apache.cocoon.generation.GeneratorSelector,org.apache.cocoon.transformation.Transformer/xalanPooled,org.apache.cocoon.transformation.Transformer/xalan,org.apache.cocoon.components.modules.input.InputModule/request-scoped-attr,org.apache.cocoon.components.modules.input.InputModule/url-decode,org.apa
che.cocoon.selection.Selector/resource-exists,org.apache.excalibur.source.SourceFactory/*,org.apache.cocoon.acting.ActionSelector,org.apache.cocoon.components.modules.input.InputModule/global,org.apache.cocoon.classloader.ClassLoaderFactory,org.apache.cocoon.i18n.BundleFactory,org.apache.cocoon.components.notification.NotifyingBuilderPooled,org.apache.cocoon.components.notification.NotifyingBuilder,org.apache.cocoon.serialization.Serializer/xhtmlPooled,org.apache.cocoon.serialization.Serializer/xhtml,org.apache.cocoon.components.modules.input.InputModule/flow-attr,org.apache.cocoon.components.expression.ExpressionCompilerSelector,org.apache.cocoon.components.flow.Interpreter/apples,org.apache.cocoon.transformation.Transformer/write-sourcePooled,org.apache.cocoon.transformation.Transformer/write-source,org.apache.cocoon.components.pipeline.ProcessingPipeline/expiresPooled,org.apache.cocoon.components.pipeline.ProcessingPipeline/expires,org.apache.cocoon.components.modules.inpu
t.InputModule/request-param,org.apache.cocoon.transformation.Transformer/jpathPooled,org.apache.cocoon.transformation.Transformer/jpath,org.apache.cocoon.matching.Matcher/request-parameter,org.apache.cocoon.components.modules.input.InputModule/session-attr,org.apache.excalibur.source.SourceFactorySelector,org.apache.cocoon.components.treeprocessor.TreeBuilder/sitemap-1.0Pooled,org.apache.cocoon.components.treeprocessor.TreeBuilder/sitemap-1.0,org.apache.cocoon.matching.Matcher/referer-match,org.apache.cocoon.serialization.Serializer/zipPooled,org.apache.cocoon.serialization.Serializer/zip,org.apache.cocoon.acting.Action/session-invalidator,org.apache.cocoon.components.modules.input.InputModuleSelector,org.apache.cocoon.transformation.Transformer/paginatePooled,org.apache.cocoon.transformation.Transformer/paginate,org.apache.cocoon.transformation.Transformer/encodeURLPooled,org.apache.cocoon.transformation.Transformer/encodeURL,org.apache.cocoon.transformation.Transformer/read
DOMsessionPooled,org.apache.cocoon.transformation.Transformer/readDOMsession,org.apache.cocoon.components.expression.ExpressionCompiler/jxpath,org.apache.cocoon.components.expression.ExpressionCompiler/jexl,org.apache.cocoon.generation.Generator/<aggregator>Pooled,org.apache.cocoon.generation.Generator/<aggregator>,org.apache.cocoon.transformation.Transformer/xsltPooled,org.apache.cocoon.transformation.Transformer/xslt,org.apache.cocoon.transformation.Transformer/xincludePooled,org.apache.cocoon.transformation.Transformer/xinclude,org.apache.excalibur.xml.dom.DOMParserPooled,org.apache.excalibur.xml.dom.DOMParser,org.apache.cocoon.components.modules.input.InputModule/naming,org.apache.cocoon.template.expression.StringTemplateParser,org.apache.cocoon.serialization.Serializer/textPooled,org.apache.cocoon.serialization.Serializer/text,org.apache.cocoon.components.modules.input.InputModule/chain,org.apache.cocoon.components.modules.input.InputModule/date,org.apache.excalibur.stor
e.StoreJanitor,org.apache.cocoon.transformation.TransformerSelector,org.apache.cocoon.template.expression.StringTemplateParser/jxtg,org.apache.cocoon.generation.Generator/mp3directoryPooled,org.apache.cocoon.generation.Generator/mp3directory,org.apache.cocoon.serialization.Serializer/sxwPooled,org.apache.cocoon.serialization.Serializer/sxw,org.apache.cocoon.components.modules.input.InputModule/xmlmeta,org.apache.cocoon.components.modules.input.InputModule/datemeta,org.apache.cocoon.generation.Generator/filePooled,org.apache.cocoon.generation.Generator/file,org.apache.cocoon.acting.Action/session-isvalid,org.apache.cocoon.transformation.Transformer/jxPooled,org.apache.cocoon.transformation.Transformer/jx,org.apache.cocoon.transformation.helpers.IncludeCacheManager,org.apache.cocoon.serialization.SerializerSelector,org.apache.cocoon.selection.Selector/request-method,org.apache.cocoon.components.modules.input.InputModule/digest,org.apache.cocoon.acting.Action/request,org.apache.
cocoon.components.modules.input.InputModule/url-encode,org.apache.cocoon.selection.Selector/host,org.apache.cocoon.components.modules.input.InputModule/constant,org.apache.cocoon.transformation.Transformer/logPooled,org.apache.cocoon.transformation.Transformer/log,org.apache.excalibur.xml.xslt.XSLTProcessor/xalanPooled,org.apache.excalibur.xml.xslt.XSLTProcessor/xalan,org.apache.excalibur.source.SourceFactory/module,org.apache.cocoon.matching.Matcher/wildcard,org.apache.cocoon.components.modules.input.InputModule/simplemap,org.apache.cocoon.caching.Cache,org.apache.excalibur.store.Store/TransientStore,org.apache.cocoon.template.expression.StringTemplateParser/default,org.apache.cocoon.generation.Generator/notifyingPooled,org.apache.cocoon.generation.Generator/notifying,org.apache.cocoon.matching.Matcher/mount-table,org.apache.cocoon.components.modules.input.InputModule/locate,org.apache.cocoon.Processor,org.apache.cocoon.serialization.Serializer/wmlPooled,org.apache.cocoon.se
rialization.Serializer/wml,org.apache.cocoon.serialization.Serializer/svgxmlPooled,org.apache.cocoon.serialization.Serializer/svgxml,org.apache.cocoon.template.expression.StringTemplateParserSelector,org.apache.cocoon.transformation.Transformer/xsltcPooled,org.apache.cocoon.transformation.Transformer/xsltc,org.apache.cocoon.generation.Generator/<notifier>Pooled,org.apache.cocoon.generation.Generator/<notifier>,org.apache.cocoon.components.modules.input.InputModule/cocoon-properties,org.apache.excalibur.source.SourceFactory/zip,org.apache.cocoon.components.pipeline.ProcessingPipeline/noncachingPooled,org.apache.cocoon.components.pipeline.ProcessingPipeline/noncaching,org.apache.cocoon.components.modules.input.InputModule/session,org.apache.cocoon.generation.Generator/statusPooled,org.apache.cocoon.generation.Generator/status,org.apache.cocoon.generation.Generator/exceptionPooled,org.apache.cocoon.generation.Generator/exception,org.apache.excalibur.source.SourceFactory/context,
org.apache.cocoon.components.persistence.RequestDataStore,org.apache.cocoon.serialization.Serializer/linksPooled,org.apache.cocoon.serialization.Serializer/links,org.apache.cocoon.acting.Action/form-validator,org.apache.cocoon.serialization.Serializer/sxcPooled,org.apache.cocoon.serialization.Serializer/sxc,org.apache.cocoon.generation.Generator/streamPooled,org.apache.cocoon.generation.Generator/stream,org.apache.excalibur.xml.xslt.XSLTProcessor/xsltcPooled,org.apache.excalibur.xml.xslt.XSLTProcessor/xsltc,org.apache.cocoon.components.modules.input.InputModule/cookie,org.apache.cocoon.reading.Reader/resourcePooled,org.apache.cocoon.reading.Reader/resource,org.apache.cocoon.transformation.Transformer/<translator>Pooled,org.apache.cocoon.transformation.Transformer/<translator>,org.apache.cocoon.components.modules.input.InputModule/request-header,org.apache.cocoon.components.modules.input.InputModule/realpath,org.apache.cocoon.classloader.ClassLoaderFactory/reloading,org.apache
.cocoon.selection.Selector/request-parameter,org.apache.cocoon.generation.Generator/xpathdirectoryPooled,org.apache.cocoon.generation.Generator/xpathdirectory,org.apache.cocoon.components.expression.ExpressionCompiler/js,org.apache.cocoon.acting.Action/clear-persistent-store,org.apache.cocoon.components.modules.input.InputModule/environment-attr,org.apache.cocoon.acting.Action/locale,org.apache.excalibur.source.SourceFactory/resource,org.apache.cocoon.transformation.Transformer/writeDOMsessionPooled,org.apache.cocoon.transformation.Transformer/writeDOMsession,org.apache.excalibur.xml.sax.SAXParserPooled,org.apache.excalibur.xml.sax.SAXParser,org.apache.cocoon.selection.Selector/parameter,org.apache.cocoon.matching.Matcher/header,org.apache.cocoon.components.modules.output.OutputModuleSelector,org.apache.cocoon.components.pipeline.ProcessingPipeline/cachingPooled,org.apache.cocoon.components.pipeline.ProcessingPipeline/caching,org.apache.cocoon.selection.Selector/simple,org.ap
ache.cocoon.components.modules.input.InputModule/request-attr,org.apache.excalibur.source.SourceFactory/empty,org.apache.excalibur.xml.EntityResolver,org.apache.cocoon.components.expression.ExpressionCompiler/default,org.apache.cocoon.serialization.Serializer/sxiPooled,org.apache.cocoon.serialization.Serializer/sxi,org.apache.cocoon.components.modules.output.OutputModule/request-attr-map,org.apache.cocoon.components.modules.input.InputModule/random,org.apache.cocoon.components.modules.input.InputModule/flow-continuation,org.apache.cocoon.serialization.Serializer/chtmlPooled,org.apache.cocoon.serialization.Serializer/chtml,org.apache.cocoon.acting.Action/req-params,org.apache.cocoon.components.modules.input.InputModule/jxpath,org.apache.cocoon.components.modules.input.InputModule/contextpath,org.apache.cocoon.template.script.InstructionFactory,org.apache.excalibur.source.SourceFactory/file,org.apache.excalibur.xmlizer.XMLizer,org.apache.excalibur.source.SourceFactory/upload,or
g.apache.cocoon.acting.Action/clear-cache,org.apache.cocoon.selection.SelectorSelector,org.apache.excalibur.source.SourceFactory/xmodule,org.apache.cocoon.matching.Matcher/regexp,org.apache.cocoon.components.flow.ContinuationsManager,org.apache.cocoon.components.modules.input.InputModule/baselink,org.apache.cocoon.selection.Selector/browser,org.apache.cocoon.components.modules.input.InputModule/system-property,org.apache.cocoon.serialization.Serializer/vrmlPooled,org.apache.cocoon.serialization.Serializer/vrml,org.apache.cocoon.generation.Generator/virtualPooled,org.apache.cocoon.generation.Generator/virtual,org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo,org.apache.cocoon.core.container.spring.avalon.ConfigurationInfo,org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor]; root of BeanFactory hierarchy}
> Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.configuration.Settings': Invocation of init method failed; nested exception is java.lang.NullPointerException
> Caused by: java.lang.NullPointerException
> at org.apache.cocoon.core.container.spring.SettingsBeanFactoryPostProcessor.createSettings(SettingsBeanFactoryPostProcessor.java:181)
> at org.apache.cocoon.core.container.spring.SettingsBeanFactoryPostProcessor.init(SettingsBeanFactoryPostProcessor.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1104)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1066)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1029)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:420)
> at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:245)
> at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141)
> at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:242)
> at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:156)
> at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:642)
> at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:405)
> at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:330)
> at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:92)
> at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:77)
> at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:68)
> at com.mobilebox.viessmann.pi.server.Test.main(Test.java:28)
failing at: this.servletContext.log("Apache Cocoon " + Constants.VERSION
+ " is running in mode: " + mode);
So either we mock the servlet context (probably not the best idea) or we
put more attention to making cocoon usable without servlet context.
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>>>> To get things going: how do I get access to current cocoon running mode in:
>>>> - AvalonElementParser
>>>> - SitemapElementParser
>>>>
>>>> in order to pass it to ConfigurationReader?
>>> It seems my knowledge of Spring internals is lacking alot. Reading the
>>> code I would say maybe somthing line
>>>
>>> (Settings)(new RuntimeBeanReference(Settings.ROLE).getSource())
>> probably not, I need to access the bean itself - not the definition
>> metadata. I do not know if that is possible - after all the context
>> containing the settings bean is still in creation.
>>
> It's not possible to get the settings object in the element parser.
> Actually its not possible to access any bean in the parser (and its also
> not possible to get the ServletContext). I had a very hard time figuring
> a way out of this problem. And I came up with the current solution which
> registers special beans which do the work. So the parser only register
> beans, pass some configuration information to the beans, but the actual
> work is done in the beans when they are instantiated by Spring.
You are creating bean definitions in AvalonElementParser and in
AvalonBeanPostProcessor you apply lifecycle to previously defined beans.
The problem is that the actual bean definition/bean creation would have
to be moved to AvalonBeanPostProcessor. This is way beyond my
qualifications :).
Is this at all feasible?
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>> you won't get away that easy :) : block/COB-INF/config/spring/mode is
>> missing.
> :) You mean including per sitemap spring configurations, right?
> I just added some code which should (not tested yet!) pass the current
> running mode into the sitemap parser. Does this help you?
A lot. I will test the feature tomorrow morning. Right now I have
already commited some (not tested yet!) code based on your (not tested
yet!:)) code that should do the trick.
I am little bit scared about:
final String runningMode = this.getAttributeValue(element,
SettingsElementParser.RUNNING_MODE_ATTR,
SettingsDefaults.DEFAULT_RUNNING_MODE);
a similar command already made CocoonOverridePropertyConfigurer include
default mode properties because settings objects was not injected.
As cocoon is always running in some mode at level of
SitemapElementParser that mode should be clearly determined. I therefore
propose to change the code to:
final String runningMode = this.getAttributeValue(element,
SettingsElementParser.RUNNING_MODE_ATTR);
if ( runningMode == null )
throw new IllegalSomethingException( "cocoon mode must not be null
at this point" );
wdyt?
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
>
> you won't get away that easy :) : block/COB-INF/config/spring/mode is
> missing.
:) You mean including per sitemap spring configurations, right?
I just added some code which should (not tested yet!) pass the current
running mode into the sitemap parser. Does this help you?
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote
>>> System.getProperty(RUNNING_MODE_PROEPRTY, RUNNING_MODE_DEFAULT)
>>>
>>> needed in those classes mentioned to get te running mode than?
>> yes.. but I would rather use the Settings.getRunningMode() than to
>> duplicate the logic that establishes running mode. With
>> System.getProperty() we have the feature working in 2 minutes. Question
>> is: will other developers agree to such "unprofessional" solution?
>>
> No :) And what's worse it's not the right approach. Since some weeks we
> have the (yet undocumented) feature that you can also change the running
> mode in the application context with the <cocoon:settings/> element.
> This allows the change of the running mode without the need to use
> system properties!
>
> I think we should not support running modes for avalon based
> configurations - so there is no need to get the settings in the avalon
> element parser :) What is missing then?
you won't get away that easy :) : block/COB-INF/config/spring/mode is
missing.
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carsten Ziegeler wrote:
> Leszek Gawron wrote
>>> System.getProperty(RUNNING_MODE_PROEPRTY, RUNNING_MODE_DEFAULT)
>>>
>>> needed in those classes mentioned to get te running mode than?
>> yes.. but I would rather use the Settings.getRunningMode() than to
>> duplicate the logic that establishes running mode. With
>> System.getProperty() we have the feature working in 2 minutes. Question
>> is: will other developers agree to such "unprofessional" solution?
>>
> No :) And what's worse it's not the right approach. Since some weeks we
> have the (yet undocumented) feature that you can also change the running
> mode in the application context with the <cocoon:settings/> element.
> This allows the change of the running mode without the need to use
> system properties!
>
> I think we should not support running modes for avalon based
> configurations - so there is no need to get the settings in the avalon
> element parser :) What is missing then?
Yes, sorry. I meant only mode for spring configs.
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFThdhLNdJvZjjVZARAndcAJ9BX6wxQ+W5KaBtP/4yxv2GLE7gIQCglLDI
msnSlwZKkHlgZCpRD27C50g=
=dUhj
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote
>>
>> System.getProperty(RUNNING_MODE_PROEPRTY, RUNNING_MODE_DEFAULT)
>>
>> needed in those classes mentioned to get te running mode than?
>
> yes.. but I would rather use the Settings.getRunningMode() than to
> duplicate the logic that establishes running mode. With
> System.getProperty() we have the feature working in 2 minutes. Question
> is: will other developers agree to such "unprofessional" solution?
>
No :) And what's worse it's not the right approach. Since some weeks we
have the (yet undocumented) feature that you can also change the running
mode in the application context with the <cocoon:settings/> element.
This allows the change of the running mode without the need to use
system properties!
I think we should not support running modes for avalon based
configurations - so there is no need to get the settings in the avalon
element parser :) What is missing then?
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
>>> System.getProperty(RUNNING_MODE_PROEPRTY, RUNNING_MODE_DEFAULT)
>>>
>>> needed in those classes mentioned to get te running mode than?
>> yes.. but I would rather use the Settings.getRunningMode() than to
>> duplicate the logic that establishes running mode. With
>> System.getProperty() we have the feature working in 2 minutes. Question
>> is: will other developers agree to such "unprofessional" solution?
>
> Thanks or qualifying my proposal as "unprofessional" :-)
My english sometimes is not as fluent as I would like it to be. It was
not my intention to criticize your proposal. I apologise if you feel
insulted.
> I you cannot get a Setting object you only have the System.getProperty choice.
System.getProperty is not an option as Carsten has introduced some other
ways of setting running mode that have nothing to do with system
properties. So we are on his mercy now to propose something :)
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> Giacomo Pati wrote:
>>>> System.getProperty(RUNNING_MODE_PROEPRTY, RUNNING_MODE_DEFAULT)
>>>>
>>>> needed in those classes mentioned to get te running mode than?
>>> yes.. but I would rather use the Settings.getRunningMode() than to
>>> duplicate the logic that establishes running mode. With
>>> System.getProperty() we have the feature working in 2 minutes. Question
>>> is: will other developers agree to such "unprofessional" solution?
>>
>> Thanks or qualifying my proposal as "unprofessional" :-)
>
> My english sometimes is not as fluent as I would like it to be. It was
> not my intention to criticize your proposal. I apologise if you felt
> insulted.
Don't worry.
1) eMails are so unemotional to me
2) I'm an old far thus unshakable :-)
>> I you cannot get a Setting object you only have the System.getProperty
>> choice.
>
> System.getProperty is not an option as Carsten has introduced some other
I've seen his mail later on
> ways of setting running mode that have nothing to do with system
> properties. So we are on his mercy now to propose something :)
beleave me we both sit in the same boat wrt Carsten (hint!)
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFTi66LNdJvZjjVZARAq4CAJ4n8DrQFQ08427vSWi+rYI/N0vrqACg3muC
0zNejkU+buGWHEr/uO6ARwE=
=nfFI
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
>>> System.getProperty(RUNNING_MODE_PROEPRTY, RUNNING_MODE_DEFAULT)
>>>
>>> needed in those classes mentioned to get te running mode than?
>> yes.. but I would rather use the Settings.getRunningMode() than to
>> duplicate the logic that establishes running mode. With
>> System.getProperty() we have the feature working in 2 minutes. Question
>> is: will other developers agree to such "unprofessional" solution?
>
> Thanks or qualifying my proposal as "unprofessional" :-)
My english sometimes is not as fluent as I would like it to be. It was
not my intention to criticize your proposal. I apologise if you felt
insulted.
> I you cannot get a Setting object you only have the System.getProperty choice.
System.getProperty is not an option as Carsten has introduced some other
ways of setting running mode that have nothing to do with system
properties. So we are on his mercy now to propose something :)
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> Giacomo Pati wrote:
>>
>> Carsten Ziegeler wrote:
>>> Leszek Gawron wrote:
>>>>>> To get things going: how do I get access to current cocoon running
>>>>>> mode in:
>>>>>> - AvalonElementParser
>>>>>> - SitemapElementParser
>>>>>>
>>>>>> in order to pass it to ConfigurationReader?
>>>>> It seems my knowledge of Spring internals is lacking alot. Reading the
>>>>> code I would say maybe somthing line
>>>>>
>>>>> (Settings)(new RuntimeBeanReference(Settings.ROLE).getSource())
>>>> probably not, I need to access the bean itself - not the definition
>>>> metadata. I do not know if that is possible - after all the context
>>>> containing the settings bean is still in creation.
>>>>
>>> It's not possible to get the settings object in the element parser.
>>> Actually its not possible to access any bean in the parser (and its also
>>> not possible to get the ServletContext). I had a very hard time figuring
>>> a way out of this problem. And I came up with the current solution which
>>> registers special beans which do the work. So the parser only register
>>> beans, pass some configuration information to the beans, but the actual
>>> work is done in the beans when they are instantiated by Spring.
>>
>> To go back to Leszeks initial question, so there is a
>>
>> System.getProperty(RUNNING_MODE_PROEPRTY, RUNNING_MODE_DEFAULT)
>>
>> needed in those classes mentioned to get te running mode than?
>
> yes.. but I would rather use the Settings.getRunningMode() than to
> duplicate the logic that establishes running mode. With
> System.getProperty() we have the feature working in 2 minutes. Question
> is: will other developers agree to such "unprofessional" solution?
Thanks or qualifying my proposal as "unprofessional" :-)
I you cannot get a Setting object you only have the System.getProperty choice.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFThcALNdJvZjjVZARAlMjAKCDtHLp+v0pRZPZgckCX48lgEPTFgCfSzuu
Kx5LNejJNaQcPPZKG6GhlUg=
=NfMk
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
>
> Carsten Ziegeler wrote:
>> Leszek Gawron wrote:
>>>>> To get things going: how do I get access to current cocoon running mode in:
>>>>> - AvalonElementParser
>>>>> - SitemapElementParser
>>>>>
>>>>> in order to pass it to ConfigurationReader?
>>>> It seems my knowledge of Spring internals is lacking alot. Reading the
>>>> code I would say maybe somthing line
>>>>
>>>> (Settings)(new RuntimeBeanReference(Settings.ROLE).getSource())
>>> probably not, I need to access the bean itself - not the definition
>>> metadata. I do not know if that is possible - after all the context
>>> containing the settings bean is still in creation.
>>>
>> It's not possible to get the settings object in the element parser.
>> Actually its not possible to access any bean in the parser (and its also
>> not possible to get the ServletContext). I had a very hard time figuring
>> a way out of this problem. And I came up with the current solution which
>> registers special beans which do the work. So the parser only register
>> beans, pass some configuration information to the beans, but the actual
>> work is done in the beans when they are instantiated by Spring.
>
> To go back to Leszeks initial question, so there is a
>
> System.getProperty(RUNNING_MODE_PROEPRTY, RUNNING_MODE_DEFAULT)
>
> needed in those classes mentioned to get te running mode than?
yes.. but I would rather use the Settings.getRunningMode() than to
duplicate the logic that establishes running mode. With
System.getProperty() we have the feature working in 2 minutes. Question
is: will other developers agree to such "unprofessional" solution?
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>>>> To get things going: how do I get access to current cocoon running mode in:
>>>> - AvalonElementParser
>>>> - SitemapElementParser
>>>>
>>>> in order to pass it to ConfigurationReader?
>>> It seems my knowledge of Spring internals is lacking alot. Reading the
>>> code I would say maybe somthing line
>>>
>>> (Settings)(new RuntimeBeanReference(Settings.ROLE).getSource())
>> probably not, I need to access the bean itself - not the definition
>> metadata. I do not know if that is possible - after all the context
>> containing the settings bean is still in creation.
>>
> It's not possible to get the settings object in the element parser.
> Actually its not possible to access any bean in the parser (and its also
> not possible to get the ServletContext). I had a very hard time figuring
> a way out of this problem. And I came up with the current solution which
> registers special beans which do the work. So the parser only register
> beans, pass some configuration information to the beans, but the actual
> work is done in the beans when they are instantiated by Spring.
To go back to Leszeks initial question, so there is a
System.getProperty(RUNNING_MODE_PROEPRTY, RUNNING_MODE_DEFAULT)
needed in those classes mentioned to get te running mode than?
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
>>> To get things going: how do I get access to current cocoon running mode in:
>>> - AvalonElementParser
>>> - SitemapElementParser
>>>
>>> in order to pass it to ConfigurationReader?
>> It seems my knowledge of Spring internals is lacking alot. Reading the
>> code I would say maybe somthing line
>>
>> (Settings)(new RuntimeBeanReference(Settings.ROLE).getSource())
>
> probably not, I need to access the bean itself - not the definition
> metadata. I do not know if that is possible - after all the context
> containing the settings bean is still in creation.
>
It's not possible to get the settings object in the element parser.
Actually its not possible to access any bean in the parser (and its also
not possible to get the ServletContext). I had a very hard time figuring
a way out of this problem. And I came up with the current solution which
registers special beans which do the work. So the parser only register
beans, pass some configuration information to the beans, but the actual
work is done in the beans when they are instantiated by Spring.
HTH
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Leszek Gawron wrote:
>> Leszek Gawron wrote:
>>>> Yup,that was me. Before one could do that which has been handy together
>>>> with different modes:
>>> OK, lets enable cocoon modes for META-INF/cocoon/spring/ and
>>> META-INF/cocoon/avalon
>> To get things going: how do I get access to current cocoon running mode in:
>> - AvalonElementParser
>> - SitemapElementParser
>>
>> in order to pass it to ConfigurationReader?
>
> It seems my knowledge of Spring internals is lacking alot. Reading the
> code I would say maybe somthing line
>
> (Settings)(new RuntimeBeanReference(Settings.ROLE).getSource())
probably not, I need to access the bean itself - not the definition
metadata. I do not know if that is possible - after all the context
containing the settings bean is still in creation.
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> Leszek Gawron wrote:
>>> Yup,that was me. Before one could do that which has been handy together
>>> with different modes:
>> OK, lets enable cocoon modes for META-INF/cocoon/spring/ and
>> META-INF/cocoon/avalon
>
> To get things going: how do I get access to current cocoon running mode in:
> - AvalonElementParser
> - SitemapElementParser
>
> in order to pass it to ConfigurationReader?
It seems my knowledge of Spring internals is lacking alot. Reading the
code I would say maybe somthing line
(Settings)(new RuntimeBeanReference(Settings.ROLE).getSource())
??
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFTKlxLNdJvZjjVZARAqtsAKDawlVW6CJ6YIJDbHNuro8geJMr0QCg7BVr
HF3vgDlGwW7HGSgKunHRpiQ=
=+riY
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
>> Yup,that was me. Before one could do that which has been handy together
>> with different modes:
> OK, lets enable cocoon modes for META-INF/cocoon/spring/ and
> META-INF/cocoon/avalon
To get things going: how do I get access to current cocoon running mode in:
- AvalonElementParser
- SitemapElementParser
in order to pass it to ConfigurationReader?
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
>
> Leszek Gawron wrote:
>> Giacomo Pati wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>>
>>> Leszek Gawron wrote:
>>>> Giacomo Pati wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>>
>>>>>
>>>>> Carsten Ziegeler wrote:
>>>>>> Leszek Gawron wrote
>>>>>>> I doubt that is possible in spring. Probably the class of bean
>>>>>>> definition must be known even before BeanFactoryPostProcessors apply.
>>>>>> Yes, it's not possible this way. Spring reads in the configuration,
>>>>>> creates the
>>>>>> bean definition object, does some class checking on the beans (for
>>>>>> example if the bean implements some bean processing interfaces) and
>>>>>> then
>>>>>> applies the properties.
>>>>>>
>>>>>> Our own version we had before was reading in the XML itself and
>>>>>> applying
>>>>>> the properties during reading the XML. So if we would need the same
>>>>>> behaviour again we have to give our own XML reader/parser to Spring
>>>>>> (which might be possible).
>>>>> No need for anymore. Leszek showed me the way to do what I wanted.
>>>> This currently works if you place files in
>>>> classpath:/META-INF/cocoon/spring and
>>>> classpath:/META-INF/cocoon/spring/mode
>>> Sure.
>>>
>>>> it's a little bit too complicated for me to make this for for
>>>> block/config/spring and block/config/spring/mode
>>> Wa's this? dDo we have a config directory somewhere as well?????
>> When you put spring context into classpath:/META-INF/cocoon/spring you
>> actually contribute spring beans directly to core. They are in the same
>> context as cocoon internals.
>>
>> If you want some beans to be sitemap specific put your spring context
>> files into block/COB-INF/config/spring (analogous for properties
>> block/COB-INF/config/properties). The context files residing there will
>> create a separate child spring context.
>>
>> Same goes for legacy components: block/COB-INF/config/avalon (instead of
>> declaring them in sitemap.xmap/map:sitemap/map:components)
>
> Hmm.. I think someone knowledgeable need to write all those directory
> possibilities down somewhere if it is not already.
>
> Are those config/{avalon,spring} directories {mode} aware as well?
no not yet. We need to come up with the solution we are discussing in
other thread (System.getProperty() vs Settings.getRunningMode())
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
Leszek Gawron wrote:
> Giacomo Pati wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Leszek Gawron wrote:
>>> Giacomo Pati wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>>
>>>>
>>>> Carsten Ziegeler wrote:
>>>>> Leszek Gawron wrote
>>>>>> I doubt that is possible in spring. Probably the class of bean
>>>>>> definition must be known even before BeanFactoryPostProcessors apply.
>>>>> Yes, it's not possible this way. Spring reads in the configuration,
>>>>> creates the
>>>>> bean definition object, does some class checking on the beans (for
>>>>> example if the bean implements some bean processing interfaces) and
>>>>> then
>>>>> applies the properties.
>>>>>
>>>>> Our own version we had before was reading in the XML itself and
>>>>> applying
>>>>> the properties during reading the XML. So if we would need the same
>>>>> behaviour again we have to give our own XML reader/parser to Spring
>>>>> (which might be possible).
>>>> No need for anymore. Leszek showed me the way to do what I wanted.
>>> This currently works if you place files in
>>> classpath:/META-INF/cocoon/spring and
>>> classpath:/META-INF/cocoon/spring/mode
>>
>> Sure.
>>
>>> it's a little bit too complicated for me to make this for for
>>> block/config/spring and block/config/spring/mode
>>
>> Wa's this? dDo we have a config directory somewhere as well?????
>
> When you put spring context into classpath:/META-INF/cocoon/spring you
> actually contribute spring beans directly to core. They are in the same
> context as cocoon internals.
>
> If you want some beans to be sitemap specific put your spring context
> files into block/COB-INF/config/spring (analogous for properties
> block/COB-INF/config/properties). The context files residing there will
> create a separate child spring context.
>
> Same goes for legacy components: block/COB-INF/config/avalon (instead of
> declaring them in sitemap.xmap/map:sitemap/map:components)
Hmm.. I think someone knowledgeable need to write all those directory
possibilities down somewhere if it is not already.
Are those config/{avalon,spring} directories {mode} aware as well?
Ciao
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Leszek Gawron wrote:
>> Giacomo Pati wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>>
>>> Carsten Ziegeler wrote:
>>>> Leszek Gawron wrote
>>>>> I doubt that is possible in spring. Probably the class of bean
>>>>> definition must be known even before BeanFactoryPostProcessors apply.
>>>> Yes, it's not possible this way. Spring reads in the configuration,
>>>> creates the
>>>> bean definition object, does some class checking on the beans (for
>>>> example if the bean implements some bean processing interfaces) and then
>>>> applies the properties.
>>>>
>>>> Our own version we had before was reading in the XML itself and applying
>>>> the properties during reading the XML. So if we would need the same
>>>> behaviour again we have to give our own XML reader/parser to Spring
>>>> (which might be possible).
>>> No need for anymore. Leszek showed me the way to do what I wanted.
>> This currently works if you place files in
>> classpath:/META-INF/cocoon/spring and
>> classpath:/META-INF/cocoon/spring/mode
>
> Sure.
>
>> it's a little bit too complicated for me to make this for for
>> block/config/spring and block/config/spring/mode
>
> Wa's this? dDo we have a config directory somewhere as well?????
When you put spring context into classpath:/META-INF/cocoon/spring you
actually contribute spring beans directly to core. They are in the same
context as cocoon internals.
If you want some beans to be sitemap specific put your spring context
files into block/COB-INF/config/spring (analogous for properties
block/COB-INF/config/properties). The context files residing there will
create a separate child spring context.
Same goes for legacy components: block/COB-INF/config/avalon (instead of
declaring them in sitemap.xmap/map:sitemap/map:components)
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> Giacomo Pati wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Carsten Ziegeler wrote:
>>> Leszek Gawron wrote
>>>> I doubt that is possible in spring. Probably the class of bean
>>>> definition must be known even before BeanFactoryPostProcessors apply.
>>> Yes, it's not possible this way. Spring reads in the configuration,
>>> creates the
>>> bean definition object, does some class checking on the beans (for
>>> example if the bean implements some bean processing interfaces) and then
>>> applies the properties.
>>>
>>> Our own version we had before was reading in the XML itself and applying
>>> the properties during reading the XML. So if we would need the same
>>> behaviour again we have to give our own XML reader/parser to Spring
>>> (which might be possible).
>>
>> No need for anymore. Leszek showed me the way to do what I wanted.
>
> This currently works if you place files in
> classpath:/META-INF/cocoon/spring and
> classpath:/META-INF/cocoon/spring/mode
Sure.
> it's a little bit too complicated for me to make this for for
> block/config/spring and block/config/spring/mode
Wa's this? dDo we have a config directory somewhere as well?????
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFTeUiLNdJvZjjVZARAi3ZAKDGG5wf+cQKg07PpDoWZq+ApsHFUwCgvXg+
wGRs5CZi6bu5ahfQAt+xbE4=
=sGe1
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Carsten Ziegeler wrote:
>> Leszek Gawron wrote
>>> I doubt that is possible in spring. Probably the class of bean
>>> definition must be known even before BeanFactoryPostProcessors apply.
>> Yes, it's not possible this way. Spring reads in the configuration,
>> creates the
>> bean definition object, does some class checking on the beans (for
>> example if the bean implements some bean processing interfaces) and then
>> applies the properties.
>>
>> Our own version we had before was reading in the XML itself and applying
>> the properties during reading the XML. So if we would need the same
>> behaviour again we have to give our own XML reader/parser to Spring
>> (which might be possible).
>
> No need for anymore. Leszek showed me the way to do what I wanted.
This currently works if you place files in
classpath:/META-INF/cocoon/spring and classpath:/META-INF/cocoon/spring/mode
it's a little bit too complicated for me to make this for for
block/config/spring and block/config/spring/mode
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carsten Ziegeler wrote:
> Leszek Gawron wrote
>> I doubt that is possible in spring. Probably the class of bean
>> definition must be known even before BeanFactoryPostProcessors apply.
> Yes, it's not possible this way. Spring reads in the configuration,
> creates the
> bean definition object, does some class checking on the beans (for
> example if the bean implements some bean processing interfaces) and then
> applies the properties.
>
> Our own version we had before was reading in the XML itself and applying
> the properties during reading the XML. So if we would need the same
> behaviour again we have to give our own XML reader/parser to Spring
> (which might be possible).
No need for anymore. Leszek showed me the way to do what I wanted.
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFTSDcLNdJvZjjVZARAk8FAJ9utBkqtGcR0Ycp+NKuTEVZI0+s5wCdF3UZ
RBAmdtT2oiJbX5EJbGmmb8U=
=ygmW
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote
>
> I doubt that is possible in spring. Probably the class of bean
> definition must be known even before BeanFactoryPostProcessors apply.
Yes, it's not possible this way. Spring reads in the configuration,
creates the
bean definition object, does some class checking on the beans (for
example if the bean implements some bean processing interfaces) and then
applies the properties.
Our own version we had before was reading in the XML itself and applying
the properties during reading the XML. So if we would need the same
behaviour again we have to give our own XML reader/parser to Spring
(which might be possible).
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Leszek Gawron wrote:
>> Giacomo Pati wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>>
>>> Leszek Gawron wrote:
>>>> Carsten Ziegeler wrote:
>>>>> Giacomo Pati wrote:
>>>>>> Just to clear things:
>>>>> :)
>>>>>
>>>>>> Carsten Ziegeler wrote:
>>>>>>>> Done - with the additional change discussed recently, so now we
>>>>>>>> have:
>>>>>>>>
>>>>>>>>>>> META-INF/cocoon/avalon/**
>>>>>>>>>>> META-INF/cocoon/spring/**
>>>>>> plus ev. mode subdir {dev,test,proc}
>>>>>>
>>>>> Yes, but only for the properties! It's simple to add this for reading
>>>>> avalon and spring configurations, if desired?!?
>>>> I heard somewhere on the list that some developers (Giacomo?) where
>>>> using property placeholders for defining mock beans.
>>> Yup,that was me. Before one could do that which has been handy together
>>> with different modes:
>> OK, lets enable cocoon modes for META-INF/cocoon/spring/ and
>> META-INF/cocoon/avalon
>
> I thought modes are already enabled but it's not about mode, its about
> the ability to use properties replacement in
>
> <bean class="${...}">
>
> elements which since Carsten switched to Springs PropertyReplacer is not
> possible anymore (our own implementation of property replacement was
> able to do it).
I doubt that is possible in spring. Probably the class of bean
definition must be known even before BeanFactoryPostProcessors apply.
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Felix Knecht <fe...@otego.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks for your hints. Now it works :-)
> For now you have to stop using 'org.apache.cocoon.mode' system
> property. Rather in webapp/WEB-INF/applicationContext.xml use the
> following line:
>
> <cocoon:settings runningMode="dev"/>
>
> (the default is <cocoon:settings/>)
>
> This needs fixing asap (one should not have to modify webapp
> sources to change running mode).
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFTxIP2lZVCB08qHERAgXaAKCIfecGNITsCqu3CyOmywwqeyT72wCfQms7
SCbV9HikWAiH9h7pF2o9SI8=
=C6r/
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Felix Knecht wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Giacomo Pati schrieb:
>>
>> Leszek Gawron wrote:
>>> with cocoon modes enabled for spring you can do something like
>>> this:
> I always get the error:
> Embedded error: Cannot invoke listener
> org.springframework.web.context.ContextLoaderListener@ef2e7c
> No bean named 'myDao' is defined
>
> Putting the 'myDao' bean definition into the myContext.xml it works.
> Maybe I need to enable cocoon modes for spring, but
> where do I enable cocoon modes for spring?
For now you have to stop using 'org.apache.cocoon.mode' system property.
Rather in webapp/WEB-INF/applicationContext.xml use the following line:
<cocoon:settings runningMode="dev"/>
(the default is <cocoon:settings/>)
This needs fixing asap (one should not have to modify webapp sources to
change running mode).
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
>
> 2. Some components (like CocoonOverridePropertyConfigurer, which has
> already been fixed) use the Settings object but happily fallback to
> default mode when settings object is not available. The result of such
> situation is that a bean that has been incorrectly dependence injected
> uses other running mode than you might think. Beans using running mode
> should simply throw if they cannot determine one.
>
> I am probably picky about this but hey - you're the ones I've learnt my
> values from :)
>
:) Actually I'm not sure - now, the reason why I wrote the code like
this is for unit testing. You can write a unit test for the configurer
which does not need to setup any dependency.
But the more I think about it, the more I agree with you: we should
raise an exception when the settings object is not set rather than
falling back to some default value. This comes with the cost to setup a
settings object (or a mock) for testing, but makes the code safer.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carsten Ziegeler wrote:
> Giacomo Pati wrote:
>>>> 1. IMO cocoon components should either use Settings.getRunningMode() to
>>>> get the current running mode or have the mode injected. Allowing
>>>> components to determine the running mode using any algorithm (even the
>>>> easiest one) leads to inconsistencies.
>> I do absolutely agree with you.
> Exactly.
>
>>>> 2. Some components (like CocoonOverridePropertyConfigurer, which has
>>>> already been fixed) use the Settings object but happily fallback to
>>>> default mode when settings object is not available. The result of such
>>>> situation is that a bean that has been incorrectly dependence injected
>>>> uses other running mode than you might think. Beans using running mode.
>>>> should simply throw if they cannot determine one.
>> As Carsten pointed out in a recent mail, we do not have the "original
>> working code" yet in the repo (dunno where it has been gone, nor which
>> ever class he had in mind as "original working code"). Maybe we should
>> just restore it and see whether that fix our problems
> Yes, let's please restore the old code in the settings element parser; I
> think that's all we need.
Well, actually I'm lost wrt what the "original code" was. I've diffed some
of the latest revisions but couldn't figure out what could have been the
"original code". Can someone help me out (Carsten, Leszek) as I'm rather
near to have it going again (wrt jetty6:run in a block).
>
>>>> I am probably picky about this but hey - you're the ones I've learnt my
>>>> values from :)
> Carsten
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFUEliLNdJvZjjVZARAvOxAJ4xYjW0O0r0XmEb0sxguJuc8+ZalQCfXowR
TBM2dVILYEDp0MWa+hsx7nQ=
=CkyU
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Giacomo Pati wrote:
>>>> 1. IMO cocoon components should either use Settings.getRunningMode() to
>>>> get the current running mode or have the mode injected. Allowing
>>>> components to determine the running mode using any algorithm (even the
>>>> easiest one) leads to inconsistencies.
>> I do absolutely agree with you.
> Exactly.
>
>>>> 2. Some components (like CocoonOverridePropertyConfigurer, which has
>>>> already been fixed) use the Settings object but happily fallback to
>>>> default mode when settings object is not available. The result of such
>>>> situation is that a bean that has been incorrectly dependence injected
>>>> uses other running mode than you might think. Beans using running mode.
>>>> should simply throw if they cannot determine one.
>> As Carsten pointed out in a recent mail, we do not have the "original
>> working code" yet in the repo (dunno where it has been gone, nor which
>> ever class he had in mind as "original working code"). Maybe we should
>> just restore it and see whether that fix our problems
> Yes, let's please restore the old code in the settings element parser; I
> think that's all we need.
which is?
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote:
>>> 1. IMO cocoon components should either use Settings.getRunningMode() to
>>> get the current running mode or have the mode injected. Allowing
>>> components to determine the running mode using any algorithm (even the
>>> easiest one) leads to inconsistencies.
>
> I do absolutely agree with you.
Exactly.
>
>>> 2. Some components (like CocoonOverridePropertyConfigurer, which has
>>> already been fixed) use the Settings object but happily fallback to
>>> default mode when settings object is not available. The result of such
>>> situation is that a bean that has been incorrectly dependence injected
>>> uses other running mode than you might think. Beans using running mode.
>>> should simply throw if they cannot determine one.
>
> As Carsten pointed out in a recent mail, we do not have the "original
> working code" yet in the repo (dunno where it has been gone, nor which
> ever class he had in mind as "original working code"). Maybe we should
> just restore it and see whether that fix our problems
Yes, let's please restore the old code in the settings element parser; I
think that's all we need.
>
>>> I am probably picky about this but hey - you're the ones I've learnt my
>>> values from :)
>
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> Giacomo Pati wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Carsten Ziegeler wrote:
>>> Leszek Gawron wrote:
>>>> Carsten Ziegeler wrote:
>>>>> Sorry, I got totally lost in all these mails. As far as I
>>>>> understand we
>>>>> are currently discussing when/where it's possible to set the
>>>>> running mode.
>>>>> There are two places: applicationContext.xml and system property. The
>>>>> system property takes precedence over the applicationContext.xml. I'm
>>>>> not sure which role cocoon.xconf should play in this?
>>>> I think everyone means applicationContext.xml. I happend to put the
>>>> wrong name in the first place.
>>>>
>>> :) OK, fine, so is there still a problem?
>>
>> Actually, yes, the problem is still there. If I understand Leszek
>> correctly, we do have to places in code where we examine the running
>> mode with the same algorithm.
>
> I actually have two problems:
>
> 1. IMO cocoon components should either use Settings.getRunningMode() to
> get the current running mode or have the mode injected. Allowing
> components to determine the running mode using any algorithm (even the
> easiest one) leads to inconsistencies.
I do absolutely agree with you.
> 2. Some components (like CocoonOverridePropertyConfigurer, which has
> already been fixed) use the Settings object but happily fallback to
> default mode when settings object is not available. The result of such
> situation is that a bean that has been incorrectly dependence injected
> uses other running mode than you might think. Beans using running mode.
> should simply throw if they cannot determine one.
As Carsten pointed out in a recent mail, we do not have the "original
working code" yet in the repo (dunno where it has been gone, nor which
ever class he had in mind as "original working code"). Maybe we should
just restore it and see whether that fix our problems
> I am probably picky about this but hey - you're the ones I've learnt my
> values from :)
Sure, it's easy to have someone to blame for it ;-)
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD4DBQFFT5vOLNdJvZjjVZARApFSAJUWHDjGtaxdiTWATKdplOp2vy99AJsEwPYV
LNMscahUH0/+UUGFtpWiTA==
=NIFB
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Carsten Ziegeler wrote:
>> Leszek Gawron wrote:
>>> Carsten Ziegeler wrote:
>>>> Sorry, I got totally lost in all these mails. As far as I understand we
>>>> are currently discussing when/where it's possible to set the running mode.
>>>> There are two places: applicationContext.xml and system property. The
>>>> system property takes precedence over the applicationContext.xml. I'm
>>>> not sure which role cocoon.xconf should play in this?
>>> I think everyone means applicationContext.xml. I happend to put the
>>> wrong name in the first place.
>>>
>> :) OK, fine, so is there still a problem?
>
> Actually, yes, the problem is still there. If I understand Leszek
> correctly, we do have to places in code where we examine the running
> mode with the same algorithm.
I actually have two problems:
1. IMO cocoon components should either use Settings.getRunningMode() to
get the current running mode or have the mode injected. Allowing
components to determine the running mode using any algorithm (even the
easiest one) leads to inconsistencies.
2. Some components (like CocoonOverridePropertyConfigurer, which has
already been fixed) use the Settings object but happily fallback to
default mode when settings object is not available. The result of such
situation is that a bean that has been incorrectly dependence injected
uses other running mode than you might think. Beans using running mode
should simply throw if they cannot determine one.
I am probably picky about this but hey - you're the ones I've learnt my
values from :)
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>> Carsten Ziegeler wrote:
>>> Sorry, I got totally lost in all these mails. As far as I understand we
>>> are currently discussing when/where it's possible to set the running mode.
>>> There are two places: applicationContext.xml and system property. The
>>> system property takes precedence over the applicationContext.xml. I'm
>>> not sure which role cocoon.xconf should play in this?
>> I think everyone means applicationContext.xml. I happend to put the
>> wrong name in the first place.
>>
> :) OK, fine, so is there still a problem?
Actually, yes, the problem is still there. If I understand Leszek
correctly, we do have to places in code where we examine the running
mode with the same algorithm.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFT5OdLNdJvZjjVZARAgCkAKDX8k1FFOiO2ZjtuNFekrBIDRWh9QCguVfw
eOEtx96npsJBZL6sUXULhiY=
=8mPY
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Felix Knecht <fe...@otego.com>.
Carsten Ziegeler schrieb:
> Felix Knecht wrote:
>> The problem:
>>
>> As far as I've seen, sitemap element parser as well as settings element
>> parser do not respect CLI property settings ( -Dorg.apache.cocoon.mode=xxx).
>>
>> The duplication:
>> With my supposed patch the functions getSystemProperty(String key) and
>> getSystemProperty(String key, String defaultValue) are implemented
>> several times at different locations (I think to remember alsways as
>> protected).
>>
> Ok, I briefly looked at the current code (I have not looked at your
> patch yet). The current code is not the original (working) code. The old
> version did check the system property and the optional runningMode
> attribute of the cocoon:settings element in the applicationContext,
> both, in the settings element parser. And this was the only place where
> this checking occured.
> The sitemap element parser *always* gets the running mode set by the
> attribute runningMode. This is ensured by the SitemapHelper class which
> creates an in memory spring configuration containing the sitemap element.
> Apart from these two places, there shouldn't be any need to directly
> detect the running mode. All places should have access to the Settings
> bean which provides a method to get the current running mode.
>
> Did I oversee any location?
In settings element parser you get 'null' as runningMode when {mode} is
only a CLI parameter. So the bean include handle is not done correctly done
<snip>
// handle includes
try {
this.handleBeanInclude(parserContext, null,
Constants.DEFAULT_SPRING_CONFIGURATION_LOCATION, "*.xml", true);
this.handleBeanInclude(parserContext, null,
Constants.DEFAULT_SPRING_CONFIGURATION_LOCATION + "/" + runningMode,
"*.xml", true);
</snip>
Felix
>
> Carsten
>
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
>> The sitemap element parser *always* gets the running mode set by the
>> attribute runningMode. This is ensured by the SitemapHelper class which
>> creates an in memory spring configuration containing the sitemap element.
>
> Can I ask why this particular technique (I mean creating a string with
> xml to pass it to application context constructor)?
>
Sure :) I wanted to create the per sitemap spring application context in
the same way as the global application context, using the same code and
the same techniques. As the context needs an initial configuration file
containing our special elements, the easiest way to achieve this is to
construct the XML in memory as a string and pass this into the
application context as the configuration. It's not the most elegant way,
so I'm open for any improvement, but as the XML is not too big, I think
it's not the worst option. Anyway, creating this XML allows to use most
of the code we already had, with some minor adaptions.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Felix Knecht wrote:
>> The problem:
>>
>> As far as I've seen, sitemap element parser as well as settings element
>> parser do not respect CLI property settings ( -Dorg.apache.cocoon.mode=xxx).
>>
>> The duplication:
>> With my supposed patch the functions getSystemProperty(String key) and
>> getSystemProperty(String key, String defaultValue) are implemented
>> several times at different locations (I think to remember alsways as
>> protected).
>>
> Ok, I briefly looked at the current code (I have not looked at your
> patch yet). The current code is not the original (working) code. The old
> version did check the system property and the optional runningMode
> attribute of the cocoon:settings element in the applicationContext,
> both, in the settings element parser. And this was the only place where
> this checking occured.
> The sitemap element parser *always* gets the running mode set by the
> attribute runningMode. This is ensured by the SitemapHelper class which
> creates an in memory spring configuration containing the sitemap element.
Can I ask why this particular technique (I mean creating a string with
xml to pass it to application context constructor)?
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Knecht wrote:
>
> The problem:
>
> As far as I've seen, sitemap element parser as well as settings element
> parser do not respect CLI property settings ( -Dorg.apache.cocoon.mode=xxx).
>
> The duplication:
> With my supposed patch the functions getSystemProperty(String key) and
> getSystemProperty(String key, String defaultValue) are implemented
> several times at different locations (I think to remember alsways as
> protected).
>
Ok, I briefly looked at the current code (I have not looked at your
patch yet). The current code is not the original (working) code. The old
version did check the system property and the optional runningMode
attribute of the cocoon:settings element in the applicationContext,
both, in the settings element parser. And this was the only place where
this checking occured.
The sitemap element parser *always* gets the running mode set by the
attribute runningMode. This is ensured by the SitemapHelper class which
creates an in memory spring configuration containing the sitemap element.
Apart from these two places, there shouldn't be any need to directly
detect the running mode. All places should have access to the Settings
bean which provides a method to get the current running mode.
Did I oversee any location?
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Felix Knecht <fe...@otego.com>.
>>>>> Sorry, I got totally lost in all these mails. As far as I understand we
>>>>> are currently discussing when/where it's possible to set the running mode.
>>>>> There are two places: applicationContext.xml and system property. The
>>>>> system property takes precedence over the applicationContext.xml. I'm
>>>>> not sure which role cocoon.xconf should play in this?
>>>> I think everyone means applicationContext.xml. I happend to put the
>>>> wrong name in the first place.
>>>>
>>> :) OK, fine, so is there still a problem?
>> As I've written in some post before: if noone objects that the actual
>> logic of getting current running mode is duplicated here and there I
>> have no problem also.
>>
>> I'll apply the patch today.
>>
> Sorry to ask again - there where too many responses for me in this
> thread, so can you please give me an update on why the duplication is
> necessary?
> As far as I see it, the settings object should be available in all
> places or we can pass in the running mode from the outside, like we did
> with the sitemap element parser.
The problem:
As far as I've seen, sitemap element parser as well as settings element
parser do not respect CLI property settings ( -Dorg.apache.cocoon.mode=xxx).
The duplication:
With my supposed patch the functions getSystemProperty(String key) and
getSystemProperty(String key, String defaultValue) are implemented
several times at different locations (I think to remember alsways as
protected).
>
> Carsten
>
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
> Carsten Ziegeler wrote:
>> Leszek Gawron wrote:
>>> Carsten Ziegeler wrote:
>>>> Sorry, I got totally lost in all these mails. As far as I understand we
>>>> are currently discussing when/where it's possible to set the running mode.
>>>> There are two places: applicationContext.xml and system property. The
>>>> system property takes precedence over the applicationContext.xml. I'm
>>>> not sure which role cocoon.xconf should play in this?
>>> I think everyone means applicationContext.xml. I happend to put the
>>> wrong name in the first place.
>>>
>> :) OK, fine, so is there still a problem?
>
> As I've written in some post before: if noone objects that the actual
> logic of getting current running mode is duplicated here and there I
> have no problem also.
>
> I'll apply the patch today.
>
Sorry to ask again - there where too many responses for me in this
thread, so can you please give me an update on why the duplication is
necessary?
As far as I see it, the settings object should be available in all
places or we can pass in the running mode from the outside, like we did
with the sitemap element parser.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>> Carsten Ziegeler wrote:
>>> Sorry, I got totally lost in all these mails. As far as I understand we
>>> are currently discussing when/where it's possible to set the running mode.
>>> There are two places: applicationContext.xml and system property. The
>>> system property takes precedence over the applicationContext.xml. I'm
>>> not sure which role cocoon.xconf should play in this?
>> I think everyone means applicationContext.xml. I happend to put the
>> wrong name in the first place.
>>
> :) OK, fine, so is there still a problem?
As I've written in some post before: if noone objects that the actual
logic of getting current running mode is duplicated here and there I
have no problem also.
I'll apply the patch today.
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
> Carsten Ziegeler wrote:
>> Sorry, I got totally lost in all these mails. As far as I understand we
>> are currently discussing when/where it's possible to set the running mode.
>> There are two places: applicationContext.xml and system property. The
>> system property takes precedence over the applicationContext.xml. I'm
>> not sure which role cocoon.xconf should play in this?
>
> I think everyone means applicationContext.xml. I happend to put the
> wrong name in the first place.
>
:) OK, fine, so is there still a problem?
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Sorry, I got totally lost in all these mails. As far as I understand we
> are currently discussing when/where it's possible to set the running mode.
> There are two places: applicationContext.xml and system property. The
> system property takes precedence over the applicationContext.xml. I'm
> not sure which role cocoon.xconf should play in this?
I think everyone means applicationContext.xml. I happend to put the
wrong name in the first place.
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Sorry, I got totally lost in all these mails. As far as I understand we
are currently discussing when/where it's possible to set the running mode.
There are two places: applicationContext.xml and system property. The
system property takes precedence over the applicationContext.xml. I'm
not sure which role cocoon.xconf should play in this?
Carsten
Giacomo Pati wrote:
>
>
> Leszek Gawron wrote:
>>> Felix Knecht wrote:
>>>> + final String runningMode =
>>>> getSystemProperty(Settings.PROPERTY_RUNNING_MODE,
>>>> this.getAttributeValue(element, RUNNING_MODE_ATTR, null) );
>>> 1. the logic for obtaining running mode is scattered again
>
> You seem to have a problem with that :-)
>
> No, seriously. It seems a little over engineered at first as I cannot
> imagine anyone willing to have its own implementation of a
> getSystemProperty method (beacause they are protected). On the other
> hand (if we make those method private) I find the solution from Felix
> quite simple.
>
>>> 2. system property takes preference over the setting in cocoon.xconf. Is
>>> that correct?
>
> Yes, I think the System property should take precedence over the setting
> in cocoon.xconf
>
> --
> Giacomo Pati
> Otego AG, Switzerland - http://www.otego.com
> Orixo, the XML business alliance - http://www.orixo.com
>
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Leszek Gawron wrote:
>> Felix Knecht wrote:
>>> + final String runningMode =
>>> getSystemProperty(Settings.PROPERTY_RUNNING_MODE,
>>> this.getAttributeValue(element, RUNNING_MODE_ATTR, null) );
>> 1. the logic for obtaining running mode is scattered again
>
> You seem to have a problem with that :-)
>
> No, seriously. It seems a little over engineered at first as I cannot
> imagine anyone willing to have its own implementation of a
> getSystemProperty method (beacause they are protected). On the other
> hand (if we make those method private) I find the solution from Felix
> quite simple.
If everyone is OK with that I will have no objections either :).
>
>> 2. system property takes preference over the setting in cocoon.xconf. Is
>> that correct?
>
> Yes, I think the System property should take precedence over the setting
> in cocoon.xconf
Whatever you like. I won't be using <cocoon:settings runningMode="sth"/>
anyway
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> Felix Knecht wrote:
>> + final String runningMode =
>> getSystemProperty(Settings.PROPERTY_RUNNING_MODE,
>> this.getAttributeValue(element, RUNNING_MODE_ATTR, null) );
>
> 1. the logic for obtaining running mode is scattered again
You seem to have a problem with that :-)
No, seriously. It seems a little over engineered at first as I cannot
imagine anyone willing to have its own implementation of a
getSystemProperty method (beacause they are protected). On the other
hand (if we make those method private) I find the solution from Felix
quite simple.
> 2. system property takes preference over the setting in cocoon.xconf. Is
> that correct?
Yes, I think the System property should take precedence over the setting
in cocoon.xconf
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFT0lkLNdJvZjjVZARAm3/AJ9FigCA2PcpMl35cvw0Bm66kF3HuwCgkqh+
t6ZfBCpfqaWZ/IS32tpyaV4=
=biBj
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Felix Knecht <fe...@otego.com>.
Leszek Gawron schrieb:
> Felix Knecht wrote:
>> + final String runningMode =
>> getSystemProperty(Settings.PROPERTY_RUNNING_MODE,
>> this.getAttributeValue(element, RUNNING_MODE_ATTR, null) );
>
> 1. the logic for obtaining running mode is scattered again
Sorry, I know is a kind 'unprofessional', but yes, again.
> 2. system property takes preference over the setting in cocoon.xconf. Is
> that correct?
Yep
>
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Felix Knecht wrote:
> + final String runningMode = getSystemProperty(Settings.PROPERTY_RUNNING_MODE, this.getAttributeValue(element, RUNNING_MODE_ATTR, null) );
1. the logic for obtaining running mode is scattered again
2. system property takes preference over the setting in cocoon.xconf. Is
that correct?
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Felix Knecht <fe...@otego.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron schrieb:
> Leszek Gawron wrote:
>> Felix Knecht wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Giacomo Pati schrieb:
>>>>
>>>> Leszek Gawron wrote:
>>>>> with cocoon modes enabled for spring you can do something
>>>>> like this:
>>> I always get the error: Embedded error: Cannot invoke listener
>>> org.springframework.web.context.ContextLoaderListener@ef2e7c No
>>> bean named 'myDao' is defined
>>>
>>> Putting the 'myDao' bean definition into the myContext.xml it
>>> works. Maybe I need to enable cocoon modes for spring, but
>>> where do I enable cocoon modes for spring?
>>
>> Let me test that...
> This is another question to Carsten (SettingsElementParser):
>
>> public BeanDefinition parse(Element element, ParserContext
>> parserContext) { final String springConfigLocation =
>> this.getAttributeValue(element, "location",
>> Constants.DEFAULT_SPRING_CONFIGURATION_LOCATION);
>>
>> // create bean definition for settings object final String
>> componentClassName = this.getAttributeValue(element,
>> PROCESSOR_CLASS_NAME_ATTR,
>> SettingsBeanFactoryPostProcessor.class.getName()); final
>> RootBeanDefinition beanDef =
>> this.createBeanDefinition(componentClassName, "init", false); //
>> if running mode is specified add it as a property final String
>> runningMode = this.getAttributeValue(element, RUNNING_MODE_ATTR,
>> null); if (runningMode != null) {
>> beanDef.getPropertyValues().addPropertyValue("runningMode",
>> runningMode); }
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This
> code does not take into consideration the fact that cocoon running
> mode may be passed using system property
Attached path.txt will take consideration of this fact.
>
>> // register settings bean this.register(beanDef, Settings.ROLE,
>> parserContext.getRegistry());
>>
>> // register a PropertyPlaceholderConfigurer
>> this.registerPropertyOverrideConfigurer(parserContext,
>> springConfigLocation);
>>
>> // add the servlet context as a bean
>> this.addComponent(ServletContextFactoryBean.class.getName(),
>> ServletContext.class.getName(), null, false,
>> parserContext.getRegistry());
>>
>> // handle includes try { this.handleBeanInclude(parserContext,
>> null, Constants.DEFAULT_SPRING_CONFIGURATION_LOCATION, "*.xml",
>> true); this.handleBeanInclude(parserContext, null,
>> Constants.DEFAULT_SPRING_CONFIGURATION_LOCATION + "/" +
>> runningMode, "*.xml", true);
>
> when running mode is set with system property the runningMode
> variable is null here.
>
>> } catch (Exception e) { throw new
>> BeanDefinitionStoreException("Unable to read spring
>> configurations from " +
>> Constants.DEFAULT_SPRING_CONFIGURATION_LOCATION, e); } return
>> null; }
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFTzmF2lZVCB08qHERAvx6AKChw/2wHZw8UFIJWBhbrhHOwXF7CACdGGrI
4hf6llnM16ZDlKROdeN1cgs=
=uyI8
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> Felix Knecht wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Giacomo Pati schrieb:
>>>
>>> Leszek Gawron wrote:
>>>> with cocoon modes enabled for spring you can do something like
>>>> this:
>> I always get the error:
>> Embedded error: Cannot invoke listener
>> org.springframework.web.context.ContextLoaderListener@ef2e7c
>> No bean named 'myDao' is defined
>>
>> Putting the 'myDao' bean definition into the myContext.xml it works.
>> Maybe I need to enable cocoon modes for spring, but
>> where do I enable cocoon modes for spring?
>
> Let me test that...
This is another question to Carsten (SettingsElementParser):
> public BeanDefinition parse(Element element, ParserContext parserContext) {
> final String springConfigLocation = this.getAttributeValue(element, "location",
> Constants.DEFAULT_SPRING_CONFIGURATION_LOCATION);
>
> // create bean definition for settings object
> final String componentClassName = this.getAttributeValue(element, PROCESSOR_CLASS_NAME_ATTR,
> SettingsBeanFactoryPostProcessor.class.getName());
> final RootBeanDefinition beanDef = this.createBeanDefinition(componentClassName, "init", false);
> // if running mode is specified add it as a property
> final String runningMode = this.getAttributeValue(element, RUNNING_MODE_ATTR, null);
> if (runningMode != null) {
> beanDef.getPropertyValues().addPropertyValue("runningMode", runningMode);
> }
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This code does not take into consideration the fact that cocoon running
mode may be passed using system property
> // register settings bean
> this.register(beanDef, Settings.ROLE, parserContext.getRegistry());
>
> // register a PropertyPlaceholderConfigurer
> this.registerPropertyOverrideConfigurer(parserContext, springConfigLocation);
>
> // add the servlet context as a bean
> this.addComponent(ServletContextFactoryBean.class.getName(), ServletContext.class.getName(), null, false,
> parserContext.getRegistry());
>
> // handle includes
> try {
> this.handleBeanInclude(parserContext, null, Constants.DEFAULT_SPRING_CONFIGURATION_LOCATION, "*.xml", true);
> this.handleBeanInclude(parserContext, null, Constants.DEFAULT_SPRING_CONFIGURATION_LOCATION + "/" + runningMode, "*.xml", true);
when running mode is set with system property the runningMode variable
is null here.
> } catch (Exception e) {
> throw new BeanDefinitionStoreException("Unable to read spring configurations from " + Constants.DEFAULT_SPRING_CONFIGURATION_LOCATION, e);
> }
> return null;
> }
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Felix Knecht wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Giacomo Pati schrieb:
>>
>> Leszek Gawron wrote:
>>> with cocoon modes enabled for spring you can do something like
>>> this:
> I always get the error:
> Embedded error: Cannot invoke listener
> org.springframework.web.context.ContextLoaderListener@ef2e7c
> No bean named 'myDao' is defined
>
> Putting the 'myDao' bean definition into the myContext.xml it works.
> Maybe I need to enable cocoon modes for spring, but
> where do I enable cocoon modes for spring?
Let me test that...
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Felix Knecht <fe...@otego.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Giacomo Pati schrieb:
>
>
> Leszek Gawron wrote:
>> with cocoon modes enabled for spring you can do something like
>> this:
I always get the error:
Embedded error: Cannot invoke listener
org.springframework.web.context.ContextLoaderListener@ef2e7c
No bean named 'myDao' is defined
Putting the 'myDao' bean definition into the myContext.xml it works.
Maybe I need to enable cocoon modes for spring, but
where do I enable cocoon modes for spring?
Felix
>
>> in META-INF/cocoon/spring/myContext.xml:
>
>> <bean id="myService" class="com.mycompany.MyServiceImpl">
>> <property name="myDao" ref="myDao"/> </bean>
>
>> and then
>
>> in META-INF/cocoon/spring/dev/daos.xml: <bean id="myDao"
>> class="com.mycompany.MyMockDaoImpl"/>
>
>> in META-INF/cocoon/spring/prod/daos.xml: <bean id="myDao"
>> class="com.mycompany.MyActualDaoImpl"/>
>
> Cool, that's exactly what I was looking for, thanks!
>
> Ciao
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFTwX32lZVCB08qHERAnssAKDqoMUa8UpE7l4pdIKqDywc7WuYXgCg1o/1
lsw7y6SV5NkkO9pgjfOhTs4=
=9KV/
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> with cocoon modes enabled for spring you can do something like this:
>
> in META-INF/cocoon/spring/myContext.xml:
>
> <bean id="myService" class="com.mycompany.MyServiceImpl">
> <property name="myDao" ref="myDao"/>
> </bean>
>
> and then
>
> in META-INF/cocoon/spring/dev/daos.xml:
> <bean id="myDao" class="com.mycompany.MyMockDaoImpl"/>
>
> in META-INF/cocoon/spring/prod/daos.xml:
> <bean id="myDao" class="com.mycompany.MyActualDaoImpl"/>
Cool, that's exactly what I was looking for, thanks!
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFTMGWLNdJvZjjVZARApR5AKCx4agiz7aw82ca9+nyrx3qV3w23ACfXcZE
/fVEEOy316NcsWyFujw/vwA=
=htGD
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Leszek Gawron wrote:
>> Giacomo Pati wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>>
>>> Leszek Gawron wrote:
>>>> Carsten Ziegeler wrote:
>>>>> Giacomo Pati wrote:
>>>>>> Just to clear things:
>>>>> :)
>>>>>
>>>>>> Carsten Ziegeler wrote:
>>>>>>>> Done - with the additional change discussed recently, so now we
>>>>>>>> have:
>>>>>>>>
>>>>>>>>>>> META-INF/cocoon/avalon/**
>>>>>>>>>>> META-INF/cocoon/spring/**
>>>>>> plus ev. mode subdir {dev,test,proc}
>>>>>>
>>>>> Yes, but only for the properties! It's simple to add this for reading
>>>>> avalon and spring configurations, if desired?!?
>>>> I heard somewhere on the list that some developers (Giacomo?) where
>>>> using property placeholders for defining mock beans.
>>> Yup,that was me. Before one could do that which has been handy together
>>> with different modes:
>> OK, lets enable cocoon modes for META-INF/cocoon/spring/ and
>> META-INF/cocoon/avalon
>
> I thought modes are already enabled but it's not about mode, its about
> the ability to use properties replacement in
>
> <bean class="${...}">
with cocoon modes enabled for spring you can do something like this:
in META-INF/cocoon/spring/myContext.xml:
<bean id="myService" class="com.mycompany.MyServiceImpl">
<property name="myDao" ref="myDao"/>
</bean>
and then
in META-INF/cocoon/spring/dev/daos.xml:
<bean id="myDao" class="com.mycompany.MyMockDaoImpl"/>
in META-INF/cocoon/spring/prod/daos.xml:
<bean id="myDao" class="com.mycompany.MyActualDaoImpl"/>
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> Giacomo Pati wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Leszek Gawron wrote:
>>> Carsten Ziegeler wrote:
>>>> Giacomo Pati wrote:
>>>>> Just to clear things:
>>>> :)
>>>>
>>>>> Carsten Ziegeler wrote:
>>>>>>> Done - with the additional change discussed recently, so now we
>>>>>>> have:
>>>>>>>
>>>>>>>>>> META-INF/cocoon/avalon/**
>>>>>>>>>> META-INF/cocoon/spring/**
>>>>> plus ev. mode subdir {dev,test,proc}
>>>>>
>>>> Yes, but only for the properties! It's simple to add this for reading
>>>> avalon and spring configurations, if desired?!?
>>> I heard somewhere on the list that some developers (Giacomo?) where
>>> using property placeholders for defining mock beans.
>>
>> Yup,that was me. Before one could do that which has been handy together
>> with different modes:
> OK, lets enable cocoon modes for META-INF/cocoon/spring/ and
> META-INF/cocoon/avalon
I thought modes are already enabled but it's not about mode, its about
the ability to use properties replacement in
<bean class="${...}">
elements which since Carsten switched to Springs PropertyReplacer is not
possible anymore (our own implementation of property replacement was
able to do it).
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFTKaOLNdJvZjjVZARAnyOAJ9r8KvUPYIiBNe/o/KYvygJMWuoLACg02eA
DWAob6Ay2cSsIWbIVBd/kYo=
=xFXM
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Leszek Gawron wrote:
>> Carsten Ziegeler wrote:
>>> Giacomo Pati wrote:
>>>> Just to clear things:
>>> :)
>>>
>>>> Carsten Ziegeler wrote:
>>>>>> Done - with the additional change discussed recently, so now we have:
>>>>>>
>>>>>>>>> META-INF/cocoon/avalon/**
>>>>>>>>> META-INF/cocoon/spring/**
>>>> plus ev. mode subdir {dev,test,proc}
>>>>
>>> Yes, but only for the properties! It's simple to add this for reading
>>> avalon and spring configurations, if desired?!?
>> I heard somewhere on the list that some developers (Giacomo?) where
>> using property placeholders for defining mock beans.
>
> Yup,that was me. Before one could do that which has been handy together
> with different modes:
OK, lets enable cocoon modes for META-INF/cocoon/spring/ and
META-INF/cocoon/avalon
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> Carsten Ziegeler wrote:
>> Giacomo Pati wrote:
>>> Just to clear things:
>> :)
>>
>>> Carsten Ziegeler wrote:
>>>>> Done - with the additional change discussed recently, so now we have:
>>>>>
>>>>>>>> META-INF/cocoon/avalon/**
>>>>>>>> META-INF/cocoon/spring/**
>>> plus ev. mode subdir {dev,test,proc}
>>>
>> Yes, but only for the properties! It's simple to add this for reading
>> avalon and spring configurations, if desired?!?
>
> I heard somewhere on the list that some developers (Giacomo?) where
> using property placeholders for defining mock beans.
Yup,that was me. Before one could do that which has been handy together
with different modes:
> I could also find this useful. Especially when 'new CLI':
>
> ApplicationContext = new ClasspathXmlApplicationContext(
> "applicationContext.xml" );
>
> will finally create full blown cocoon container. I suppose 'when' might
> have changed to 'already' after the changes from last two days.
Whatever you mean by that !?!?
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFTJGPLNdJvZjjVZARAsRvAJ9Cp8OHfVs+UKYes5zo0qhaTR1gUACglb2r
Pu+QyEQhf+nB4edwQb1U5VM=
=OjDR
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Giacomo Pati wrote:
>> Just to clear things:
> :)
>
>> Carsten Ziegeler wrote:
>>>> Done - with the additional change discussed recently, so now we have:
>>>>
>>>>>>> META-INF/cocoon/avalon/**
>>>>>>> META-INF/cocoon/spring/**
>> plus ev. mode subdir {dev,test,proc}
>>
> Yes, but only for the properties! It's simple to add this for reading
> avalon and spring configurations, if desired?!?
I heard somewhere on the list that some developers (Giacomo?) where
using property placeholders for defining mock beans.
I could also find this useful. Especially when 'new CLI':
ApplicationContext = new ClasspathXmlApplicationContext(
"applicationContext.xml" );
will finally create full blown cocoon container. I suppose 'when' might
have changed to 'already' after the changes from last two days.
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote:
> Just to clear things:
:)
>
> Carsten Ziegeler wrote:
>>> Done - with the additional change discussed recently, so now we have:
>>>
>>>>>> META-INF/cocoon/avalon/**
>>>>>> META-INF/cocoon/spring/**
>
> plus ev. mode subdir {dev,test,proc}
>
Yes, but only for the properties! It's simple to add this for reading
avalon and spring configurations, if desired?!?
>>>>>> META-INF/cocoon/properties/**
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just to clear things:
Carsten Ziegeler wrote:
> Done - with the additional change discussed recently, so now we have:
>
>>>> META-INF/cocoon/avalon/**
>>>> META-INF/cocoon/spring/**
plus ev. mode subdir {dev,test,proc}
>>>> META-INF/cocoon/properties/**
>
> Carsten
>
> Carsten Ziegeler wrote:
>> Ok, it seems that we are all in favour of restructuring our directory
>> structure for 2.2.
>>
>> Could someone please write/run a script that does the work? The final
>> result should be:
>>
>>>> META-INF/cocoon/xconf/**
>>>> META-INF/cocoon/spring/**
>>>> META-INF/cocoon/properties/**
>> Thanks
>> Carsten
>
>
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFS8mFLNdJvZjjVZARAqkFAJ0fu0LkubPyF6hKwObycWpOGMu6zgCcChmo
wxh3g2wFBbPTjFAo+jm3zUg=
=USLw
-----END PGP SIGNATURE-----
Re: Restructuring directory structure[was [Vote] Block artifact directory
structure]
Posted by Carsten Ziegeler <cz...@apache.org>.
Done - with the additional change discussed recently, so now we have:
>>> META-INF/cocoon/avalon/**
>>> META-INF/cocoon/spring/**
>>> META-INF/cocoon/properties/**
Carsten
Carsten Ziegeler wrote:
> Ok, it seems that we are all in favour of restructuring our directory
> structure for 2.2.
>
> Could someone please write/run a script that does the work? The final
> result should be:
>
>>> META-INF/cocoon/xconf/**
>>> META-INF/cocoon/spring/**
>>> META-INF/cocoon/properties/**
>
> Thanks
> Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/