RE: Page breaking infinite loop
A little musing on the infinite loop issue... It seems that, for the most part, each layout manager turns predominately to its children LMs to see what they're up to. As a result, it's not easy to spot at a high level (ala the PageLayoutManager) that some singular element is holding the entire works up. In the case of one of my stripped-down infinite loop tests, it's a single string of text that is constantly spilling off the page. The only indication I can seem to locate in code that its TextLayoutManager is not making progress in laying it out is that, at every time its getNextBreakPoss() method is called, it can poll itself to see what character in its internal array it's starting the positioning at, and discover that, call after call, it's making no progress and trying to constantly reposition the same string starting at the same character number...every time. I'm suspecting that, in general, these low men on the totem pole are the only LMs in any position to spot the abject lack of progress that characterizes the infinite loop. At that point, they need to send a notice up the line that they suspect an infinite loop. Now, here's the hard part as I see it- our users are defining page sequences of variable size, and so it just might take many iterations in general to finally reach a page with room for the object in question. Would the correct policy in this case be for there to be a callback process from the low-level LMs to send messages up the line back to their PageLMs so that they can keep an eye on the page sequencing and, after all possible pages have been tried, give up? Or would an acceptable solution to the maintenance branch (which is a dead-end branch) just be to let the cycle run for, say, 20 iterations and, at that time, assume an infinite loop and throw an Exception to break the cycle? -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 3:56 AM To: FOP Subject: Re: Page breaking infinite loop On Wed, 2002-09-18 at 20:38, Christian Geisert wrote: Go for it! (don't forget to assign the bug to yourself) By the way .. any comments from you (as a classloader expert ;-) on the following bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255 If you want to fix that bug why not simply do a null check and maybe try the system class loader. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Page breaking infinite loop
Sounds reasonable. Depending on certain things, though, the system classloader might not be able to find the classes. I asked the guy in charge of deployment at my workplace where we kept FOP under Apache 4.0.4, and he said we kept it in Apache's common-lib folder, so perhaps the best way to combat this is with documentation? Like I said...it's been my experience that, if you put it in the right place, FOP works fine under TC 4.0.4 -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Thu 9/19/2002 3:56 AM To: FOP Cc: Subject: Re: Page breaking infinite loop On Wed, 2002-09-18 at 20:38, Christian Geisert wrote: Go for it! (don't forget to assign the bug to yourself) By the way .. any comments from you (as a classloader expert ;-) on the following bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255 If you want to fix that bug why not simply do a null check and maybe try the system class loader. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] winmail.dat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Page breaking infinite loop
Rhett Aultman schrieb: I'm having a very involved working weekend this weekend, and I'm writing my list of things to do. There's some openings in it, and I thought I might tackle the infinite loop that occurs in the page breaking test as has been documented in some previous bugs in our Bugzilla. Before I settled in to that, though, I wanted to make sure my effort wasn't being repeated elsewhere. I haven't seen anyone resolve the bug, so I'm assuming it's still needing work. Is anyone else out there working on this, or should I roll up my sleeves and get to it? Go for it! (don't forget to assign the bug to yourself) By the way .. any comments from you (as a classloader expert ;-) on the following bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255 Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Page breaking infinite loop
I'll make the bug assignment. As for the bug mentioned, FOP can't be embedded in Tomcat 4.0.4, I have to say this- we've been using various versions of FOP under Tomcat 4.0.4 for a while...at least, until my supervisor switched us to Jetty. Everything ran fine. I have made no *EXPLICIT* attempt at reproducing that bug, but I can make some guesses on what might be going on. I mentioned this in a previous post, but I'll speculate it again- what I think is happening in this case is a function of where the FOP classes were getting loaded from. Clearly, this person wasn't packing FOP in a WAR, since if that were the case, no class packed in a WAR could get to its own classloader, which would mean web applications of all kinds (including some I've written here at FCCI) would have experienced this problem in Tomcat 4.0.4. So, my best guess, without having analyzed Tomcat 4.0.4 source, would be that they are putting FOP in a directory that's loading classes Tomcat wants to keep protected from other parts of the program being able to access. I suppose that they could load classes with a classloader that would kill the classloader reference of the Class object for the sake of internal security. Quite why they would want to do this, I have no idea, but like I said, I haven't read much TC 4.0.4 source to know. The bug report says it was due to a change in security, so it just might have something to do with allowing applications in WARs to have access to classes loaded by some library classloader, but denying them access to that classloader, which I guess would be a technique to prevent web applications from having access to a classloader that has domain over lots of Tomcat internals. That seems like a bit of a roundabout to go through, but it might be what's going on. I can say right now that I suspect I will have enough time this weekend to work on one thing we'd like cleared up. If you guys would rather see the root of this TC 4.0.4 classloader bug pinned down, I can work on that instead. I really just want to put my effort where it's needed I'm not sure when I became a classloader expert, but I won't complain. ;) -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 2:39 PM To: [EMAIL PROTECTED] Subject: Re: Page breaking infinite loop Rhett Aultman schrieb: I'm having a very involved working weekend this weekend, and I'm writing my list of things to do. There's some openings in it, and I thought I might tackle the infinite loop that occurs in the page breaking test as has been documented in some previous bugs in our Bugzilla. Before I settled in to that, though, I wanted to make sure my effort wasn't being repeated elsewhere. I haven't seen anyone resolve the bug, so I'm assuming it's still needing work. Is anyone else out there working on this, or should I roll up my sleeves and get to it? Go for it! (don't forget to assign the bug to yourself) By the way .. any comments from you (as a classloader expert ;-) on the following bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255 Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
