Re: [2.2] Simplifying configuration
Antonio Fiol Bonnín wrote:
Some thoughts (my opinion) about configuration.
1. Environment-related configuration should be banned inside the
webapp directory (or WAR file).
2. Business-related configuration should be inside it.
[...]
Thanks for sharing your ideas! After having some working prototype of the OSGi
based blocks-fw (expect this within the next 6-8 weeks), we will certainly
discuss configuration management in detail. Your mail is certainly a good
starting point, especially your idea of differentiating between environment
related configuration and business-related configurations.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[docs] updating Daisy
Hi, If nobody minds I'd like to upgrade the Daisy on the cocoon zone this afternoon, somewhere around 4 pm CET. Since this involves restarting Daisy, it's better not to edit docs in Daisy around that time. I'll give a notice when it's done. Bruno. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Block deployment
* Reinhard Poetz: Jean-Baptiste Quenot wrote: And I have a more general question: what concrete usecase and existing blocks have motivated the design and development of the wiring feature? Do we have several blocks implementing the same interface? see http://wiki.apache.org/cocoon/BlockIntroduction, which was the originally written by Stefano long time ago. The wiki documents mainly deal with what we call sitemap blocks. The last missing piece is how component dependencies will finally look like. That's pretty much undefined. Declarative services in OSGi could be the answer. OK to make it short, I think that the top priority is to have the block deployment working again. Polymorphism and inheritance are brilliant ideas, but should not be considered short-term development. If we want to release 2.2, we must delay the development of polymorphism and inheritance. What is missing to have this block deployer working, without wiring concerns (hardcoded wiring against cocoon-core)? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [jira] Closed: (COCOON-649) [PATCH] Made SQLTransformer paginatable
* David Crossley: It looks like the patch was made against the old CVS for Cocoon. My did you Close, rather than just ask for a new patch? Because the bug is three years old, there is very little probability that the contributor still uses Cocoon. That's why I stated: « Feel free to reopen if you can provide an updated patch. » -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Block deployment
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
Jean-Baptiste Quenot wrote:
And I have a more general question: what concrete usecase and
existing blocks have motivated the design and development of
the wiring feature? Do we have several blocks implementing
the same interface?
see http://wiki.apache.org/cocoon/BlockIntroduction, which was
the originally written by Stefano long time ago.
The wiki documents mainly deal with what we call
sitemap blocks. The last missing piece is how component
dependencies will finally look like. That's pretty much
undefined. Declarative services in OSGi could be the answer.
OK to make it short, I think that the top priority is to have the
block deployment working again. Polymorphism and inheritance
are brilliant ideas, but should not be considered short-term
development.
it was implemented by Daniel about one year ago.
If we want to release 2.2, we must delay the development of
polymorphism and inheritance.
What is missing to have this block deployer working, without
wiring concerns (hardcoded wiring against cocoon-core)?
I'm working on the deployer again and will give a status report very soon
(sunday or monday).
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Block deployment
* Reinhard Poetz: Jean-Baptiste Quenot wrote: * Reinhard Poetz: Jean-Baptiste Quenot wrote: And I have a more general question: what concrete usecase and existing blocks have motivated the design and development of the wiring feature? Do we have several blocks implementing the same interface? see http://wiki.apache.org/cocoon/BlockIntroduction, which was the originally written by Stefano long time ago. The wiki documents mainly deal with what we call sitemap blocks. The last missing piece is how component dependencies will finally look like. That's pretty much undefined. Declarative services in OSGi could be the answer. OK to make it short, I think that the top priority is to have the block deployment working again. Polymorphism and inheritance are brilliant ideas, but should not be considered short-term development. it was implemented by Daniel about one year ago. Then can you explain the current tasks left to do to have the blocks framework? If we want to release 2.2, we must delay the development of polymorphism and inheritance. What is missing to have this block deployer working, without wiring concerns (hardcoded wiring against cocoon-core)? I'm working on the deployer again and will give a status report very soon (sunday or monday). OK, thanks a lot. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Block deployment
Jean-Baptiste Quenot wrote: ... Then can you explain the current tasks left to do to have the blocks framework? https://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12310712 It's not completely up to date. Since we wrote it we have changed from ECM++ to Spring for Cocoon. This change is not yet done for the blocks fw, which still use ECM++. I have not yet thought out the details about how to switch the blocks fw to Spring. For more general background about component handling in blocks you can take a look at: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113813135727508w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113916800307367w=2 And a somewhat older overview about the blocks implementation: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113335919919804w=2 /Daniel
I am guest in Daisy
Hello, Can someone with Daisy karma grant me to edit documents? I would like to change the « Who we are » page for now. Thanks in advance, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
RE: environment errors
Dear all, sorry for this noise... It was my fault. I didn't release a source properly in one of my generators... Jean-Baptiste, maybe you have the same problem? Bye! max -Original Message- From: Max Pfingsthorn Sent: Thursday, March 02, 2006 13:10 To: dev@cocoon.apache.org Subject: RE: environment errors ...nevermind. that didn't do the trick. max -Original Message- From: Max Pfingsthorn Sent: Thursday, March 02, 2006 13:05 To: dev@cocoon.apache.org Subject: RE: environment errors Carsten Ziegeler [mailto:[EMAIL PROTECTED] Max Pfingsthorn schrieb: Hi! Okay, I traced this one to the o.a.c.environment.wrapper.EnvironmentWrapper thank god for debuggers). That one does not implement release(Source) itself, so the superclass is used, but since it is a wrapper, it is not initialized to have a source resolver itself! I am not sure what this class is used for, but can I just forward the call to the wrapped environment like some of the other methods do? Hmm, no, I think this is then just a workaround for the real problem. If the source resolver is null in release it either means that the resolveURI was never called before, so a source is tried to be released on a different env than it was looked up from. Or in the other case, finishProcessing() has been called prior to the release method. Then the order of method calls is wrong. Can you come up with a test case? Well, there are two errors here, actually. The one Jean-Baptiste commented on and the one I traced. Both are very similar, and seem to be caused by a similar problem... In Cocoon.process, in the last finally block, we call CocoonComponentManager.leaveEnvironment(); CocoonComponentManager.endProcessing(environment, key); leaveEnvironment pops the environment stack while endProcessing will call release (which in turn calls recycle) on all components, which in turn calls CocoonComponentManager.removeFromAutomaticRelease(Component) which tries to acces the environment stack, which is empty. The other error is caused by endProcessing calling env.finishingProcessing(); before desc.release();. Okay, I think I got it now. The CocoonComponentManager.addComponentForAutomaticRelease will actually add this component to the root environment (line 464, in 2.1.8) because it does stack.get(0), which is the lowest stack item. This happens for each sitemap source in the init() method. Since env.finishingProcessing() is called by each sitemap source (through CocoonComponentManager.leaveEnvironment()) and removeFromAutomaticRelease() is done after all the processing, the environment the components from the deeper sitemap sources will already have been ended. It would be better to add them to the top of the stack. I think this would solve both problems, because both occur in EnvironmentDescription.release(). I'll try to come up with a simple test case, but right now I have a headache from two days of sitting in front of the debugger... I'll let you know if changing this one line in CocoonComponentManager.addComponentForAutomaticRelease helped. Actually its changing final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(0); into final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(); I'll take some painkillers now. max
RE: Cocoon developers opensource license YourKit Java Profiler
Hello! Yes, please, I would like one :) Thanks! max -Original Message- From: David Crossley [mailto:[EMAIL PROTECTED] Sent: Thursday, March 02, 2006 23:33 To: dev@cocoon.apache.org Subject: Re: Cocoon developers opensource license YourKit Java Profiler David Crossley wrote: Cocoon developers who would like to use YourKit Java Profiler during their work on the Cocoon project, are entitled to an Open Source license. Here is their response to my request for clarification. I defined exactly what we mean by developer and committer and then asked what was their meaning ... developer is a person who will use profiler during his work in Forrest/Cocoon project. Last call. Any more Cocoon developers wanting a license key? -David
RE: repository block
Hi! Okay, for the WebDAVSource, or any Inspectable and Traverseable source, you will get an InspectableTraversableCachingSource from the CachingSourceFactory. This source will actually put SourceProperty objects in a map for its cached response. The cached response is Serializable, but not the elements in that map, so ObjectOutputStream.writeObject() fails. This only happens when the in-memory part of the Cache which uses the EHDefaultStore becomes too full and loads objects off to disk. Here is the exception we get: 2006-02-28 12:03:57,173 ERROR net.sf.ehcache.store.DiskStore cocoon-ehcache-1Cache: Could not write elements to disk cache java.io.NotSerializableException: org.apache.cocoon.components.source.helpers.SourceProperty at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at java.util.HashMap.writeObject(HashMap.java:980) at sun.reflect.GeneratedMethodAccessor789.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at net.sf.ehcache.store.DiskStore.flushSpool(DiskStore.java:515) at net.sf.ehcache.store.DiskStore.spoolThreadMain(DiskStore.java:488) at net.sf.ehcache.store.DiskStore.access$600(DiskStore.java:89) at net.sf.ehcache.store.DiskStore$SpoolThread.run(DiskStore.java:755) max -Original Message- From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED] Sent: Thursday, March 02, 2006 16:59 To: dev@cocoon.apache.org Subject: Re: repository block * Max Pfingsthorn: I want to refactor the repository block so that SourceProperty is an interface. Or at least implement readObject() and writeObject(), so it can be serialized. SourceProperty not being Serializable makes the WebDAVSource (and any other which implements InspectableSource) not cacheable via the CachingSourceFactory from the scratchpad. Hello Max, Does CachingSourceFactory give an error? How do you observe that WebDAVSource is not cacheable? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: I am guest in Daisy
On Fri, 2006-03-03 at 11:38 +0100, Jean-Baptiste Quenot wrote: Hello, Can someone with Daisy karma grant me to edit documents? I would like to change the « Who we are » page for now. done, enjoy. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: environment errors
* Max Pfingsthorn: sorry for this noise... It was my fault. I didn't release a source properly in one of my generators... Jean-Baptiste, maybe you have the same problem? This is a very good suggestion. Maybe a cocoon: source is not released. I will double check. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Release 2.1.9 (again)
I am pinging again to see where we stand. AFAIK the only thing we are waiting for is Sylvain's blessing on Ajax. Also, does Ajax need to be marked stable since Forms depends on it? Ralph
Re: Release 2.1.9 (again)
Ralph Goers wrote: I am pinging again to see where we stand. AFAIK the only thing we are waiting for is Sylvain's blessing on Ajax. Also, does Ajax need to be marked stable since Forms depends on it? We experienced some strange problems with latest forms as some of our applications using javascript are not working properly anymore (all browsers on windows and linux). I did not have enough time to dive into the real problem - it might be our own code which needs to be adapted to latest forms or it might be a problem in the forms/ajax block. We downgraded to a svn snapshot just before the change to dojo and everything works perfectly. Hopefully, I'll have time by the end of next week to find the problem. Anyways, I think we should also mark the ajax block stable - as soon as we are confident that everything works as expected. What about the template block from 2.2? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: environment errors
* Max Pfingsthorn: sorry for this noise... It was my fault. I didn't release a source properly in one of my generators... Just to be sure: is it a cocoon: source that was missing to be released? For a file: source, I don't think it makes a difference to release it or not. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
[jira] Created: (COCOON-1790) VerifyException Attempt to split long or double on the stack in javaflow
VerifyException Attempt to split long or double on the stack in javaflow -- Key: COCOON-1790 URL: http://issues.apache.org/jira/browse/COCOON-1790 Project: Cocoon Type: Bug Components: Blocks: Java Flow Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni When writing code like this : long time = System.currentTimeMillis(); Date date = new Date(time); the given exception is thrown. It's a validation exception. This happens when a long (maybe also a double?) is used in a constructor (not in a function call). The following code is a workaround : Date date = new Date(); date.setTime(time); but can be used only when the object we are instantiating have a getter as an alternative to the constructor parameter. I'm having this problem with a fresh (yesterday) checkout of cocoon 2.1.X branch. Don't know yet if this apply to other versions of cocoon. I'm using Blackdown-1.4.2-02 on a 2.6.12-gentoo-r6 linux machine. Googling around it seems that this exception is raised when the data type in a pop2 JVM instruction is not correct. I think this is one of the side-effects of the javaflow BCEL manipulations, but I'm not skilled enought on BCEL and similar stuff to even think of a possible solution. The exception is raised loading the javaflow class, so it will prevent the entire flow (and not only the affected method) to be used. Also, the exception will just tell you that the class is invalid, and not point you to the place in code where this long is used in a constructor, so you'll have to spot it by hand. I can produce a test case to try to narrow it down, but the given 3 lines of code are enought to produce the error in my javaflows. -- 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
[2.2] Support for per sitemap classloading?
Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[2.2] Merging DefaultTreeBuilder and SitemapLanguage
Anyone against merging the DefaultTreeBuilder and the SitemapLanguage class? Currently DTB is abstract and SL is the only sub class of it. And I think although the general nature of the DTB is to be a general tree builder solution, the current implementation is not that general. And the SL will be the only implementation we will provide anyway. If noone objects I'll merge the code soon. (Less classes = easier code) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Support for per sitemap classloading?
On 04.03.2006, at 01:54, Carsten Ziegeler wrote: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). I guess it is just disabled by default because it is a new feature Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. That's how the class auto-compiling reloading works in trunk ...does/will the block framework support that then? cheers -- Torsten smime.p7s Description: S/MIME cryptographic signature
Re: [2.2] Support for per sitemap classloading?
Carsten Ziegeler wrote:
Some time ago the support for per sitemap classloaders has been added to
2.2; this feature is currently disabled (for making the implementation
for blocks easier I guess).
Now the question is, do we want to support this or is this obsolete when
we have the blocks implementation soon? In this case we can simply
remove the classpath handling code, I guess.
yes, you can remove it. Classloading will become a concern of the blocks-fw;
though I have no idea how to add the ReloadingClassloader to the OSGi-based
blocks-fw as this will probably mean extending the functionality of the OSGi
framework that we use. Maybe somebody can pick up this task and find out how
this can be done.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Support for per sitemap classloading?
Torsten Curdt wrote:
On 04.03.2006, at 01:54, Carsten Ziegeler wrote:
Some time ago the support for per sitemap classloaders has been added to
2.2; this feature is currently disabled (for making the implementation
for blocks easier I guess).
I guess it is just disabled by default because it is a new feature
Now the question is, do we want to support this or is this obsolete when
we have the blocks implementation soon? In this case we can simply
remove the classpath handling code, I guess.
That's how the class auto-compiling reloading works in trunk
...does/will the block framework support that then?
Yes, that's the plan. Adding it to
org.apache.cocoon.blocks.servlet.BlocksManager (module:
cocoon-blocks-fw-servlet-impl) shouldn't be too difficult, especially for you ;-)
But as said in my other response to Carsten's mail, adding it to the OSGi
framework (Equinox and/or Felix) will be more difficult. If you have some time,
it would be really great if you could have a look at it. IMO the
ReloadingClassloader is one of the most important features that we should add
(developing [web]apps without it, isn't fun anymore for me).
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[docs] Daisy updated, some new docs
Hi, The Daisy update on the cocoon zone is done. I have also added some new sitemap reference docs, e.g. http://cocoon.zones.apache.org/daisy/documentation/sitemap/reference/pipeline_elements/842.html It's basically a document for each sitemap element, with a short description, the attributes, and a link field holding references to the documents describing the child elements of the sitemap element. It should be complete (for C2.1) but if you notice missing elements or attributes, just let me know or add them yourself. I have left out the container-specific attributes on purpose (pool-min etc.). From time to time I'll try to fill this up with some more content, integrating the old docs etc. - o - To the default CocoonDocument document type, I've added some (optional) fields to allow more query-based navigation and faceted navigation. The fields are: * CocoonBlock: core, forms, portal, ... * CocoonComponentReference: if the document is the reference documentation for some type of Cocoon component (a transformer, a widget), then this is indicated in this field So that allows some more faceted browsing: http://cocoon.zones.apache.org/daisy/documentation/facetedBrowser/default -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Release 2.1.9 (again)
Hi Carsten,
I checked out latest 2.1.X yesterday and had the same problems, nothing
client side (submit on change, other events) worked anymore. The error
was it could not find a lot of dojo related stuff, I just had to add a
match in the sitemap for the dojo javascript :
map:match pattern=resources/dojo/**
map:read src=resource://org/apache/cocoon/dojo/resources/{1}/
/map:match
Now they all work properly again. I haven't yet run a lot of test with
ajax enabled, but at first sight it seems to work better than the old
ajax system.
I don't know if this is your problem, just thought it worth mentioning
the new javascript location and the fact that they are working for me.
Simone
--
Simone Gianni
obiblio cocoon-forms-2.1.8.jar broken?
Hi, It looks like the jar is broken on http://www.ibiblio.org/maven/cocoon/jars/cocoon-forms-2.1.8.jar. When I use the jar I get the error: org.apache.avalon.framework.logger.AbstractLogEnabled.access$201(Lorg/apache/cocoon/forms/binding/JXPathBindingManager;)Lorg/apache/avalon/framework/logger/Logger; org.apache.cocoon.ProcessingException: Error calling flowscript function do_insert at resource://org/apache/cocoon/forms/flow/javascript/Form.js:215:-1 at file:/home/user/mysite/resources/flowscript/cforms.js:30:-1 at file:/home/user/mysite/cforms/persistence-admin/poll/admin.js:8:-1 at map:call - file:/home/user/mysite/cforms/persistence-admin/poll/sitemap.xmap:56:34 at map:mount - file:/home/user/mysite/part/cforms/persistence-admin/sitemap.xmap:30:57 at map:mount - file:/home/user/mysite/part/sitemap.xmap:210:85 at map:mount - file:/home/user/mysite/cocoon/sitemap.xmap:138:59 cause: java.lang.NoSuchMethodError: org.apache.avalon.framework.logger.AbstractLogEnabled.access$201(Lorg/apache/cocoon/forms/binding/JXPathBindingManager;)Lorg/apache/avalon/framework/logger/Logger; When I build cocoon locally it just works fine. Bart -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: [2.2] Support for per sitemap classloading?
Reinhard Poetz wrote: Carsten Ziegeler wrote: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. yes, you can remove it. Great :) One remaining question: currently we have several places where the thread context classloader is used (for example to create new instances). I guess that with the blocks-fw in place that the thread context class loader is not the correct one. Is there anything I can do today to prepare the correct behaviour? Like getting the class loader from the spring bean factory? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Support for per sitemap classloading?
Reinhard Poetz wrote: Carsten Ziegeler wrote: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. yes, you can remove it. Classloading will become a concern of the blocks-fw; though I have no idea how to add the ReloadingClassloader to the OSGi-based blocks-fw as this will probably mean extending the functionality of the OSGi framework that we use. Maybe somebody can pick up this task and find out how this can be done. And one additional question :) In 2.1.x you can configure extra classpath in the web.xml; I think we should remove that feature for blocks-fw as well, right? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Release 2.1.9 (again)
Simone Gianni wrote:
Hi Carsten,
I checked out latest 2.1.X yesterday and had the same problems,
nothing client side (submit on change, other events) worked anymore.
The error was it could not find a lot of dojo related stuff, I just
had to add a match in the sitemap for the dojo javascript :
map:match pattern=resources/dojo/**
map:read src=resource://org/apache/cocoon/dojo/resources/{1}/
/map:match
Hmm... do you really need that?
With the Dojo stuff, I added a map:match
pattern=_cocoon/resources/*/** in the root sitemap, which allows any
block/jar to provide resources, which are mounted at a fixed location
(to increase browser cache efficiency).
Sylvain
--
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member
Re: Release 2.1.9 (again)
Ralph Goers wrote: I am pinging again to see where we stand. AFAIK the only thing we are waiting for is Sylvain's blessing on Ajax. Also, does Ajax need to be marked stable since Forms depends on it? Please wait a few more days (not more, promise!), I'm nearly finished with the new Ajax stuff, and we'll be able to mark Ajax stable also. Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [2.2] Support for per sitemap classloading?
Carsten Ziegeler skrev: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. In the absence of blocks we have developed subsitemaps to handle application modularization. With blocks we have a better concept for modularization, and it is IMO better to focus the role of sitemaps by removing classloading and maybe even deprecating the configuration of components in sitemaps. /Daniel
Re: [2.2] Support for per sitemap classloading?
Reinhard Poetz skrev: Torsten Curdt wrote: On 04.03.2006, at 01:54, Carsten Ziegeler wrote: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). I guess it is just disabled by default because it is a new feature Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. That's how the class auto-compiling reloading works in trunk ...does/will the block framework support that then? What the blocks fw eventually will support depends on what you and others want it to support and are prepared to implement ;) Yes, that's the plan. Adding it to org.apache.cocoon.blocks.servlet.BlocksManager (module: cocoon-blocks-fw-servlet-impl) shouldn't be too difficult, especially for you ;-) But as said in my other response to Carsten's mail, adding it to the OSGi framework (Equinox and/or Felix) will be more difficult. I haven't evaluated all the details, but IMHO the difficulty of adding dynamic classloading in OSGi depends on what you what to achieve. In OSGi classes in the main classloader of a bundle are imported, exported or internal. For classes that a bundle export dynamic class loading is more complicated as all bundles that import the class must be refreeshed when the class is updated. But dynamic classloading in Cocoon has always been about isolated, e.g. sitemap local class loading. As long as we are happy with bundle internal classloading, it shouldn't be much different from the sitemap local dynamic classloading of today. For inter bundle (block) dependencies, you can always stop, update, and restart a bundle and refresh the OSGi framework, and the application will work again with the new code (given that all services are dynamic aware). If you have some time, it would be really great if you could have a look at it. IMO the ReloadingClassloader is one of the most important features that we should add (developing [web]apps without it, isn't fun anymore for me). It should also be noted that Eclipse is based on OSGi and is rather dynamic :) So it should be possible to achieve a high degree of dynamism in OSGi based Cocoon, and we can possibly reuse some Eclipse bundles for convenient application development. /Daniel
Re: Release 2.1.9 (again)
Hi Sylvain,
Sylvain Wallez wrote:
map:match pattern=resources/dojo/**
map:read src=resource://org/apache/cocoon/dojo/resources/{1}/
/map:match
Hmm... do you really need that?
Yep, in my current situation i needed this. I'm not sure why, probably
because we developed custom stylesheets for forms and maybe altered a
bit the default resource uri :)
Simply I thought that since it's working very well here, the simplest
problem for nothing is working anymore could be that JS resources are
not loaded anymore due to the change from resources/ajax/js/ to
resources/dojo, expecially for applications migrating from 2.1.x9 and
2.1.X-9.
With the Dojo stuff, I added a map:match
pattern=_cocoon/resources/*/** in the root sitemap, which allows
any block/jar to provide resources, which are mounted at a fixed
location (to increase browser cache efficiency).
Yep, this is surely the best approach, il try to trim this application
of mine resources path so that it will load directly from the root sitemap.
Sylvain
Simone
--
Simone Gianni
