Re: Another settings question (love bugging Carsten these days)
Leszek Gawron wrote: Previously web.xml properties were read into settings via a hard-wired PropertyProvider. I see no property providers implemented now in cocoon-core as well as no code reading web.xml elsewhere. Was this intentional? I have not used the functionality anyways. Just trying to keep compatibility. Yes, that's intentional :) We decided to drop the compatibility because of two reasons: - With 2.2 you might have several Cocoon related servlets, listeners or filters which makes a central configuration in web.xml more complicated (ok, you could use context parameters) - but most important: no need to patch web.xml for this. You can configure everything more elegantly via properties. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Another settings question (love bugging Carsten these days)
Carsten Ziegeler wrote: Leszek Gawron wrote: Previously web.xml properties were read into settings via a hard-wired PropertyProvider. I see no property providers implemented now in cocoon-core as well as no code reading web.xml elsewhere. Was this intentional? I have not used the functionality anyways. Just trying to keep compatibility. Yes, that's intentional :) We decided to drop the compatibility because of two reasons: - With 2.2 you might have several Cocoon related servlets, listeners or filters which makes a central configuration in web.xml more complicated (ok, you could use context parameters) - but most important: no need to patch web.xml for this. You can configure everything more elegantly via properties. I fully agree. It would be even better If I could declare a servlet filter at core level or sitemap level so I do not have to patch web.xml either. -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Another settings question (love bugging Carsten these days)
Leszek Gawron wrote: I fully agree. It would be even better If I could declare a servlet filter at core level or sitemap level so I do not have to patch web.xml either. I'm not sure, but perhaps Spring does provide something like this? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: cocoon ehcache usage vs. hibernate + spring
This has come up a few times before, independent of it being used in
hibernate's session factory.
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110846153823635w=2
This problem now seems to be on the ehcache list as well:
http://sourceforge.net/mailarchive/forum.php?thread_id=30378955forum_id=48004
I am having the The cocoon-ehcache-X Cache is not alive also from time to
time, but did not have time to check when exactly it happens.
Another problem we have with ehcache 1.2.2 is (though it might have been in
there always, because our diskPersistent between JVM restarts did not work
before) that I don't know what it does on a JVM restart. I suppose that it
stores its memory store keys and disk store keys to cocoon-ehcache-X.index on
shut down, and on starting up, re-populates its cache according that index
(with the LRU and things correctly restored). We have large sites running, with
disk stores easily growing to 1 Gb in a couple of days (keeping only 1000 items
in memory). Start up takes insanely long now when the disk store is large (up
to 10 min for 1 Gb disk store). Are there other people having this problem?
Regards Ard
Jorg
On 22 Aug 2006, at 11:08, Leszek Gawron wrote:
It looks like cocoon ehcache based store does not live
happily with
hibernate's session factory (spring managed):
304859 [Shutdown] INFO / - Closing Spring root
WebApplicationContext
304859 [Shutdown] INFO
org.springframework.web.context.support.XmlWebApplicationContext -
Closing application context [Root WebApplicationContext]
304859 [Shutdown] INFO
org.springframework.beans.factory.support.DefaultListableBeanFactory
- Destroying singletons in
{org.springframework.beans.factory.support.DefaultL
istableBeanFactory defining beans
[filterChainProxy,httpSessionContextIntegrationFilter,basicProcessing
Filter,basicProcessingFilterEntryPoint,exceptionTranslationFilter,f
ilterSecurityInterceptor,roleVoter,accessDecisionManager,userDetailsS
ervice,userCache,daoAuthenticationProvider,anonymousAuthenticationPro
vider,testingAuthenticationProvi
der,rememberMeAuthenticationProvider,authenticationManager,beanSecuri
tyInterceptor,beanSecurityAdvisor,placeholderConfig,org.springframewo
rk.beans.factory.annotation.Requ
iredAnnotationBeanPostProcessor,dataSource,sessionFactory,baseHiberna
teDao,transactionManager,annotationTransactionAttributeSource,transac
tionInterceptor,transactionAdvis
or,org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProx
yCreator,clientDao,transportOrderDao,orderLogEntryDao,clientService,t
ransportOrderService,org.springf
ramework.scheduling.quartz.SchedulerFactoryBean]; root of
BeanFactory hierarchy}
304859 [Shutdown] INFO
org.springframework.scheduling.quartz.SchedulerFactoryBean -
Shutting down Quartz Scheduler
304859 [Shutdown] INFO org.quartz.core.QuartzScheduler -
Scheduler
DefaultQuartzScheduler_$_NON_CLUSTERED shutting down.
304859 [Shutdown] INFO org.quartz.core.QuartzScheduler -
Scheduler
DefaultQuartzScheduler_$_NON_CLUSTERED paused.
304859 [Shutdown] INFO org.quartz.core.QuartzScheduler -
Scheduler
DefaultQuartzScheduler_$_NON_CLUSTERED shutdown complete.
304859 [Shutdown] INFO
org.springframework.orm.hibernate3.LocalSessionFactoryBean -
Closing Hibernate SessionFactory
304859 [Shutdown] INFO org.hibernate.impl.SessionFactoryImpl -
closing
304859 [Shutdown] ERROR
org.springframework.beans.factory.support.DefaultListableBeanFactory
- Destroy method on bean with name 'sessionFactory' threw an
exception
java.lang.IllegalStateException: The cocoon-ehcache-1
Cache is not
alive.
at net.sf.ehcache.Cache.checkStatus(Cache.java:1062)
at net.sf.ehcache.Cache.dispose(Cache.java:939)
at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:
538)
at org.hibernate.cache.EhCacheProvider.stop
(EhCacheProvider.java:145)
at org.hibernate.impl.SessionFactoryImpl.close
(SessionFactoryImpl.java:756)
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.orm.hibernate3.LocalSessionFactoryBean
$TransactionAwareInvocationHandler.invoke
(LocalSessionFactoryBean.java:1124)
at $Proxy10.close(Unknown Source)
at
org.springframework.orm.hibernate3.LocalSessionFactoryBean.destroy
(LocalSessionFactoryBean.java:1078)
at
org.springframework.beans.factory.support.DisposableBeanAdapter.destr
oy(DisposableBeanAdapter.java:97)
at
[jira] Closed: (COCOON-1903) [PATCH] cocoon-block-deployer does not reflect latest spring configuration changes
[ http://issues.apache.org/jira/browse/COCOON-1903?page=all ] Lars Trieloff closed COCOON-1903. - Resolution: Fixed [PATCH] cocoon-block-deployer does not reflect latest spring configuration changes -- Key: COCOON-1903 URL: http://issues.apache.org/jira/browse/COCOON-1903 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-block-deployer-spring-support.patch In revision 436902 cziegeler changed the way a cocoon web application is loaded in order to provide better spring support. This change had been applied to the cocoon-webapp example web application, but not to the mininmal web application configuration provided by the cocoon-block-deployer maven plugin resulting in breaking the mvn cocoon:deploy jetty6:run target used for developing custom blocks in trunk. (In effect class org.apache.cocoon.servlet.CocoonServletListener could not found) The attached patch updates the web.xml provided by the cocoon-block-deployer to use org.springframework.web.context.ContextLoaderListener instead of org.apache.cocoon.servlet.CocoonServletListener, adds an applicationContext.xml to the cocoon-block-deployer and makes cocoon-block-deployer deploy this applicationContext.xml additionally to web.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Property replacement in spring config files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all I couldn't follow all the recent changes to the property/settings subject but it seems with the current trunk not all properties will be replaced anymore in spring config files. I have spring.xml where the class attribute of a bean element is set by a property and this has worked util today (well, my last full build of trunk was mid last week). Is this change because of some refactoring or something else? 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) iD8DBQFE9a1bLNdJvZjjVZARAqY8AKDqEWycpRjOecSFFARjhGPKGcDd+QCgmZ17 ovWH0Ia2iSKA55j9m40azJk= =Hq+C -END PGP SIGNATURE-
[jira] Created: (COCOON-1904) [PATCH] pom.xml generated for cocoon-block-archetype does not regard versions
[PATCH] pom.xml generated for cocoon-block-archetype does not regard versions - Key: COCOON-1904 URL: http://issues.apache.org/jira/browse/COCOON-1904 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-archetype-pom-version.patch The pom.xml generated by the cocoon-22-block archtepye uses a variable for the version for configuring the maven-jetty-plugin, but uses a fixed version for the project itself. This leads to problem when the version specified at the command line is not identical to 1.0.0-SNAPSHOT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1904) [PATCH] pom.xml generated for cocoon-block-archetype does not regard versions
[ http://issues.apache.org/jira/browse/COCOON-1904?page=all ] Lars Trieloff updated COCOON-1904: -- Attachment: cocoon-archetype-pom-version.patch This patch makes the version for the generated pom.xml variable. [PATCH] pom.xml generated for cocoon-block-archetype does not regard versions - Key: COCOON-1904 URL: http://issues.apache.org/jira/browse/COCOON-1904 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-archetype-pom-version.patch The pom.xml generated by the cocoon-22-block archtepye uses a variable for the version for configuring the maven-jetty-plugin, but uses a fixed version for the project itself. This leads to problem when the version specified at the command line is not identical to 1.0.0-SNAPSHOT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Subscription: COCOON-open-with-patch
Issue Subscription
Filter: COCOON-open-with-patch (85 issues)
Subscriber: cocoon
Key Summary
COCOON-1904 [PATCH] pom.xml generated for cocoon-block-archetype does not
regard versions
http://issues.apache.org/jira/browse/COCOON-1904
COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice
http://issues.apache.org/jira/browse/COCOON-1899
COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin
http://issues.apache.org/jira/browse/COCOON-1898
COCOON-1893 XML-Binding: Problem creating a new element
http://issues.apache.org/jira/browse/COCOON-1893
COCOON-1890 Provide a tool to update artifact versions within multiple POMs
http://issues.apache.org/jira/browse/COCOON-1890
COCOON-1879 Make fd:field whitespace trimming behavior configurable
http://issues.apache.org/jira/browse/COCOON-1879
COCOON-1877 [PATCH] Pageable Repeater
http://issues.apache.org/jira/browse/COCOON-1877
COCOON-1870 Lucene block does not store attributes when instructed so
http://issues.apache.org/jira/browse/COCOON-1870
COCOON-1869 MailMessageSender.java eats exception chain - which does not allow
for proper dubuging and logging
http://issues.apache.org/jira/browse/COCOON-1869
COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the
rigth time with IE
http://issues.apache.org/jira/browse/COCOON-1846
COCOON-1843 LDAPTransformer: add-entry tag doesn't work
http://issues.apache.org/jira/browse/COCOON-1843
COCOON-1842 LDAPTransformer: ClassCastException with Binary fields
http://issues.apache.org/jira/browse/COCOON-1842
COCOON-1838 Always use 3-digit version number
http://issues.apache.org/jira/browse/COCOON-1838
COCOON-1811 [PATCH] Flow Script: Allow dynamic loading of JavaScript objects
even when scope is locked
http://issues.apache.org/jira/browse/COCOON-1811
COCOON-1810 [PATCH] JMSEventMessageListener does not work
http://issues.apache.org/jira/browse/COCOON-1810
COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and
implementation of a move-node binding
http://issues.apache.org/jira/browse/COCOON-1794
COCOON-1776 [PATCH]Reload Bookmarks on bookmark file validity
http://issues.apache.org/jira/browse/COCOON-1776
COCOON-1738 double-listbox problem in repeaters
http://issues.apache.org/jira/browse/COCOON-1738
COCOON-1726 Implementation of Source that supports conditional GETs
http://issues.apache.org/jira/browse/COCOON-1726
COCOON-1717 Use custom cache keys for caching uri coplets using input modules.
http://issues.apache.org/jira/browse/COCOON-1717
COCOON-1706 Allow TeeTransformer to run a system command for debugging purposes
http://issues.apache.org/jira/browse/COCOON-1706
COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text
orientation, color code fix, prefered unit for margins and measure unit
converter
http://issues.apache.org/jira/browse/COCOON-1703
COCOON-1697 Allow request parameters to be used in for (var k in h) kind of
Javascript Loops
http://issues.apache.org/jira/browse/COCOON-1697
COCOON-1692 [PATCH] Tree widget not handling on-selection-change events
correctly.
http://issues.apache.org/jira/browse/COCOON-1692
COCOON-1686 [PATCH] COCOON-1671 Form not binding when prefix in binding
definition is unequal to that in the instance data for the same namespace.
http://issues.apache.org/jira/browse/COCOON-1686
COCOON-1648 Add support for ISO8601 in I18nTransformer and Forms
http://issues.apache.org/jira/browse/COCOON-1648
COCOON-1622 [PATCH] SendMailTransformer and HTML body
http://issues.apache.org/jira/browse/COCOON-1622
COCOON-1618 [PATCH] SoapGenerator/Serializer for Axis Block
http://issues.apache.org/jira/browse/COCOON-1618
COCOON-1611 [PATCH] Add additonal constructor to FormInstance.java to be able
to pass a locale
http://issues.apache.org/jira/browse/COCOON-1611
COCOON-1603 [PATCH] handling of alternatives in MailTransformer
http://issues.apache.org/jira/browse/COCOON-1603
COCOON-1573 Improvement SetAttributeJXPathBinding and Contribution
SetNodeValueJXPathBinding
http://issues.apache.org/jira/browse/COCOON-1573
COCOON-1557 [PATCH] Change access to AbstractContinuable.getContext to protected
http://issues.apache.org/jira/browse/COCOON-1557
COCOON-1556 [PATCH] Add a JXPathConvertor for conversion betwean beans and
Strings
http://issues.apache.org/jira/browse/COCOON-1556
COCOON-1535 [PATCH] enhancement to {global:} input module: return all sitemap
globals
http://issues.apache.org/jira/browse/COCOON-1535
COCOON-1527 [PATCH] Cache control logic sheets for XSP to override getKey and
getValidity
Re: Property replacement in spring config files
Giacomo Pati wrote: Hi all I couldn't follow all the recent changes to the property/settings subject but it seems with the current trunk not all properties will be replaced anymore in spring config files. I have spring.xml where the class attribute of a bean element is set by a property and this has worked util today (well, my last full build of trunk was mid last week). Is this change because of some refactoring or something else? I guess it is due to the refactoring, but I'm not sure. The difference between the old version and today is that now Spring is duing the replacement for us. This means now we are reading the configurations path them to Spring and tell Spring to replace the properties. Is it possible to use a property as class name in plain spring? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
patch for an entityResolver problem in xsl stylesheets ...
Hi;
I tried to use external entities like uuml; etc. in xsl stylesheets.
For this purpose in first place i added a DOCTYPE definition on top of
my stylesheet, i.e.:
?xml version=1.0?
!DOCTYPE mydoc [
!ENTITY % ISOlat1 PUBLIC ISO 8879:1986//ENTITIES Added Latin 1//EN//XML
ISOlat1.pen %ISOlat1;
]xsl:stylesheet version=1.0
...
I assumed, the default entity resolver would resolve the ISOlat1.pen, but it
did not!
I tracked this down and found, that entity resolution only works correctly when
i
set the SYSTEM identifier to the absolute location of the external entity file.
I did
not like this hack, hence i tracked the problem further down and eventually
found
one location in TraxProcessor.java which apparently needs a modification in
order to inject
the correct EntityResolver to work as expected.
I finally created a patch, which adds Entity resolving within XSLT processing
wherever
a document(), import or include is performed. i did not check whether this
patch works
recursively (follows an import within an imported xsl), but it looks like it
would do ...
The patch has been created against cocoon/branches/BRANCH_2_1_X
It works for me. Hopefully it is usefull for others and does not break code at
other
places. If anyone would like to review the patch and give some feedback,
That would be great ;-)
best regards,
Hussayn
Index: src/java/org/apache/cocoon/components/xslt/TraxProcessor.java
===
--- src/java/org/apache/cocoon/components/xslt/TraxProcessor.java
(revision 437809)
+++ src/java/org/apache/cocoon/components/xslt/TraxProcessor.java
(working copy)
@@ -30,6 +30,7 @@
import javax.xml.transform.TransformerException;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.URIResolver;
+import javax.xml.transform.sax.SAXSource;
import javax.xml.transform.sax.SAXTransformerFactory;
import javax.xml.transform.sax.TemplatesHandler;
import javax.xml.transform.sax.TransformerHandler;
@@ -52,14 +53,17 @@
import org.apache.excalibur.source.SourceValidity;
import org.apache.excalibur.source.impl.validity.AggregatedValidity;
import org.apache.excalibur.store.Store;
+import org.apache.excalibur.xml.EntityResolver;
import org.apache.excalibur.xml.sax.XMLizable;
import org.apache.excalibur.xml.xslt.XSLTProcessor;
import org.apache.excalibur.xml.xslt.XSLTProcessorException;
import org.apache.excalibur.xmlizer.XMLizer;
+import org.apache.xml.utils.XMLReaderManager;
import org.xml.sax.ContentHandler;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import org.xml.sax.XMLFilter;
+import org.xml.sax.XMLReader;
/**
* Adaptation of Excalibur's XSLTProcessor implementation to allow for better
@@ -91,6 +95,9 @@
/** Resolver used to resolve XSLT document() calls, imports and includes */
protected SourceResolver m_resolver;
+
+/** EntityResolver used to resolve Entity references within document(),
import and include targets */
+protected EntityResolver m_entityResolver;
/** Check included stylesheets */
protected boolean m_checkIncludes;
@@ -118,6 +125,7 @@
if (m_manager.hasService(Store.TRANSIENT_STORE)) {
m_store = (Store) m_manager.lookup(Store.TRANSIENT_STORE);
}
+m_entityResolver = (EntityResolver)
m_manager.lookup(EntityResolver.ROLE);
}
/**
@@ -560,7 +568,7 @@
}
}
-InputSource is = getInputSource(xslSource);
+SAXSource saxSource = getInputSource(xslSource);
if (getLogger().isDebugEnabled()) {
getLogger().debug(xslSource = + xslSource + , system id =
+ xslSource.getURI());
@@ -580,7 +588,7 @@
}
}
-return new StreamSource(is.getByteStream(), is.getSystemId());
+return saxSource;
} catch (SourceException e) {
if (getLogger().isDebugEnabled()) {
getLogger().debug(Failed to resolve + href + (base = +
base + ), return null, e);
@@ -614,10 +622,22 @@
* @throws IOException
* if I/O error occured.
*/
-protected InputSource getInputSource(final Source source) throws
IOException, SourceException {
-final InputSource newObject = new InputSource(source.getInputStream());
+protected SAXSource getInputSource(final Source source) throws
IOException, SourceException {
+InputSource newObject = new InputSource(source.getInputStream());
newObject.setSystemId(source.getURI());
-return newObject;
+SAXSource saxSource = new SAXSource(newObject);
+try{
+ if(m_entityResolver != null){
+ XMLReader reader =
XMLReaderManager.getInstance().getXMLReader();
+ reader.setEntityResolver(m_entityResolver);
+ saxSource.setXMLReader(reader);
+ }
+
Re: Property replacement in spring config files
On Wed, 30 Aug 2006, Carsten Ziegeler wrote: Date: Wed, 30 Aug 2006 22:00:13 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Property replacement in spring config files Giacomo Pati wrote: Hi all I couldn't follow all the recent changes to the property/settings subject but it seems with the current trunk not all properties will be replaced anymore in spring config files. I have spring.xml where the class attribute of a bean element is set by a property and this has worked util today (well, my last full build of trunk was mid last week). Is this change because of some refactoring or something else? I guess it is due to the refactoring, but I'm not sure. The difference between the old version and today is that now Spring is duing the replacement for us. This means now we are reading the configurations path them to Spring and tell Spring to replace the properties. Is it possible to use a property as class name in plain spring? Good question. Never used plain Spring that way, but Cocoon-Spring-Integration ;-) and I loved being able to do it. That way I was able to have Mock-Beans for mode=dev (speed), Local-Beans for mode=test (functional), and Prod-Beans for mode=prod (live) just with a set of properties no need to change/filter any config file. Ciao and thanks -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
[jira] Created: (COCOON-1905) [PATCH] Support non-file resources for jaas.config in JCR block
[PATCH] Support non-file resources for jaas.config in JCR block --- Key: COCOON-1905 URL: http://issues.apache.org/jira/browse/COCOON-1905 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor The current implementation of the JCR-block requires the user to define a physical file as source for the jaas.config. While is behaviour matches the requirements of the Java JAAS implementation it is inconvenient for development and prevents the creation of a generic out-of-the-box cocoon-JCR-example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1905) [PATCH] Support non-file resources for jaas.config in JCR block
[ http://issues.apache.org/jira/browse/COCOON-1905?page=all ] Lars Trieloff updated COCOON-1905: -- Attachment: cocoon-jcr-jaas-uri-source.patch This patch allows the JAAS configuration to be stored in non physical files, e.g. in context resources, which is often the case with blocks under development that are deployed using the mvn cocoon:deploy goal. The patch adds a special case for those non-physical files: A temporary file is created, the contents of the specified resource are copied into the temporary file and this temporary file is used for configuring JAAS. This is very convenient behaviour in development environments because the block can be used out-of-the-box, but does not affect the security properties of a production system because in this case the location of the jaas.config file will be specified using Java system properties. [PATCH] Support non-file resources for jaas.config in JCR block --- Key: COCOON-1905 URL: http://issues.apache.org/jira/browse/COCOON-1905 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-jcr-jaas-uri-source.patch The current implementation of the JCR-block requires the user to define a physical file as source for the jaas.config. While is behaviour matches the requirements of the Java JAAS implementation it is inconvenient for development and prevents the creation of a generic out-of-the-box cocoon-JCR-example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1904) [PATCH] pom.xml generated for cocoon-block-archetype does not regard versions
[ http://issues.apache.org/jira/browse/COCOON-1904?page=all ] Leszek Gawron closed COCOON-1904. - Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed applied, thanks [PATCH] pom.xml generated for cocoon-block-archetype does not regard versions - Key: COCOON-1904 URL: http://issues.apache.org/jira/browse/COCOON-1904 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-archetype-pom-version.patch The pom.xml generated by the cocoon-22-block archtepye uses a variable for the version for configuring the maven-jetty-plugin, but uses a fixed version for the project itself. This leads to problem when the version specified at the command line is not identical to 1.0.0-SNAPSHOT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
