Ulf Dittmer wrote:Well, the images are not created until the web page in which they appear accesses them (which means that if a JSP page has a cewolf:chart tag, but no corresponding cewolf:img tag, then they aren't created at all).
If a page contains multiple images, then it'll take a while until all are being requested, generated, and returned to the browser (because browsers only send a few requests in parallel). The "Cewolf Set" page of the sample web app is an example of a page where this can be observed.
If this is repeatable behavior -and it probably isn't- then I'd check the web access logs to see if the image requests reach the server, and use something like the Firefox extension LiveHTTPHeaders to see if those requests are sent by the browser. This might provide clues as to what's going on.
Martijn Verburg wrote:You'll want to find out the host OS of the FTP server, that's usually enough to configure your client correctly. Also I assume you've logged in through a Command Line client to check your permissions, home directory etc are OK?
Martijn Verburg wrote:Hi Michael,
Have you tried Apache commons-net? And yes the type of FTP server does matter, there are some subtleties between them and often you have to configure your FTP lib to talk to a particular flavour. _very_ rarely you have to write a plugin to make yours work.
Ulf Dittmer wrote:I'm not sure what you mean by "get a value to my JSP page" - JSP has access to the user's session, so it can retrieve the value.
The "params" Map in the processChart method contains all values that are passed in via cewolf:param tags, so I think adding that single line of JSP code is all it takes to implement this (plus the Java code that retrieves the element from the Map and uses it).
Ulf Dittmer wrote:You can use the JSP EL to pass the value to the postprocessor:
<cewolf:param name="maxXValue" value="${maxXValue}"/>
Assuming that there are no other attributes with that name in the page or request scope, it will get it from the session. Or you can use "${sessionScope.maxXValue}".
David Newton wrote:Define the DAO bean in Spring and include it in the Quartz job bean: you might want to read up on some Spring basics before proceeding too much further; this IoC/DI (Inversion of Control/Dependency Injection) is one of the most basic aspects of Spring. getting a handle on it early will save you a lot of effort.
David Newton wrote:Inject the DAO directly into your Quartz job--that's what Spring is for; why convolute things?
David Newton wrote:That's no bean, that's an action. Spring knows nothing about it.
Struts actions can be Spring beans (or vice-versa, depending on your point of view), but the action class itself would need to be defined as a Spring bean. There's Struts 1-Spring integration, so this is not a big deal.
That said: that's a *bad* idea, there should be no reason why a Quartz job would need to access a Struts action, unless something has gone wrong with your design: that's an inappropriate coupling.
Christophe Verré wrote:You're telling Spring that there is a JobDetailBean class called Myjob in the "path" package. Is the MyJob class in a package called "path" ? I don't see any package declaration in your code.