Re: Cannot call c:import / more than once!

2004-11-06 Thread Mick Wever

  There is a simple solution. In the c:import specify an absolute URL.


 I am having the same issue as you were last month.  I am using OC4J (AS
 10g) and can not c:import nor tiles:insert more than one Struts
action
 on the same JSP.  I saw that you worked around the issue by using an
 absolute URL with c:import.  I tried this too and it does indeed work
 however this results in a distinct request scope such that the request
 scope of the calling JSP is not visible in the included Struts action
(and
 vice versa).  Did you find this too?  Have you found any other
workarounds
 to this issue?  Do you think this is an OC4J issue, a Struts issue, a
JSTL
 issue?  Why do you suppose there is so little written about this problem
 considering that what we are doing seems like it would be an ideal
 architecture?


It does say in the jstl spec for import that if the url is within the same
application context then the environment variables will be pass on, ie
request, response, etc. Struts actions commit to the response so you
cannot use them to include additional data in this way. It worked out well
with an absolute url because we are using a webcache so that the import
was fast enough. I guess your options are to either change the struts
action into just including a jsp page or servlet, or importing an absolute
url and putting the required information in as request parameters to the
url. 
Mick.

ps. please post your question to the mailing list, and then, only if the
thread is old, email me a copy. 

-- 
To be young, really young, takes a very long time. Picasso 
--- www.vetproducts.com.au --- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Cannot call c:import / more than once!

2004-10-14 Thread Mick Wever
On Wed, 13 Oct 2004 13:59:32 -0400, Kris Schneider wrote:

 I'm not sure he actually intended to do multiple forwards, it seems like
 he just wanted to reuse an action to generate some common output. The
 fact that Struts is performing an implicit forward in response to each
 of those imports can be easy to overlook.


Well bugger.
I would go so far as to say that struts is not honouring the contract of
c:import. Nowhere (that I can find, and please quickly point it out if you
can) in the JSTL documentation can I find spec or definition that c:import
'forwards'. It is clearly stated that it imports a URL and never mentions
forwarding.
Taking this further, examples in Sun's 'core JSTL' book actually use
multiple c:import's! So there is the clear indication that the import does
not forward, and struts is breaking this contract...

Should I enter a bug?

Mick.


-- 
---BR/ Everything you can imagine is real. Pablo Picasso
BR/
a href=http://www.harryspractice.com.auHarry's Practice/a
BR/--- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Cannot call c:import / more than once!

2004-10-14 Thread Mick Wever
 It's got nothing to do with JSTL and everything to do with your Struts
 action. The Struts controller effectively performs the forward with the
 result of your action's execute method. Yes, c:import can work perfectly
 well when used multiple times in a page. For URLs that are within the same
 context (same app), the semantics are pretty much the same as
 RequestDispatcher.include.

This is awkward. Is there no way that the Struts could avoid committing
the response when it is called from the import tag.
Simply avoiding the commit, or cloning the response so the original
response is not altered?
Mick



-- 
---BR/ The turtle only makes progress when it's neck is stuck out Rollo May
BR/
a href=http://www.harryspractice.com.auHarry's Practice/a
BR/--- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Cannot call c:import / more than once!

2004-10-14 Thread Mick Wever
On Thu, 14 Oct 2004 07:17:34 -0400, Kris Schneider wrote:

 It's got nothing to do with JSTL and everything to do with your Struts
 action. The Struts controller effectively performs the forward with the
 result of your action's execute method. Yes, c:import can work perfectly
 well when used multiple times in a page. For URLs that are within the same
 context (same app), the semantics are pretty much the same as
 RequestDispatcher.include.

Delving deeper into the JSTL defintion for c:import it does mentioned that
if the url is relative and within the same context then the
RequestProcessor.include is used, and the entire environment is available.

There is a simple solution. In the c:import specify an absolute URL.
So the code below works just fine:

%@ taglib uri=c.tld prefix=c %

c:forEach items=${listOfNumbers} var=number
c:import url=http://myServer/myContext/myAction.do?number=${number}/
br/
/c:forEach


Mick.

ps Thanks for your explanation and reference to RequestProcessor.include, without 
this I would not have found the small print ;=)


-- 
---BR/ Great spirits have always encountered violent opposition from mediocre 
minds. 
Albert Einstein
BR/
a href=http://www.harryspractice.com.auHarry's Practice/a
BR/--- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: FieldChecks change signature and no longer returns value

2004-10-14 Thread Mick Wever
 Gentoo now has the latest version.
You're responsible for the ebuild? Thanks!
But doesn't build:

 Source unpacked.
Buildfile: build.xml does not exist!
Build failed

Mick.
-- 
---BR/ The reward of patience is patience. St. Augustine
BR/
a href=http://www.harryspractice.com.auHarry's Practice/a
BR/--- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Cannot call c:import / more than once!

2004-10-13 Thread Mick Wever
I think I've got a very annoying 
Response has already been committed problem narrowed down...

The follwing jsp code does not work for me:

%@ taglib uri=c.tld prefix=c %

c:forEach items=${listOfNumbers} var=number
c:import url=/customAction.do?number=${number}/
br/
/c:forEach  

Because during the c:import the response is committed, and when the
second (or third) c:import executes it dumps Response has already been
committed. So somewhere between 
org.apache.taglibs.standard.common.core.ImportSupport.doEndTag(:179) and
org.apache.struts.action.RequestProcessor.processActionPerform(:421)
my response is getting committed.
Does anyone know where this would be?
Or has anyone experienced this problem before?
Or even better, can someone give me a solution to get around this?

I'm using struts-1.2.4, and Oracle's OC4J (Orion).
The following stacktrace hints at the methods involved between the
c:import and customAction:

at 
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:765)
at 
com.evermind.server.http.ServletRequestDispatcher.include(ServletRequestDispatcher.java:121)
at 
com.evermind.server.http.GetParametersRequestDispatcher.newInclude(GetParametersRequestDispatcher.java:80)
at 
com.evermind.server.http.GetParametersRequestDispatcher.include(GetParametersRequestDispatcher.java:34)
at 
org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString(ImportSupport.java:314)
at 
org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag(ImportSupport.java:179)

Mick.

-- 
---BR/ You must be the change you wish to see in the world. Gandhi
BR/
a href=http://www.harryspractice.com.auHarry's Practice/a
BR/--- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



FieldChecks change signature and no longer returns value

2004-10-12 Thread Mick Wever
After updating to version 1.2.2 FieldsCheck.checkInteger(..) now returns a
boolean indicating success rather the value.
This has broken our code and we need the value.
Is there a substitute method now?

Mick.

-- 
BR/ It is not enough to have a good mind; the main thing is to use it well. 
Descartes



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: FieldChecks change signature and no longer returns value

2004-10-12 Thread Mick Wever

 After updating to version 1.2.2
 FieldsCheck.validateInteger(..) now returns a boolean indicating success
 rather the value. This has broken our code and we need the value. Is
 there a substitute method now?

I've tracked this down to a patch done under bug#26413.
http://issues.apache.org/bugzilla/show_bug.cgi?id=26413 
Changing signatures like this is bad API development.

This change has royally screwed me.
Now I have to copy _ALL_ of the code in FieldChecks.validateInteger(..)
into our application just to get the value again.

IMHO it would have been much much better api development to provide
wrapper methods around the existing validateXXX methods that provided the
fix you wanted.

For example:

public static boolean validatableInteger(Object bean,
  ValidatorAction va, Field field,
  ActionMessages errors,
  HttpServletRequest request) {
return validateInteger(bean,va,field,errors,request) == null
 ? false : true;
}


This would not break the API, and would solve this issue. 
I'm not sure validatable is a word? But you get my drift.

Mick

-- 
BR/ It is not enough to have a good mind; the main thing is to use it well. 
Descartes



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: FieldChecks change signature and no longer returns value

2004-10-12 Thread Mick Wever
 Version 1.2.2 was downgraded from ga quality because of problems so its
 not a good idea to use it in general. Current release version is 1.2.4 and
 this issue was fixed in that version.

Sorry, failed to look that far ahead :$
Gentoo, unfortunately is still publishing 1.2.2 :(


 P.S. I assume you meant FieldsCheck.validateInteger(..)  rather than
 checkInteger()

Yes, indeed.


-- 
BR/ The ultimate measure of a man is not where he stands in moments of comfort and 
convenience but where he stands at times of challenge and controversy. Martin Luther 
King



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Links relative to jsp not action in Opera

2004-05-26 Thread Mick Wever
When our webpages are viewed with opera all our links are relative to the
jsp used (within tiles) not the actual url/action given.
Is there some way of changing the response so that the url is correct and
relative links don't reference the jsp?
Mick.

-- 
-- BR/
It is not enough to have a good mind; the main thing is to use it well. Descartes
BR/ --- a href=http://www.harryspractice.com.auHarry's Practice/a --- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Links relative to jsp not action in Opera

2004-05-26 Thread Mick Wever
On Wed, 26 May 2004 07:14:52 -0400, James Mitchell wrote:
 Opera should know nothing about your jsp, unless you are doing something
 else wrong.  Are you using redirects or forwards?

Indeed I would think so too. There are naturally no differents in the html
source between the different browsers, and the links are definitely
relative, but Opera bases the links relative to the last requested jsp not
the request url, hence this last-requested-jsp information must be stored
somewhere in the response... 
So, how to I change it back to the original request url before the
response is sent?
Mick

ps there are forwards and tiles involved.

-- 
-- BR/
To be young, really young, takes a very long time. Picasso
BR/ --- a href=http://www.harryspractice.com.auHarry's Practice/a --- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Links relative to jsp not action in Opera

2004-05-26 Thread Mick Wever
On Wed, 26 May 2004 13:28:23 +0200, Kransen, J. wrote:

 Do you have a base tag inside your htmlhead ?

No, but I'm playing around with that now...
One problem that arises from using the base tag is browser
differences: 
IE: server name and port required in base href 
Firefox: base tag doesn't work at all 
Opera: works great.

Mick.


-- 
-- BR/
When prosperity comes, do not use all of it. Confucius
BR/ --- a href=http://www.harryspractice.com.auHarry's Practice/a --- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Links relative to jsp not action in Opera

2004-05-26 Thread Mick Wever
On Wed, 26 May 2004 13:49:34 +0200, Kransen, J. wrote:

 You probably already know, but you can use Struts html:base/ tag to
 dynamically create the base tag. This works great as you don't have to edit
 the tag if you move the page or change the server for example. It also
 creates the full http://host/webapp/page.jsp;

I'm not sure on how to use the htmml:base tag in the opposite manner, ie
the href to be that of the struts action's path not the jsp's path?

Mick

[The other problem here is in a clustor the server must be the virtual
host fronting the clustor not the localhost, although this can be solved
it's just an extra pain.]

-- 
-- BR/
Only those who risk going too far can possibly know how far they can really go. T.S. 
Eliot
BR/ --- a href=http://www.harryspractice.com.auHarry's Practice/a --- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Links relative to jsp not action in Opera

2004-05-26 Thread Mick Wever
On Wed, 26 May 2004 14:52:08 +0200, Kransen, J. wrote:
 I'm not sure on how to use the html:base tag in the opposite manner, ie
 the href to be that of the struts action's path not the jsp's path?
 
 Indeed it seems impossible to create a base tag containing an action path
 instead of a jsp path, or at least it didn't work for me. I assume your jsps
 are not in the root? I once had difficulties with the base tag with jsps
 not in the webapp root. I ended up placing the jsps in the webapp root. Not
 sure if this is an option for your project, but maybe you can do the same?

Ended up just using base (base/) tag directly, with a coded
correct base url (virtual hostname, port, web context, and action path). A
bit messy just to satisfy one browser, but i guess #*% happens. It would
have been nice to exclude the action path from the base url making all
relative links relative to the base of the webcontext but... firefox
doesn't honour the base tag! 

Thanks for the help Jeroen.

Mick.

-- 
-- BR/
Living on Earth is expensive, but it does include a free trip around the sun every 
year. Unknown
BR/ --- a href=http://www.harryspractice.com.auHarry's Practice/a --- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How to renderize a image?

2004-05-26 Thread Mick Wever
On Wed, 26 May 2004 10:26:34 -0300, Paulo Rezende wrote:
 It's a way but I really dont like it. If I copy all the fields of a table
 to properties of the form, why i dont can copy also the image to a Blob in
 the form and use it? Do I need to create another connection with db and
 run another sql only to get the image?

Yes you'll need separate db calls. Images are always separate urls and are
not 'embedded' into the html.
Your picture servlet will look something like below so it's not like there
is really a lot of extra work involved.


String format = ...;
byte[] data = ...;
try{
response.reset();
response.setContentType(format);
ServletOutputStream ss = response.getOutputStream();
ss.write(data);
ss.close();
}catch(IOException io){
LOG.error(PictureServlet.doGet +io);
}

Mick.

-- 
-- BR/
As you go the way of life, you will see a great chasm. Jump. It is not as wide as you 
think. Native American Initiation Rite
BR/ --- a href=http://www.harryspractice.com.auHarry's Practice/a --- 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]