You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Cherry Development (JIRA)" <ta...@jakarta.apache.org> on 2005/08/17 03:24:01 UTC
[jira] Created: (TAPESTRY-569) WebResponse does not expose a way to set headers
WebResponse does not expose a way to set headers
------------------------------------------------
Key: TAPESTRY-569
URL: http://issues.apache.org/jira/browse/TAPESTRY-569
Project: Tapestry
Type: Bug
Components: Framework
Versions: 4.0
Reporter: Cherry Development
I'm trying to puzzle over this one...
The HttpServletResponse object has been made completely inaccessible through any non-depricated part of the Tapestry API. Instead we have the WebResponse object. The WebResponse has a convenience method for setting date headers on it, but absolutely no way to set headers that are NOT dates. Why would we be given access to set headers that should be formatted as dates, but not any others?
I've been searching on the forums and mailing list and I've seen several requests for this sort of functionality. So far, it seems the only supported way of doing this in Tapestry 4 is to create a new hivemind service so that it can access the tapestry.globals.HttpServletResponse hivemind service. Now, suddenly, we're being dropped into a much lower-level API and one I'm completely unfamiliar with, Hivemind, just so that I can stream a file to the user, which requires me to be able to set arbitrary headers. It seems that if this is a conscious decision, that would mean that the scope of what Tapestry allows the developer to do, without having to resort to a lower-level API (which is beyond the scope of Hibernate itself) no longer includes being able to stream files. I've also read that one of Howard's stated goals in using IoC is to expose the developer to fewer and fewer API's. Now, I'm finding that I'm being forced to be exposed to ANOTHER API, just to do something that I was able to take for granted in Tapestry 3.0. It's possible that a dedicated, built-in Tapestry service that represents a higher-level interface for being able to send files to a user might be more appropriate to the long-term goals of the project, so long as it hides the details of Hivemind. I am classifying this as a Major priority bug, since it represents a regression of functionality in the scope of the Tapestry projcet, without a simple workaround. In the meantime, I'll have to use the deprecated RequestContext to get a handle to the raw HttpServletResponse object.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-569) WebResponse does not expose a way to set headers
Posted by "Cherry Development (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-569?page=comments#action_12319087 ]
Cherry Development commented on TAPESTRY-569:
---------------------------------------------
Thanks for your reply, Howard.
Doing an inject seems like it would work fine for a page, which is actually how I intend to use it. As I understand, though, you can't do an inject for a EngineService without declaring it in a hivemind.xml file. It appears that PortletResponse doesn't actually allow you to do anything, at least at the moment (all the methods that would actually let you output any data are unimplemented). In addition, WebResponse does give you an interface for setting arbitrary headers, as long as the header value is a date. This seems somewhat inconsistent. I'd like to formally recommend the following changes:
Interface:
Add a setHeader(String name, String value) method to the WebResponse interface.
Should a setIntHeader method be added for completeness?
Implementation:
Have ServletWebResponse.setHeader method call the setHeader method on the HttpServletResponse
Change ServletWebResponse.getOutputStream so that the call to contentType.getMimeType() is changed to contentType.toString(), for correctness and consistency with the getPrintWriter method.
> WebResponse does not expose a way to set headers
> ------------------------------------------------
>
> Key: TAPESTRY-569
> URL: http://issues.apache.org/jira/browse/TAPESTRY-569
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Cherry Development
>
> I'm trying to puzzle over this one...
> The HttpServletResponse object has been made completely inaccessible through any non-depricated part of the Tapestry API. Instead we have the WebResponse object. The WebResponse has a convenience method for setting date headers on it, but absolutely no way to set headers that are NOT dates. Why would we be given access to set headers that should be formatted as dates, but not any others?
> I've been searching on the forums and mailing list and I've seen several requests for this sort of functionality. So far, it seems the only supported way of doing this in Tapestry 4 is to create a new hivemind service so that it can access the tapestry.globals.HttpServletResponse hivemind service. Now, suddenly, we're being dropped into a much lower-level API and one I'm completely unfamiliar with, Hivemind, just so that I can stream a file to the user, which requires me to be able to set arbitrary headers. It seems that if this is a conscious decision, that would mean that the scope of what Tapestry allows the developer to do, without having to resort to a lower-level API (which is beyond the scope of Hibernate itself) no longer includes being able to stream files. I've also read that one of Howard's stated goals in using IoC is to expose the developer to fewer and fewer API's. Now, I'm finding that I'm being forced to be exposed to ANOTHER API, just to do something that I was able to take for granted in Tapestry 3.0. It's possible that a dedicated, built-in Tapestry service that represents a higher-level interface for being able to send files to a user might be more appropriate to the long-term goals of the project, so long as it hides the details of Hivemind. I am classifying this as a Major priority bug, since it represents a regression of functionality in the scope of the Tapestry projcet, without a simple workaround. In the meantime, I'll have to use the deprecated RequestContext to get a handle to the raw HttpServletResponse object.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Closed: (TAPESTRY-569) WebResponse does not expose a way to set headers
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-569?page=all ]
Howard M. Lewis Ship closed TAPESTRY-569:
-----------------------------------------
Fix Version: 4.0
Resolution: Fixed
> WebResponse does not expose a way to set headers
> ------------------------------------------------
>
> Key: TAPESTRY-569
> URL: http://issues.apache.org/jira/browse/TAPESTRY-569
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Cherry Development
> Assignee: Howard M. Lewis Ship
> Fix For: 4.0
>
> I'm trying to puzzle over this one...
> The HttpServletResponse object has been made completely inaccessible through any non-depricated part of the Tapestry API. Instead we have the WebResponse object. The WebResponse has a convenience method for setting date headers on it, but absolutely no way to set headers that are NOT dates. Why would we be given access to set headers that should be formatted as dates, but not any others?
> I've been searching on the forums and mailing list and I've seen several requests for this sort of functionality. So far, it seems the only supported way of doing this in Tapestry 4 is to create a new hivemind service so that it can access the tapestry.globals.HttpServletResponse hivemind service. Now, suddenly, we're being dropped into a much lower-level API and one I'm completely unfamiliar with, Hivemind, just so that I can stream a file to the user, which requires me to be able to set arbitrary headers. It seems that if this is a conscious decision, that would mean that the scope of what Tapestry allows the developer to do, without having to resort to a lower-level API (which is beyond the scope of Hibernate itself) no longer includes being able to stream files. I've also read that one of Howard's stated goals in using IoC is to expose the developer to fewer and fewer API's. Now, I'm finding that I'm being forced to be exposed to ANOTHER API, just to do something that I was able to take for granted in Tapestry 3.0. It's possible that a dedicated, built-in Tapestry service that represents a higher-level interface for being able to send files to a user might be more appropriate to the long-term goals of the project, so long as it hides the details of Hivemind. I am classifying this as a Major priority bug, since it represents a regression of functionality in the scope of the Tapestry projcet, without a simple workaround. In the meantime, I'll have to use the deprecated RequestContext to get a handle to the raw HttpServletResponse object.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-569) WebResponse does not expose a way to set headers
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-569?page=comments#action_12318958 ]
Jesse Kuhnert commented on TAPESTRY-569:
----------------------------------------
Ouch, and I suppose I could have saved us both the trouble by actually looking at my code before I pasted it...You just need to create a new ContentType instance, which I'm assuming you'll need to change from text/html anyways if you are trying to make someones web-browser launch a particular application..After that you can set all the headers you want via ContentType.setParameter...
Now that I'm looking at it again I'm guessing that howard disabled the ability to set headers on WebResponse on purpose because there shouldn't really be a scenerio where someone needs to do this on an html response, but I could be wrong.
> WebResponse does not expose a way to set headers
> ------------------------------------------------
>
> Key: TAPESTRY-569
> URL: http://issues.apache.org/jira/browse/TAPESTRY-569
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Cherry Development
>
> I'm trying to puzzle over this one...
> The HttpServletResponse object has been made completely inaccessible through any non-depricated part of the Tapestry API. Instead we have the WebResponse object. The WebResponse has a convenience method for setting date headers on it, but absolutely no way to set headers that are NOT dates. Why would we be given access to set headers that should be formatted as dates, but not any others?
> I've been searching on the forums and mailing list and I've seen several requests for this sort of functionality. So far, it seems the only supported way of doing this in Tapestry 4 is to create a new hivemind service so that it can access the tapestry.globals.HttpServletResponse hivemind service. Now, suddenly, we're being dropped into a much lower-level API and one I'm completely unfamiliar with, Hivemind, just so that I can stream a file to the user, which requires me to be able to set arbitrary headers. It seems that if this is a conscious decision, that would mean that the scope of what Tapestry allows the developer to do, without having to resort to a lower-level API (which is beyond the scope of Hibernate itself) no longer includes being able to stream files. I've also read that one of Howard's stated goals in using IoC is to expose the developer to fewer and fewer API's. Now, I'm finding that I'm being forced to be exposed to ANOTHER API, just to do something that I was able to take for granted in Tapestry 3.0. It's possible that a dedicated, built-in Tapestry service that represents a higher-level interface for being able to send files to a user might be more appropriate to the long-term goals of the project, so long as it hides the details of Hivemind. I am classifying this as a Major priority bug, since it represents a regression of functionality in the scope of the Tapestry projcet, without a simple workaround. In the meantime, I'll have to use the deprecated RequestContext to get a handle to the raw HttpServletResponse object.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Assigned: (TAPESTRY-569) WebResponse does not expose a way to set headers
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-569?page=all ]
Howard M. Lewis Ship reassigned TAPESTRY-569:
---------------------------------------------
Assign To: Howard M. Lewis Ship
> WebResponse does not expose a way to set headers
> ------------------------------------------------
>
> Key: TAPESTRY-569
> URL: http://issues.apache.org/jira/browse/TAPESTRY-569
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Cherry Development
> Assignee: Howard M. Lewis Ship
>
> I'm trying to puzzle over this one...
> The HttpServletResponse object has been made completely inaccessible through any non-depricated part of the Tapestry API. Instead we have the WebResponse object. The WebResponse has a convenience method for setting date headers on it, but absolutely no way to set headers that are NOT dates. Why would we be given access to set headers that should be formatted as dates, but not any others?
> I've been searching on the forums and mailing list and I've seen several requests for this sort of functionality. So far, it seems the only supported way of doing this in Tapestry 4 is to create a new hivemind service so that it can access the tapestry.globals.HttpServletResponse hivemind service. Now, suddenly, we're being dropped into a much lower-level API and one I'm completely unfamiliar with, Hivemind, just so that I can stream a file to the user, which requires me to be able to set arbitrary headers. It seems that if this is a conscious decision, that would mean that the scope of what Tapestry allows the developer to do, without having to resort to a lower-level API (which is beyond the scope of Hibernate itself) no longer includes being able to stream files. I've also read that one of Howard's stated goals in using IoC is to expose the developer to fewer and fewer API's. Now, I'm finding that I'm being forced to be exposed to ANOTHER API, just to do something that I was able to take for granted in Tapestry 3.0. It's possible that a dedicated, built-in Tapestry service that represents a higher-level interface for being able to send files to a user might be more appropriate to the long-term goals of the project, so long as it hides the details of Hivemind. I am classifying this as a Major priority bug, since it represents a regression of functionality in the scope of the Tapestry projcet, without a simple workaround. In the meantime, I'll have to use the deprecated RequestContext to get a handle to the raw HttpServletResponse object.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-569) WebResponse does not expose a way to set headers
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-569?page=comments#action_12319079 ]
Howard M. Lewis Ship commented on TAPESTRY-569:
-----------------------------------------------
WebResponse is the lowest common denominator of HttpServletResponse and PortletResponse.
PortletResponse doesn't allow for headers to be set because that's just the way Portlets work.
The HttpServletResponse is still accessible,
@InjectObject("service:tapestry.globals.HttpServletResponse")
public abstract HttpServletResponse getResponse();
You'll get a global proxy that internally delegates to the per-thread/per-request instance. Of course, this will not work for portlet Tapestry.
Another option is to extend WebResponse to implement those methods, and have PortletWebResponse throw UnsupportedOpertaionException. There is precedent for that as well.
> WebResponse does not expose a way to set headers
> ------------------------------------------------
>
> Key: TAPESTRY-569
> URL: http://issues.apache.org/jira/browse/TAPESTRY-569
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Cherry Development
>
> I'm trying to puzzle over this one...
> The HttpServletResponse object has been made completely inaccessible through any non-depricated part of the Tapestry API. Instead we have the WebResponse object. The WebResponse has a convenience method for setting date headers on it, but absolutely no way to set headers that are NOT dates. Why would we be given access to set headers that should be formatted as dates, but not any others?
> I've been searching on the forums and mailing list and I've seen several requests for this sort of functionality. So far, it seems the only supported way of doing this in Tapestry 4 is to create a new hivemind service so that it can access the tapestry.globals.HttpServletResponse hivemind service. Now, suddenly, we're being dropped into a much lower-level API and one I'm completely unfamiliar with, Hivemind, just so that I can stream a file to the user, which requires me to be able to set arbitrary headers. It seems that if this is a conscious decision, that would mean that the scope of what Tapestry allows the developer to do, without having to resort to a lower-level API (which is beyond the scope of Hibernate itself) no longer includes being able to stream files. I've also read that one of Howard's stated goals in using IoC is to expose the developer to fewer and fewer API's. Now, I'm finding that I'm being forced to be exposed to ANOTHER API, just to do something that I was able to take for granted in Tapestry 3.0. It's possible that a dedicated, built-in Tapestry service that represents a higher-level interface for being able to send files to a user might be more appropriate to the long-term goals of the project, so long as it hides the details of Hivemind. I am classifying this as a Major priority bug, since it represents a regression of functionality in the scope of the Tapestry projcet, without a simple workaround. In the meantime, I'll have to use the deprecated RequestContext to get a handle to the raw HttpServletResponse object.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-569) WebResponse does not expose a way to set headers
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-569?page=comments#action_12318957 ]
Jesse Kuhnert commented on TAPESTRY-569:
----------------------------------------
I think you will learn to love the ability to plug things in via hivemind, but I'm not completely sure why WebResponse doesn't have the ability to set headers either...~but~
Here is a certain fileview service I created for my own webapp which should sort of handle what you are doing, and since I can see that you mentioned hibernate it will probably be even easier to use..(Mine hasn't been used for anything other than this one, so you will have to re-factor it yourself to view any file...
Add this to your hivemodule.xml (or something like it):
<service-point id="fileview" interface="org.apache.tapestry.engine.IEngineService">
<invoke-factory model="primitive">
<construct class="com.eko.app.tapestry.services.FileViewService">
<set-object property="response" value="service:tapestry.globals.WebResponse"/>
<set-object property="exceptionReporter" value="service:tapestry.error.RequestExceptionReporter"/>
<set-object property="linkFactory" value="service:tapestry.url.LinkFactory" />
<set-object property="session" value="service:cims.SessionProxy" />
</construct>
</invoke-factory>
<interceptor service-id="hivemind.LoggingInterceptor" />
</service-point>
<contribution configuration-id="tapestry.services.FactoryServices">
<service object="service:fileview" name="fileview" />
</contribution>
Here is the class I'm using, I'm injecting my hibernate sessions which are automatically bound to a thread by a service, but I think you can figure that part out:
/**
* @author Jesse Kuhnert
*/
public class FileViewService implements IEngineService {
/** Logger */
private static final Logger log = Logger.getLogger(FileViewService.class);
/** Service name */
public static final String SERVICE_NAME = "fileview";
/** Case file being served for */
public static final String CASE_ID = "caseid";
/** File id */
public static final String FILE_ID = "fileid";
/** exception handler */
private RequestExceptionReporter exceptionReporter;
/** builds links */
private LinkFactory linkFactory;
/** servlet response */
private WebResponse response;
/** Hibernate DB session */
private Session session;
/**
* {@inheritDoc}
*/
public ILink getLink(IRequestCycle cycle, boolean post, Object parameter)
{
Defense.isAssignable(parameter, Object[].class, "parameters");
Form form = (Form) ((Object[]) parameter)[0];
Map parameters = new HashMap();
parameters.put(ServiceConstants.SERVICE, SERVICE_NAME);
parameters.put(CASE_ID, String.valueOf(form.getCase().getId()));
parameters.put(FILE_ID, String.valueOf(form.getId()));
parameters.put("file", "/form.pdf");
log.debug("Now trying to construct the service link.");
return linkFactory.constructLink(cycle, post, parameters, true);
}
/**
* {@inheritDoc}
*/
public String getName()
{
return SERVICE_NAME;
}
/**
* {@inheritDoc}
*/
public void service(IRequestCycle cycle) throws IOException
{
Long caseID = new Long(cycle.getParameter(CASE_ID));
Long formID = new Long(cycle.getParameter(FILE_ID));
log.debug("service()");
PreparedStatement ps = null;
ResultSet rs = null;
try {
ContentType pdfType = new ContentType("application/pdf");
pdfType.setParameter("Content-disposition",
"attachment; filename=form.pdf");
OutputStream output = response.getOutputStream(pdfType);
log.debug("Rendering response to client.");
// Don't actually care about the caseid...Wanted caseid in there,
// just in case we decide to actually allow more than just pdfs to
// be associated with a case...like images/scanned docs/etc...
Form form = (Form) session.load(Form.class, formID);
Connection conn = session.connection();
ps = conn.prepareStatement(" select pdf_bin from dev_casePdfs where "
+ " form_id = ? ");
ps.setLong(1, form.getId());
rs = ps.executeQuery();
if (rs.next()) {
Blob blob = rs.getBlob(1);
DataInputStream blobStream = new DataInputStream(blob
.getBinaryStream());
long length = blob.length();
byte[] pdfData = new byte[(int) length];
blobStream.readFully(pdfData);
blobStream.close();
response.setContentLength(pdfData.length);
// I've seen a few bits of wierdness (including a JVM crash)
// inside
// this code.
// Hopefully, its a multi-threading problem that can be resolved
// by synchronizing.
synchronized (this) {
output.write(pdfData);
}
}
} catch (Throwable ex) {
exceptionReporter.reportRequestException(
"Error creating file stream for formID:" + formID
+ " on caseID:" + caseID, ex);
} finally {
try {
if (rs != null) rs.close();
} catch (Exception et) {
}
try {
if (ps != null) ps.close();
} catch (Exception et) {
}
}
}
/** @since 4.0 */
public void setExceptionReporter(RequestExceptionReporter exceptionReporter)
{
this.exceptionReporter = exceptionReporter;
}
/** @since 4.0 */
public void setLinkFactory(LinkFactory linkFactory)
{
this.linkFactory = linkFactory;
}
/** @since 4.0 */
public void setResponse(WebResponse response)
{
this.response = response;
}
/**
* Sets the DB session to use to retrieve file.
*
* @param session
*/
public void setSession(Session session)
{
this.session = session;
}
And here is an example of me using it in html + page spec:
<span style="float:none;margin-left:20px; display:inline-block;"
id="pdfViewer"
onclick="javascript:window.open(document.getElementById('pdfViewer').href,'View File', 'height=600,width=600,location=true'); return false;"
jwcid="pdfViewer"
>View <img src="./images/16x16/acroread.gif"/></span>
page spec:
<component id="pdfViewer" type="ServiceLink" >
<binding name="service" value="ognl:'fileview'" />
<binding name="parameters" value="ognl:{selectedForm}" />
</component>
God this seems like a completely inappropriate place for me to have put this...Maybe i'll move it to the wiki later.
> WebResponse does not expose a way to set headers
> ------------------------------------------------
>
> Key: TAPESTRY-569
> URL: http://issues.apache.org/jira/browse/TAPESTRY-569
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Cherry Development
>
> I'm trying to puzzle over this one...
> The HttpServletResponse object has been made completely inaccessible through any non-depricated part of the Tapestry API. Instead we have the WebResponse object. The WebResponse has a convenience method for setting date headers on it, but absolutely no way to set headers that are NOT dates. Why would we be given access to set headers that should be formatted as dates, but not any others?
> I've been searching on the forums and mailing list and I've seen several requests for this sort of functionality. So far, it seems the only supported way of doing this in Tapestry 4 is to create a new hivemind service so that it can access the tapestry.globals.HttpServletResponse hivemind service. Now, suddenly, we're being dropped into a much lower-level API and one I'm completely unfamiliar with, Hivemind, just so that I can stream a file to the user, which requires me to be able to set arbitrary headers. It seems that if this is a conscious decision, that would mean that the scope of what Tapestry allows the developer to do, without having to resort to a lower-level API (which is beyond the scope of Hibernate itself) no longer includes being able to stream files. I've also read that one of Howard's stated goals in using IoC is to expose the developer to fewer and fewer API's. Now, I'm finding that I'm being forced to be exposed to ANOTHER API, just to do something that I was able to take for granted in Tapestry 3.0. It's possible that a dedicated, built-in Tapestry service that represents a higher-level interface for being able to send files to a user might be more appropriate to the long-term goals of the project, so long as it hides the details of Hivemind. I am classifying this as a Major priority bug, since it represents a regression of functionality in the scope of the Tapestry projcet, without a simple workaround. In the meantime, I'll have to use the deprecated RequestContext to get a handle to the raw HttpServletResponse object.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-569) WebResponse does not expose a way to set headers
Posted by "Cherry Development (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-569?page=comments#action_12318963 ]
Cherry Development commented on TAPESTRY-569:
---------------------------------------------
Ya, for a moment, I thought that ContentType was what I was looking for, but then I discovered that in the ServletWebResponse implementation, the only part of the ContentType that is used is .toString() and .getMimeType(). It appears that the ContentType parameters are all to do with variations on mime types and the ServletWebResponse will not use any of those to add headers along. I could potentially get along with only being able to set the ContentType, but the requirements of my application also need to be able to set the Content-disposition and Last-Modified headers. It appears that your Content-Disposition parameter is being ignored, since you are calling getOutputStream(). There appears to be a bug in ServletWebResponse, as well, that sets the contentType with .getMimeType() for an OutputStream, which only returns the simple mime type, but calls .toString() for getPrintStream(), which, in your example, would result in the following header:
Content-Type: application/pdf;Content-disposition=attachment; filename=form.pdf
I've checked the mime reference guide, and this will not do what I'm sure you want it to. The Content-disposition mime field must be separated.
What I can do, though, is use your example to create for myself an IEngineService that is injected with the HttpServletResponse, which will allow me to set any headers that I wish. I still see this as a regression of capabilities of Tapestry itself, though.
Pardon my mistaken mention of Hibernate. :) I've spent too much time having 'discussions' with Gavin in the hibernate forums.
Thanks for your example, though.
> WebResponse does not expose a way to set headers
> ------------------------------------------------
>
> Key: TAPESTRY-569
> URL: http://issues.apache.org/jira/browse/TAPESTRY-569
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Cherry Development
>
> I'm trying to puzzle over this one...
> The HttpServletResponse object has been made completely inaccessible through any non-depricated part of the Tapestry API. Instead we have the WebResponse object. The WebResponse has a convenience method for setting date headers on it, but absolutely no way to set headers that are NOT dates. Why would we be given access to set headers that should be formatted as dates, but not any others?
> I've been searching on the forums and mailing list and I've seen several requests for this sort of functionality. So far, it seems the only supported way of doing this in Tapestry 4 is to create a new hivemind service so that it can access the tapestry.globals.HttpServletResponse hivemind service. Now, suddenly, we're being dropped into a much lower-level API and one I'm completely unfamiliar with, Hivemind, just so that I can stream a file to the user, which requires me to be able to set arbitrary headers. It seems that if this is a conscious decision, that would mean that the scope of what Tapestry allows the developer to do, without having to resort to a lower-level API (which is beyond the scope of Hibernate itself) no longer includes being able to stream files. I've also read that one of Howard's stated goals in using IoC is to expose the developer to fewer and fewer API's. Now, I'm finding that I'm being forced to be exposed to ANOTHER API, just to do something that I was able to take for granted in Tapestry 3.0. It's possible that a dedicated, built-in Tapestry service that represents a higher-level interface for being able to send files to a user might be more appropriate to the long-term goals of the project, so long as it hides the details of Hivemind. I am classifying this as a Major priority bug, since it represents a regression of functionality in the scope of the Tapestry projcet, without a simple workaround. In the meantime, I'll have to use the deprecated RequestContext to get a handle to the raw HttpServletResponse object.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-569) WebResponse does not expose a way to set headers
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-569?page=comments#action_12323204 ]
Howard M. Lewis Ship commented on TAPESTRY-569:
-----------------------------------------------
I've added setHeader() and setIntHeader(). I'm conferring with Mind Bridge about the last issue (getMimeType() vs. toString() ).
> WebResponse does not expose a way to set headers
> ------------------------------------------------
>
> Key: TAPESTRY-569
> URL: http://issues.apache.org/jira/browse/TAPESTRY-569
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Cherry Development
> Assignee: Howard M. Lewis Ship
>
> I'm trying to puzzle over this one...
> The HttpServletResponse object has been made completely inaccessible through any non-depricated part of the Tapestry API. Instead we have the WebResponse object. The WebResponse has a convenience method for setting date headers on it, but absolutely no way to set headers that are NOT dates. Why would we be given access to set headers that should be formatted as dates, but not any others?
> I've been searching on the forums and mailing list and I've seen several requests for this sort of functionality. So far, it seems the only supported way of doing this in Tapestry 4 is to create a new hivemind service so that it can access the tapestry.globals.HttpServletResponse hivemind service. Now, suddenly, we're being dropped into a much lower-level API and one I'm completely unfamiliar with, Hivemind, just so that I can stream a file to the user, which requires me to be able to set arbitrary headers. It seems that if this is a conscious decision, that would mean that the scope of what Tapestry allows the developer to do, without having to resort to a lower-level API (which is beyond the scope of Hibernate itself) no longer includes being able to stream files. I've also read that one of Howard's stated goals in using IoC is to expose the developer to fewer and fewer API's. Now, I'm finding that I'm being forced to be exposed to ANOTHER API, just to do something that I was able to take for granted in Tapestry 3.0. It's possible that a dedicated, built-in Tapestry service that represents a higher-level interface for being able to send files to a user might be more appropriate to the long-term goals of the project, so long as it hides the details of Hivemind. I am classifying this as a Major priority bug, since it represents a regression of functionality in the scope of the Tapestry projcet, without a simple workaround. In the meantime, I'll have to use the deprecated RequestContext to get a handle to the raw HttpServletResponse object.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org