Re: Fork Xalan?
Bart Molenkamp wrote: Can you tell when this error occurs? Anytime exception happens in the downstream sax pipe; or in xalan itself. Or what to do to avoid it? Do not do bugs! Or don't trigger bugs in Xalan. Vadim Bart. -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Thursday, April 14, 2005 3:17 PM To: Cocoon Developers Subject: Fork Xalan? Hey guys, Here is controversial thought: may be we should fork Xalan? I'm tired of this java.lang.RuntimeException: java.lang.NullPointerException at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:34 18 ) crap... Vadim
Re: Daisy as a docs editor (was Re: [CocoonInAction] Opening announce)
Upayavira wrote: Reinhard Poetz wrote: Ross Gardler wrote: One question: How are approved documents saved again in the SVN repository? Right now, they are not. However, it is my intention to create such a link at some point in the future, but there needs to be some thought about how this will happen, or even if it needs to since the daisy repository is, itself version controlled. ok, you mean replacing the SVN repository and only use Daisy? The content for our site needs to be in SVN. That's how the ASF and board maintain their oversight, they know where to look for IP 'owned' by Apache. If we start storing it elsewhere, we remove the ability for Apache members to know where ASF content is. OK Having said that, there's nothing to stop us using Daisy to maintain the content, and then having some kind of 'hook' to get the edited content back into ASF SVN. How that would work, I don't know, but I'm sure it can be done, somehow! I'll get the basic plugin working and then open a discussion about how to hook into SVN. Ross
Re: Build dependency
Le 19 avr. 05, à 21:06, Martin Geissler a écrit : ...I have found a dependency in the blocks.properties file missing. Meaning that tour depends on slop... Thanks Martin - you're right, the dependency on the slop block is missing for the tour block. I'll correct this asap unless someone beats me to it! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Build dependency
Hello, I have found a dependency in the blocks.properties file missing. Meaning that tour depends on slop. I have testet it with all block excluded, only batic, fop, forms and tour included. The build was sucsessfull, but the samples of the tour won't work. After redoing the build with slop included the tour works fine. Test environment: Windows XP, java 1.4.2_07 Cocoon 2.1.7 Yesterday I have posted a simple .ppt to the wiki at http://wiki.apache.org/cocoon/BlockDescriptions with all the dependencies found in blocks.properties The colors in this .ppt are straightforward: red: deprecated, orange: unstable, green stable hth anyone little bit Martin Martin Geissler Computer Engineering (Certified Engineer) IT Development Manager Internet / Intranet Applications New Projects WIKA Alexander Wiegand GmbH & Co. KG Alexander-Wiegand-Strasse 63911 Klingenberg / Germany Tel +49 9372 132 8924 Fax +49 9372 132 449 [EMAIL PROTECTED]
[CFORMS] NullPointerException in form-validation javascript when javascript debugger is enabled
Hi, I stumbled onto a problem I've noticed before (Cocoon 2.1.5 I think). I was under the impression it was solved, but apparently not. Situation is this: - SVN checkout of BRANCHES - Build a form definition with var success=true; return success;- create a flowscript that handles the form: function myForm() { var form = new Form(myformDef.xml); .etc. } - [1] set enabled in cocoon.xconf. - run cocoon - start function -> nullpointer exception - change [1] to - restart cocoon - start function -> works fine I've traced the code as far as the JavaScriptHelper.buildFunction (line 100). In the ctx.compileFunction lines I noticed that somewhere it called the DebugReader, which could be the problem. It would be nice if someone could fix this, so the Javascript debugger is useful again. Thanks. Bye, Helma van der Linden Medical Informatics University Maastricht POBOX 616 6200 MD Maastricht The Netherlands
Re: Java components in blocks
On Apr 18, 2005, at 12:07 PM, Daniel Fagerstrom wrote: Glen Ezkovich wrote: On Apr 18, 2005, at 7:05 AM, Daniel Fagerstrom wrote: The portal definition files define how individual portlets are invoked and rendered. As I stated before, ideally these would be separate blocks. However, since many will contain java code, it sounds like many portlets would have to be a block with a matching bundle. A block can contain code. It is just (at least in the first step) not allowed to expose components. So if the portlet components need to be accessible from other parts of the system you need both a bundle and a block. But if the components only are needed internally and the portlet can expose all its functionality as pipeline functionality, it is enough with a block. Sorry to be late to the party, but I was unsure where this discussion was headed and choose to keep my mouth shut. I'm glad to see to that blocks can have code again.;-) I think the issue of exposing components is a non issue. Did you read http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111339143403364&w=2 ? Yes We are after all talking about java byte code, if some one wants to use the jar/class file it just needs to be on the classpath. Sure, but what if two blocks contain different versions of a jar? I admit that this is a problem. The way I see this, is that if a block developer is using a jar that may have multiple versions deployed in the cocoon environment they should make sure to deploy that jar local to a sitemap. The issue here is one of deployment, where to locate the class and which ClassLoader will load the class. It seems to me that if we have two component deployment levels, global and sitemap, we can pretty much accomplish the same thing as exposing or not exposing components. If all jars from all blocks are put in a global sitemap it just don't scale. It is hard enough to keep jars in different blocks in synch whithin the Cocoon SVN. When external developers start to develop and distribute their own blocks it will stop working. Agreed. Certain jars should be available cocoon wide and others not. Unfortunately, this must be left up to the blocks developer to decide how a particular jar gets deployed. Just as it is now. Because of that classloader isolation is needed so that a block only is exposed to the classes it actually depend on from its parent classloader. And that is complicated stuff, if you don't think so you can take a look at kernel in whiteboard. I know so. I didn't say it would be easy. Things get more complicated and creates IMO unnecessary dependencies between blocks when you combine it with sitemap functionallity. How so? What is the alternative? Have blocks that have no component dependencies? If a block depends on a component it depends on a component. If a sitemap uses a component it uses a component. Because of that complexity Pier and I prefer to separate the problems. If you separate the problems thats fine with me, but to consider this a complete solution to the total problem which is to have real blocks is a mistake. When I deploy an app, I usually have a custom component or two and a bunch of POJOs. If I want to package an app as a block I would need to package the sitemap and associated files as a block and package the jars as a bundle. A block at the very least should include the bundle. As an app developer I want to have a single deployment solution. As a sys admin, I want to ensure that I don't have 30 copies of identical jars hanging around. I understand that this is a complex problem and breaking it up into smaller pieces is a wise thing to do. My basic points are that to have real blocks you need a single deployment and that there are two levels to deploy Java components, global and sitemap, parent sitemaps included. Initially, to have the choice of deploying Cocoon wide or sitemap wide solves some basic issues. The ultimate solution is much more difficult because of the multiple dependencies a block may have. It may be that it is impossible to solve all possible scenarios. I don't know. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: "If they can get you asking the wrong questions, they don't have to worry about answers." - Thomas Pynchon Gravity's Rainbow
Re: JXTG further development
Leszek Gawron wrote: - make jx:import evaluated while parsing and not at runtime. After reviewing the code I think there is no need for that. This is the current procedure: Parsing: 1. Store expression that will resolve to script uri at runtime Execution: 2. Resolve script uri value 3. Get script from script manager a) lookup from cache b) if not in cache - resolve uri source - parse - store in cache The only thing we skip when itroducing is resolving script uri value at runtime. After first page hit the imported script is cached separately anyway. It has to be looked up anyway - otherwise we get the same problem as today with xslt: you have to touch main xslt if you change the imported ones. Let's leave the feature not changed. -- Leszek Gawron MobileBox [EMAIL PROTECTED] http://www.mobilebox.pl
jx:attribute
I have committed first (really lame) implementation of jx:attribute. Finally you are able to do something like: http://apache.org/cocoon/templates/jx/1.0";> xyz def Could anyone could review the implementation? It is not NS aware yet. -- Leszek Gawron MobileBox [EMAIL PROTECTED] http://www.mobilebox.pl
Filesource questions
Hi, I think org.apache.excalibur.source.impl.FileSource is acting strange when handling temp files: - instead of using File.createTempFile(), it creates a temp file like this: // Create a temp file. It will replace the right one when writing terminates, // and serve as a lock to prevent concurrent writes. File tmpFile = new File(getFile().getPath() + ".tmp"); - furthermore, presumably because of the lock function mentioned in the comment above, it checks for an existing temp file, and throws a concurrent modification exception when it exists. The problem I'm having is that sometimes a .tmp file won't be removed after use. The next time it tries to create a file by the same name, FileSource will throw a concurrent modification exception, and refuses to write. Of course, at that point there is no other process writing the file. There is one other thread[1] where this behaviour is mentioned - when Gianugo was working on flow/webdav - it doesn't seem to have been resolved however . Finally - as an aside - is it really necessary to have Excalibur provide FileSource and factory? A quick browse through cocoon.xconf shows that there are only a few ( albeit very essential ) components that live in excalibur. From my point of view it hinders the transparency of Cocoon - I can't see straight away what filesource does and where it goes wrong. Imho it would be better to have Impl's in cocoon packages, even if the interface lives somewhere else. WDYT? Rogier [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105966223522106&w=2
RE: Fork Xalan?
Can you tell when this error occurs? Or what to do to avoid it? Bart. > -Original Message- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 14, 2005 3:17 PM > To: Cocoon Developers > Subject: Fork Xalan? > > Hey guys, > > Here is controversial thought: may be we should fork Xalan? I'm tired of > this > >java.lang.RuntimeException: java.lang.NullPointerException >at > org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:34 18 > ) > > crap... > > > Vadim
Re: Java components in blocks
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Maybe not, but those are areas that are rather vague anyway, we
where the only ones who thought it had much importance the last
time we discussed it.
Maybe it had the appearance but I can't believe this. (Recently I
had a discussion with Sylvain and he really wants this feature too.
So we are at least three ;-) )
Might be, we still need to know the use cases to provide a good
solution. Any comments to what I suggested in my response? BTW I
rather meant:
var result = cocoon.sendPageAndWait("block:myblockA://confirmDialog",
{msg: "areYouSure"});
A part from that this changes the contract of sendPageAndWait (returns
a continuation),
The response object could be made available in an extra argument
instead. Also we could have VPC flowscript functions as long as their
return values are restricted to what is part of the "core" classloader.
I would prefer the explicit call of flowscript functions of other blocks.
Anything else would have been a suprise to me ;)
I think the usecases are quite clear (reuse a flowscript function of
another block and use it the same way as a local function) but we
shouldn't discuss this ATM. Let's wait until Pier and you have set up
the base infrastructure (Block[s]Manager + some basic classloader
isoluation) and then we will see what is (easily) possible and what not.
Good, it feels rather abstract to discuss whats missing in something we
haven't implemented or tried.
/Daiel
