Re: License headers
On Oct 3, 2006, at 10:50 PM, Martijn Dashorst wrote: I ran the RAT tool from Apache on our distribution for 1.2.2, and it came up with the following files that don't have an ASL header. I haven't looked into it closely but I think we should clear these up. These are from the main src directory, I haven't filtered the test directory yet. D ../wicket-1.2.2/src/java/wicket/util/diff !? AddDelta.java !? ChangeDelta.java !? Chunk.java !? DeleteDelta.java !? Delta.java !? Diff.java !? DiffAlgorithm.java !? DiffException.java D ../wicket-1.2.2/src/java/wicket/util/diff/myers !? DiffNode.java !? MyersDiff.java !? PathNode.java !? Snake.java The diff util is from jakarta commons, and is licensed under ASL 1.1. Is there any problem with the version? Janne
Re: @Apache code conventions
On 10/3/06, Ross Gardler <[EMAIL PROTECTED]> wrote: Igor Vaynberg wrote: > depends on what you are looking to use it for i guess. > > the way we've been using @author is to tag people who design/change > behavior > in a class - not by how important the change was. Yes, that is always the intention, but experience has shown that it is not interpreted that way. An @author tag makes one contributor look more important than another. This perception has nothing to do with the intent. > so that if someone has a question about a certain class you can look at the > list of authors and go bug those people on the hows and whys. An ASF project is owned by the community, not by any individual author. All committers have equal responsibility for code. I realise you are not intending to say anything different in your above statement, but again, it is a perception thing. well, when we were thinking about entering the incubator we complained that jars with -incubating are perceived to be at most beta quality and not ready for production use. we were told that that perception is wrong and we should work on educating people and changing their perception :) im not opposed to removing @author tags because i more or less feel comfortable with the entire codebase, but i think we will only be losing and not gaining. -Igor
Re: @Apache code conventions
Igor Vaynberg wrote: depends on what you are looking to use it for i guess. the way we've been using @author is to tag people who design/change behavior in a class - not by how important the change was. Yes, that is always the intention, but experience has shown that it is not interpreted that way. An @author tag makes one contributor look more important than another. This perception has nothing to do with the intent. so that if someone has a question about a certain class you can look at the list of authors and go bug those people on the hows and whys. An ASF project is owned by the community, not by any individual author. All committers have equal responsibility for code. I realise you are not intending to say anything different in your above statement, but again, it is a perception thing. If there is a technical reason to ask a direct question then the info is easily accessible in the SVN logs. In fact, even more accessible because an annotated SVN log will tell me which line was changed by who along with when and how it was changed. Further I can go back to any point in history and examine the migration. An @author tag only tells me someone wrote a significant amount of code at some point in the past. That code may have changed beyond recognition since then. But... svn revision history is too noisy because you see all the changes - spelling fixes, the < to > changes, etc. you can ask the initial committer as that person is always the author, but then you leave out all the other people who have significantly changed/added functionality. Sure, it can be too noisy. This is why many projects have a status document as well, it is a higher level description of what has changed and who changed it. For example, http://cocoon.apache.org/2.1/changes.html Incidentally, there have been some experiments with extracting this status info from SVN logs by using javadoc like tags in the commit message to lag certain messages for inclusion in the status doc. But that's a whole different story. Ross -Igor On 10/3/06, Ross Gardler <[EMAIL PROTECTED]> wrote: Matej Knopp wrote: > Johan Compagner wrote: >>> >>> > - shall we remove the @author tags (not forbidden but frowned upon >>> @apache) >>> >>> Really, frowned upon? If I recall correctly, any Apache project I have >>> seen the sources from have them... Now that most people are more or >>> less maintaining them, I kind of like them. The author tag is considered to be too difficult to manage within a community project. At least within the ASF projets I work on, however, I believe there are projects that still use it. The general feeling, as I understand it, is that it opens the question of "how much does one have to change before they deserve entry into the author tag?". In a community driven project no contribution is more or less important than any other. For example, a single character change that fixes an elusive bug can be just as important as the contribution of a new class, consider, for example, a '<' changed to a '>' in a rarely executed conditional statement. >> aarghh >> no author tags? Then all my: >> >> @author Igor Vaynberg (ivaynberg) >> >> are removed? >> How do we blame igor then? > Exactly. I think also the @author tag is too useful to be just removed. > So -1 on removing that. SVN commit logs provide all the necessary information for tracking individual contributions. Many projects also manage a status document that describes significant changes in a code base. Ross
Re: @Apache code conventions
depends on what you are looking to use it for i guess. the way we've been using @author is to tag people who design/change behavior in a class - not by how important the change was. so that if someone has a question about a certain class you can look at the list of authors and go bug those people on the hows and whys. svn revision history is too noisy because you see all the changes - spelling fixes, the < to > changes, etc. you can ask the initial committer as that person is always the author, but then you leave out all the other people who have significantly changed/added functionality. -Igor On 10/3/06, Ross Gardler <[EMAIL PROTECTED]> wrote: Matej Knopp wrote: > Johan Compagner wrote: >>> >>> > - shall we remove the @author tags (not forbidden but frowned upon >>> @apache) >>> >>> Really, frowned upon? If I recall correctly, any Apache project I have >>> seen the sources from have them... Now that most people are more or >>> less maintaining them, I kind of like them. The author tag is considered to be too difficult to manage within a community project. At least within the ASF projets I work on, however, I believe there are projects that still use it. The general feeling, as I understand it, is that it opens the question of "how much does one have to change before they deserve entry into the author tag?". In a community driven project no contribution is more or less important than any other. For example, a single character change that fixes an elusive bug can be just as important as the contribution of a new class, consider, for example, a '<' changed to a '>' in a rarely executed conditional statement. >> aarghh >> no author tags? Then all my: >> >> @author Igor Vaynberg (ivaynberg) >> >> are removed? >> How do we blame igor then? > Exactly. I think also the @author tag is too useful to be just removed. > So -1 on removing that. SVN commit logs provide all the necessary information for tracking individual contributions. Many projects also manage a status document that describes significant changes in a code base. Ross
Re: @Apache code conventions
Matej Knopp wrote: Johan Compagner wrote: > - shall we remove the @author tags (not forbidden but frowned upon @apache) Really, frowned upon? If I recall correctly, any Apache project I have seen the sources from have them... Now that most people are more or less maintaining them, I kind of like them. The author tag is considered to be too difficult to manage within a community project. At least within the ASF projets I work on, however, I believe there are projects that still use it. The general feeling, as I understand it, is that it opens the question of "how much does one have to change before they deserve entry into the author tag?". In a community driven project no contribution is more or less important than any other. For example, a single character change that fixes an elusive bug can be just as important as the contribution of a new class, consider, for example, a '<' changed to a '>' in a rarely executed conditional statement. aarghh no author tags? Then all my: @author Igor Vaynberg (ivaynberg) are removed? How do we blame igor then? Exactly. I think also the @author tag is too useful to be just removed. So -1 on removing that. SVN commit logs provide all the necessary information for tracking individual contributions. Many projects also manage a status document that describes significant changes in a code base. Ross
Re: Re: @Apache code conventions
Dear mentors, How do we get rid of this requirement? It would be a major set back for our framework to have to remove these headers @runtime. Removing them from a binary release is also rather hard. Removing all comments just won't cut it in this case, as some browsers depend on comments being inside these files, just for their sake (IE7 specifics for instance). Martijn On 10/3/06, Johan Compagner <[EMAIL PROTECTED]> wrote: please don't let us prepend all the headers to that yes... :( Then we need to filter that out of the code again when streaming (or the markup loader should do that).. sigh. johan On 10/3/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > why would we want to stream the header to the client though? it would be > silly. > > someone uses a tabbedpanel - and all of a sudden they have a huge apache > header in their client's html. include two tabbed panels and you get two > headers. its pretty silly, considering the size of tabbedpanel.html [1]. > we > have a lot of small files like this, it would be insane to have apache > headers in them. > > [1] > > http://svn.sourceforge.net/viewvc/wicket/branches/wicket-1.x/wicket-extensions/src/java/wicket/extensions/markup/html/tabs/TabbedPanel.html?revision=7095&view=markup > > -Igor > > > On 10/3/06, Ross Gardler <[EMAIL PROTECTED]> wrote: > > > > Eelco Hillenius wrote: > > > On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > >> Several things: > > >> > > >> - which files are required to have the ASF license > > > > > > If we can avoid it, by any means please NOT in the html, javascript > > > and css files. That would just be totally horrible imo. > > > > As far as I am aware the copyright headers have to be in everything that > > is copyrighted by the ASF, i.e. all files. > > > > That is certainly the case on all the projects I am currently involved > > with in the ASF. > > > > Ross > > > > -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: @Apache code conventions
please don't let us prepend all the headers to that yes... :( Then we need to filter that out of the code again when streaming (or the markup loader should do that).. sigh. johan On 10/3/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: why would we want to stream the header to the client though? it would be silly. someone uses a tabbedpanel - and all of a sudden they have a huge apache header in their client's html. include two tabbed panels and you get two headers. its pretty silly, considering the size of tabbedpanel.html [1]. we have a lot of small files like this, it would be insane to have apache headers in them. [1] http://svn.sourceforge.net/viewvc/wicket/branches/wicket-1.x/wicket-extensions/src/java/wicket/extensions/markup/html/tabs/TabbedPanel.html?revision=7095&view=markup -Igor On 10/3/06, Ross Gardler <[EMAIL PROTECTED]> wrote: > > Eelco Hillenius wrote: > > On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > >> Several things: > >> > >> - which files are required to have the ASF license > > > > If we can avoid it, by any means please NOT in the html, javascript > > and css files. That would just be totally horrible imo. > > As far as I am aware the copyright headers have to be in everything that > is copyrighted by the ASF, i.e. all files. > > That is certainly the case on all the projects I am currently involved > with in the ASF. > > Ross >
Re: @Apache code conventions
why would we want to stream the header to the client though? it would be silly. someone uses a tabbedpanel - and all of a sudden they have a huge apache header in their client's html. include two tabbed panels and you get two headers. its pretty silly, considering the size of tabbedpanel.html [1]. we have a lot of small files like this, it would be insane to have apache headers in them. [1] http://svn.sourceforge.net/viewvc/wicket/branches/wicket-1.x/wicket-extensions/src/java/wicket/extensions/markup/html/tabs/TabbedPanel.html?revision=7095&view=markup -Igor On 10/3/06, Ross Gardler <[EMAIL PROTECTED]> wrote: Eelco Hillenius wrote: > On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: >> Several things: >> >> - which files are required to have the ASF license > > If we can avoid it, by any means please NOT in the html, javascript > and css files. That would just be totally horrible imo. As far as I am aware the copyright headers have to be in everything that is copyrighted by the ASF, i.e. all files. That is certainly the case on all the projects I am currently involved with in the ASF. Ross
Re: @Apache code conventions
Eelco Hillenius wrote: On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Several things: - which files are required to have the ASF license If we can avoid it, by any means please NOT in the html, javascript and css files. That would just be totally horrible imo. As far as I am aware the copyright headers have to be in everything that is copyrighted by the ASF, i.e. all files. That is certainly the case on all the projects I am currently involved with in the ASF. Ross
Re: @Apache code conventions
Typically, svn has more than enough history to be able to blame someone for a specific problem. Still, I like the @author tag personally. On Tue, 2006-10-03 at 13:37 -0700, Igor Vaynberg wrote: ple ase ma ke the pa in sto p On 10/3/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > > > - shall we remove the @author tags (not forbidden but frowned upon > > @apache) > > > > Really, frowned upon? If I recall correctly, any Apache project I have > > seen the sources from have them... Now that most people are more or > > less maintaining them, I kind of like them. > > > > aarghh > no author tags? Then all my: > > @author Igor Vaynberg (ivaynberg) > > are removed? > How do we blame igor then? > > johan > > -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP signature.asc Description: This is a digitally signed message part
Re: @Apache code conventions
ple ase ma ke the pa in sto p On 10/3/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > - shall we remove the @author tags (not forbidden but frowned upon > @apache) > > Really, frowned upon? If I recall correctly, any Apache project I have > seen the sources from have them... Now that most people are more or > less maintaining them, I kind of like them. aarghh no author tags? Then all my: @author Igor Vaynberg (ivaynberg) are removed? How do we blame igor then? johan
Re: @Apache code conventions
Johan Compagner wrote: > - shall we remove the @author tags (not forbidden but frowned upon @apache) Really, frowned upon? If I recall correctly, any Apache project I have seen the sources from have them... Now that most people are more or less maintaining them, I kind of like them. aarghh no author tags? Then all my: @author Igor Vaynberg (ivaynberg) are removed? How do we blame igor then? Exactly. I think also the @author tag is too useful to be just removed. So -1 on removing that. -Matej johan
Re: License headers
go ahead. Is there a tool that can quick fix everything? johan On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: I ran the RAT tool from Apache on our distribution for 1.2.2, and it came up with the following files that don't have an ASL header. I haven't looked into it closely but I think we should clear these up. These are from the main src directory, I haven't filtered the test directory yet. D ../wicket-1.2.2/src/java/wicket/behavior !? SimpleAttributeModifier.java D ../wicket-1.2.2/src/java/wicket/markup !? IMarkupParserFactory.java !? MarkupParserFactory.java D ../wicket-1.2.2/src/java/wicket/markup/html !? AjaxServerAndClientTimeFilter.java D ../wicket-1.2.2/src/java/wicket/markup/html/panel !? ComponentFeedbackPanel.java D ../wicket-1.2.2/src/java/wicket/protocol/http !? ClientProperties.java D ../wicket-1.2.2/src/java/wicket/request/target/coding !? IndexedParamUrlCodingStrategy.java !? QueryStringUrlCodingStrategy.java D ../wicket-1.2.2/src/java/wicket/settings !? IApplicationSettings.java !? IDebugSettings.java !? IExceptionSettings.java !? IMarkupSettings.java !? IPageSettings.java !? IRequestCycleSettings.java !? IResourceSettings.java !? ISecuritySettings.java !? ISessionSettings.java D ../wicket-1.2.2/src/java/wicket/util/concurrent !? ConcurrentHashMap.java !? ConcurrentReaderHashMap.java D ../wicket-1.2.2/src/java/wicket/util/crypt !? ClassCryptFactory.java !? NoCryptFactory.java D ../wicket-1.2.2/src/java/wicket/util/diff !? AddDelta.java !? ChangeDelta.java !? Chunk.java !? DeleteDelta.java !? Delta.java !? Diff.java !? DiffAlgorithm.java !? DiffException.java ASL DiffUtil.java !? DifferentiationFailedException.java !? PatchFailedException.java !? Revision.java !? RevisionVisitor.java !? ToString.java D ../wicket-1.2.2/src/java/wicket/util/diff/myers !? DiffNode.java !? MyersDiff.java !? PathNode.java !? Snake.java Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket ">Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: @Apache code conventions
> - shall we remove the @author tags (not forbidden but frowned upon @apache) Really, frowned upon? If I recall correctly, any Apache project I have seen the sources from have them... Now that most people are more or less maintaining them, I kind of like them. aarghh no author tags? Then all my: @author Igor Vaynberg (ivaynberg) are removed? How do we blame igor then? johan
Re: @Apache code conventions
On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Several things: - which files are required to have the ASF license If we can avoid it, by any means please NOT in the html, javascript and css files. That would just be totally horrible imo. - shall we remove the $Id$ fields from the file headers? Yep. Why have no need for them anyway (imo an internet connection and a history view is enough). - shall we add a maven target (checkstyle) to check for license compliancy Sure. - shall we remove the @author tags (not forbidden but frowned upon @apache) Really, frowned upon? If I recall correctly, any Apache project I have seen the sources from have them... Now that most people are more or less maintaining them, I kind of like them. Eelco
@Apache code conventions
Several things: - which files are required to have the ASF license - shall we remove the $Id$ fields from the file headers? - shall we add a maven target (checkstyle) to check for license compliancy - shall we remove the @author tags (not forbidden but frowned upon @apache) Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
License headers
I ran the RAT tool from Apache on our distribution for 1.2.2, and it came up with the following files that don't have an ASL header. I haven't looked into it closely but I think we should clear these up. These are from the main src directory, I haven't filtered the test directory yet. D ../wicket-1.2.2/src/java/wicket/behavior !? SimpleAttributeModifier.java D ../wicket-1.2.2/src/java/wicket/markup !? IMarkupParserFactory.java !? MarkupParserFactory.java D ../wicket-1.2.2/src/java/wicket/markup/html !? AjaxServerAndClientTimeFilter.java D ../wicket-1.2.2/src/java/wicket/markup/html/panel !? ComponentFeedbackPanel.java D ../wicket-1.2.2/src/java/wicket/protocol/http !? ClientProperties.java D ../wicket-1.2.2/src/java/wicket/request/target/coding !? IndexedParamUrlCodingStrategy.java !? QueryStringUrlCodingStrategy.java D ../wicket-1.2.2/src/java/wicket/settings !? IApplicationSettings.java !? IDebugSettings.java !? IExceptionSettings.java !? IMarkupSettings.java !? IPageSettings.java !? IRequestCycleSettings.java !? IResourceSettings.java !? ISecuritySettings.java !? ISessionSettings.java D ../wicket-1.2.2/src/java/wicket/util/concurrent !? ConcurrentHashMap.java !? ConcurrentReaderHashMap.java D ../wicket-1.2.2/src/java/wicket/util/crypt !? ClassCryptFactory.java !? NoCryptFactory.java D ../wicket-1.2.2/src/java/wicket/util/diff !? AddDelta.java !? ChangeDelta.java !? Chunk.java !? DeleteDelta.java !? Delta.java !? Diff.java !? DiffAlgorithm.java !? DiffException.java ASL DiffUtil.java !? DifferentiationFailedException.java !? PatchFailedException.java !? Revision.java !? RevisionVisitor.java !? ToString.java D ../wicket-1.2.2/src/java/wicket/util/diff/myers !? DiffNode.java !? MyersDiff.java !? PathNode.java !? Snake.java Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: Another compound question
it doesnt wrap itself.
there is no difference between these 2 impl in the
AttachedCompoundPropertyModel:
public IWrapModel wrapOnAssignment(Component component)
{
return new AttachedCompoundPropertyModel(component);
}
or
public IWrapModel wrapOnAssignment(Component component)
{
return CompoundPropertyModel.this.wrapOnInheritance(component);
}
it does exactly the same.
It just blows up the code.
johan
On 10/1/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
The wrap model for the compound property model implements both
IInheritableModel and IAssignmentAware. The
AttachedCompoundPropertyModel wraps itself in both these models.
Shouldn't this be done with the nested compound propertymodel instead?
i.e.:
public IWrapModel wrapOnInheritance(Component component) {
return CompoundPropertyModel.this.wrapOnInheritance(component);
};
public IWrapModel wrapOnAssignment(Component component) {
return CompoundPropertyModel.this.wrapOnInheritance(component);
};
The latter is a bit strange as the compound property model itself is
not assignment aware.
Martijn
--
http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote
for http://www.thebeststuffintheworld.com/stuff/wicket
">Wicket
at the http://www.thebeststuffintheworld.com/";>Best Stuff in
the World!
Re: IAssignmentAware and IWrapModel
We (igor and me) talked about it and we let developers of models control
what they want
if we unwrap it then it is really final. Now they can control and do
anything they want
by also implementing the wrap models right, for example let them implement
again the IInheritanceAware or IAssignmentAware
So they can do exactly what they want if the notice that the wrap model is
again assigned to something.
johan
On 10/1/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I think I have found a discrepancy in the setModel implementation.
I think that if the new model is also an Wrapped model, then it should
be normalized to its nested model, before the IAssignmentAware check.
From Component:
public Component setModel(final IModel model)
{
// Detach current model
if (this.model != null)
{
this.model.detach();
}
IModel prevModel = this.model;
if (prevModel instanceof IWrapModel)
{
prevModel = ((IWrapModel)prevModel).getNestedModel();
}
+// normalize the new model to the nested
+if(model instanceof IWrapModel)
+{
+model = ((IWrapModel)model).getNestedModel();
+}
// Change model
if (prevModel != model)
{
if (prevModel != null)
{
addStateChange(new ComponentModelChange(prevModel));
}
if (model instanceof IAssignmentAware)
{
this.model =
((IAssignmentAware)model).wrapOnAssignment(this);
}
else
{
this.model = model;
}
}
modelChanged();
return this;
}
--
http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote
for http://www.thebeststuffintheworld.com/stuff/wicket
">Wicket
at the http://www.thebeststuffintheworld.com/";>Best Stuff in
the World!
Re: ResourceModel, wrap and keeping track of Component
fixed
On 10/1/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I just read and grokked the ResourceModel class. At the moment we use
a setter to set the component on the resource model. The setter is
package private, which is fairly odd. I found the whole structure
quite confusing: which instance is getting the component?
So I propose to change the code to this:
- void setComponent(Component c)
- {
- component = c;
- }
public AssignmentWrapper(String key, String defaultValue, Component
component)
{
super(key, defaultValue);
- setComponent(component);
+super.component = component;
}
wdyt?
Martijn
--
http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote
for http://www.thebeststuffintheworld.com/stuff/wicket
">Wicket
at the http://www.thebeststuffintheworld.com/";>Best Stuff in
the World!
Re: Re: Re: Proglem generating resource: broken pipe
OK, it was a spurious span inside a link that cancelled the request for me... link Apparently you always have a 8kb buffer you can write to even when another request comes in. Consider this case closed. Martijn On 10/3/06, Johan Compagner <[EMAIL PROTECTED]> wrote: and that is exactly the number of bytes that it sent to the client? what about tomcat? johan On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > mimeType"application/zip" > length 24550 > > > On 10/3/06, Matej Knopp <[EMAIL PROTECTED]> wrote: > > What does the response header say? > > > > Martijn Dashorst wrote: > > > It is not a Jetty 5 specific bug, as in Jetty 6.0.1 I get this > exception. > > > > > > [2006-10-03 14:16:47,759] [btpool0-5] RequestCycle.step(1010) | method > > > IResourceListener of interface wicket.IResourceListener targetted at > > > component [MarkupContainer [Component id = aanmaken, page = > > > nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, > > > path = 3:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned > > > = false]] threw an exception > > > wicket.WicketRuntimeException: method IResourceListener of interface > > > wicket.IResourceListener targetted at component [MarkupContainer > > > [Component id = aanmaken, page = > > > nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, > > > path = 3:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned > > > = false]] threw an exception > > >at > > > wicket.request.target.resource.ComponentResourceRequestTarget.respond( > ComponentResourceRequestTarget.java:68) > > > > > >at > > > wicket.request.compound.DefaultResponseStrategy.respond( > DefaultResponseStrategy.java:49) > > > > > >at > > > wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond( > AbstractCompoundRequestCycleProcessor.java:66) > > > > > >at > > > wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:869) > > >at > > > wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:896) > > >at wicket.RequestCycle.step(RequestCycle.java:977) > > >at wicket.RequestCycle.steps(RequestCycle.java:1051) > > >at wicket.RequestCycle.request(RequestCycle.java:455) > > >at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java > :215) > > >at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > > >at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > >at > > > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445) > > >at > > > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java > :356) > > >at > > > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java > :226) > > >at > > > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java > :627) > > >at > > > org.mortbay.jetty.handler.ContextHandlerCollection.handle( > ContextHandlerCollection.java:149) > > > > > >at > > > org.mortbay.jetty.handler.HandlerCollection.handle( > HandlerCollection.java:123) > > > > > >at > > > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java > :141) > > >at org.mortbay.jetty.Server.handle(Server.java:269) > > >at > > > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java > :430) > > >at > > > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete( > HttpConnection.java:687) > > > > > >at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:492) > > >at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java > :199) > > >at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java > :339) > > >at > > > org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java > :270) > > >at > > > org.mortbay.thread.BoundedThreadPool$PoolThread.run( > BoundedThreadPool.java:475) > > > > > > Caused by: java.lang.reflect.InvocationTargetException > > >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > >at > > > sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:39) > > > > > >at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > > > > > >at java.lang.reflect.Method.invoke(Method.java:585) > > >at > > > wicket.request.target.resource.ComponentResourceRequestTarget.respond( > ComponentResourceRequestTarget.java:64) > > > > > >... 25 more > > > Caused by: wicket.WicketRuntimeException: Unable to render resource > > > stream [EMAIL PROTECTED] > > >at wicket.Resource.respond(Resource.java:279) > > >at wicket.Resource.onResourceRequested(Resource.java:135) > > >at > > > wicket.markup.html.link.ResourceLink.onResourceRequested( > ResourceLink.java:124) > > > > > >... 30 more > > > Caused by: org.mortbay.jetty.EofException > > >at > > > org.mortbay.je
Re: localized attributes
How is supposed to handle multiple attributes Eelco
Re: localized attributes
How is supposed to handle multiple attributes Eelco Hillenius wrote: > > We had a discussion and a vote on localized attributes some time ago: > http://www.nabble.com/VOTE%3A-how-should-localized-attributes-work--tf2047179.html#a5637727 > > Seems that most people voted for > > 2) wicket:message="value:my_key"/> > > Though it was also mentioned we could support both cases but advertise > just one. > > There is no feature request for this yet and it doesn't seem to be > implemented either, is that correct? > > I'm writing a section about localization now, so if we're gonna have > this feature, and it's not too difficult to implement, I could write > about it, provided it would be implemented soon (like this week). > > Thoughts? > > Eelco > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > -- View this message in context: http://www.nabble.com/localized-attributes-tf2288202.html#a6622905 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Re: Proglem generating resource: broken pipe
and that is exactly the number of bytes that it sent to the client? what about tomcat? johan On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: mimeType"application/zip" length 24550 On 10/3/06, Matej Knopp <[EMAIL PROTECTED]> wrote: > What does the response header say? > > Martijn Dashorst wrote: > > It is not a Jetty 5 specific bug, as in Jetty 6.0.1 I get this exception. > > > > [2006-10-03 14:16:47,759] [btpool0-5] RequestCycle.step(1010) | method > > IResourceListener of interface wicket.IResourceListener targetted at > > component [MarkupContainer [Component id = aanmaken, page = > > nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, > > path = 3:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned > > = false]] threw an exception > > wicket.WicketRuntimeException: method IResourceListener of interface > > wicket.IResourceListener targetted at component [MarkupContainer > > [Component id = aanmaken, page = > > nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, > > path = 3:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned > > = false]] threw an exception > >at > > wicket.request.target.resource.ComponentResourceRequestTarget.respond( ComponentResourceRequestTarget.java:68) > > > >at > > wicket.request.compound.DefaultResponseStrategy.respond( DefaultResponseStrategy.java:49) > > > >at > > wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond( AbstractCompoundRequestCycleProcessor.java:66) > > > >at > > wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:869) > >at > > wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:896) > >at wicket.RequestCycle.step(RequestCycle.java:977) > >at wicket.RequestCycle.steps(RequestCycle.java:1051) > >at wicket.RequestCycle.request(RequestCycle.java:455) > >at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java :215) > >at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > >at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > >at > > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445) > >at > > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java :356) > >at > > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java :226) > >at > > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java :627) > >at > > org.mortbay.jetty.handler.ContextHandlerCollection.handle( ContextHandlerCollection.java:149) > > > >at > > org.mortbay.jetty.handler.HandlerCollection.handle( HandlerCollection.java:123) > > > >at > > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java :141) > >at org.mortbay.jetty.Server.handle(Server.java:269) > >at > > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java :430) > >at > > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete( HttpConnection.java:687) > > > >at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:492) > >at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java :199) > >at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java :339) > >at > > org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java :270) > >at > > org.mortbay.thread.BoundedThreadPool$PoolThread.run( BoundedThreadPool.java:475) > > > > Caused by: java.lang.reflect.InvocationTargetException > >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >at > > sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) > > > >at > > sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) > > > >at java.lang.reflect.Method.invoke(Method.java:585) > >at > > wicket.request.target.resource.ComponentResourceRequestTarget.respond( ComponentResourceRequestTarget.java:64) > > > >... 25 more > > Caused by: wicket.WicketRuntimeException: Unable to render resource > > stream [EMAIL PROTECTED] > >at wicket.Resource.respond(Resource.java:279) > >at wicket.Resource.onResourceRequested(Resource.java:135) > >at > > wicket.markup.html.link.ResourceLink.onResourceRequested( ResourceLink.java:124) > > > >... 30 more > > Caused by: org.mortbay.jetty.EofException > >at > > org.mortbay.jetty.HttpGenerator.flushBuffers(HttpGenerator.java:856) > >at > > org.mortbay.jetty.HttpGenerator$Output.flush(HttpGenerator.java:1069) > >at > > org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:764) > >at wicket.Resource.respond(Resource.java:245) > >... 32 more > > Caused by: java.nio.channels.ClosedChannelException > >at > > sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java :125) > >at sun.nio.ch.SocketChannelImpl.
Re: Re: Proglem generating resource: broken pipe
mimeType"application/zip" length 24550 On 10/3/06, Matej Knopp <[EMAIL PROTECTED]> wrote: What does the response header say? Martijn Dashorst wrote: > It is not a Jetty 5 specific bug, as in Jetty 6.0.1 I get this exception. > > [2006-10-03 14:16:47,759] [btpool0-5] RequestCycle.step(1010) | method > IResourceListener of interface wicket.IResourceListener targetted at > component [MarkupContainer [Component id = aanmaken, page = > nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, > path = 3:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned > = false]] threw an exception > wicket.WicketRuntimeException: method IResourceListener of interface > wicket.IResourceListener targetted at component [MarkupContainer > [Component id = aanmaken, page = > nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, > path = 3:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned > = false]] threw an exception >at > wicket.request.target.resource.ComponentResourceRequestTarget.respond(ComponentResourceRequestTarget.java:68) > >at > wicket.request.compound.DefaultResponseStrategy.respond(DefaultResponseStrategy.java:49) > >at > wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond(AbstractCompoundRequestCycleProcessor.java:66) > >at > wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:869) >at > wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:896) >at wicket.RequestCycle.step(RequestCycle.java:977) >at wicket.RequestCycle.steps(RequestCycle.java:1051) >at wicket.RequestCycle.request(RequestCycle.java:455) >at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:215) >at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) >at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) >at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445) >at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:356) >at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226) >at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627) >at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149) > >at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123) > >at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141) >at org.mortbay.jetty.Server.handle(Server.java:269) >at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430) >at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:687) > >at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:492) >at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199) >at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339) >at > org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270) >at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) > > Caused by: java.lang.reflect.InvocationTargetException >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > >at java.lang.reflect.Method.invoke(Method.java:585) >at > wicket.request.target.resource.ComponentResourceRequestTarget.respond(ComponentResourceRequestTarget.java:64) > >... 25 more > Caused by: wicket.WicketRuntimeException: Unable to render resource > stream [EMAIL PROTECTED] >at wicket.Resource.respond(Resource.java:279) >at wicket.Resource.onResourceRequested(Resource.java:135) >at > wicket.markup.html.link.ResourceLink.onResourceRequested(ResourceLink.java:124) > >... 30 more > Caused by: org.mortbay.jetty.EofException >at > org.mortbay.jetty.HttpGenerator.flushBuffers(HttpGenerator.java:856) >at > org.mortbay.jetty.HttpGenerator$Output.flush(HttpGenerator.java:1069) >at > org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:764) >at wicket.Resource.respond(Resource.java:245) >... 32 more > Caused by: java.nio.channels.ClosedChannelException >at > sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:125) >at sun.nio.ch.SocketChannelImpl.write0(SocketChannelImpl.java:323) >at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:354) >at java.nio.channels.SocketChannel.write(SocketChannel.java:360) >at > org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:238) >at > org.mortbay.jetty.nio.HttpChannelEndPoint.flush(HttpChannelEndPoint.java:140)
Re: Proglem generating resource: broken pipe
What does the response header say? Martijn Dashorst wrote: It is not a Jetty 5 specific bug, as in Jetty 6.0.1 I get this exception. [2006-10-03 14:16:47,759] [btpool0-5] RequestCycle.step(1010) | method IResourceListener of interface wicket.IResourceListener targetted at component [MarkupContainer [Component id = aanmaken, page = nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, path = 3:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned = false]] threw an exception wicket.WicketRuntimeException: method IResourceListener of interface wicket.IResourceListener targetted at component [MarkupContainer [Component id = aanmaken, page = nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, path = 3:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned = false]] threw an exception at wicket.request.target.resource.ComponentResourceRequestTarget.respond(ComponentResourceRequestTarget.java:68) at wicket.request.compound.DefaultResponseStrategy.respond(DefaultResponseStrategy.java:49) at wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond(AbstractCompoundRequestCycleProcessor.java:66) at wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:869) at wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:896) at wicket.RequestCycle.step(RequestCycle.java:977) at wicket.RequestCycle.steps(RequestCycle.java:1051) at wicket.RequestCycle.request(RequestCycle.java:455) at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:356) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141) at org.mortbay.jetty.Server.handle(Server.java:269) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:687) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:492) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339) at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at wicket.request.target.resource.ComponentResourceRequestTarget.respond(ComponentResourceRequestTarget.java:64) ... 25 more Caused by: wicket.WicketRuntimeException: Unable to render resource stream [EMAIL PROTECTED] at wicket.Resource.respond(Resource.java:279) at wicket.Resource.onResourceRequested(Resource.java:135) at wicket.markup.html.link.ResourceLink.onResourceRequested(ResourceLink.java:124) ... 30 more Caused by: org.mortbay.jetty.EofException at org.mortbay.jetty.HttpGenerator.flushBuffers(HttpGenerator.java:856) at org.mortbay.jetty.HttpGenerator$Output.flush(HttpGenerator.java:1069) at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:764) at wicket.Resource.respond(Resource.java:245) ... 32 more Caused by: java.nio.channels.ClosedChannelException at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:125) at sun.nio.ch.SocketChannelImpl.write0(SocketChannelImpl.java:323) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:354) at java.nio.channels.SocketChannel.write(SocketChannel.java:360) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:238) at org.mortbay.jetty.nio.HttpChannelEndPoint.flush(HttpChannelEndPoint.java:140) at org.mortbay.jetty.HttpGenerator.flushBuffers(HttpGenerator.java:778) ... 35 more On 10/3/06, Johan Compagner <[EMAIL PROTECTED]> wrote: are you sure that the client/browser doesn't close the socket somehow? broken pipe or clientabort exceptio
Re: Re: Proglem generating resource: broken pipe
It is not a Jetty 5 specific bug, as in Jetty 6.0.1 I get this exception. [2006-10-03 14:16:47,759] [btpool0-5] RequestCycle.step(1010) | method IResourceListener of interface wicket.IResourceListener targetted at component [MarkupContainer [Component id = aanmaken, page = nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, path = 3:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned = false]] threw an exception wicket.WicketRuntimeException: method IResourceListener of interface wicket.IResourceListener targetted at component [MarkupContainer [Component id = aanmaken, page = nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, path = 3:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned = false]] threw an exception at wicket.request.target.resource.ComponentResourceRequestTarget.respond(ComponentResourceRequestTarget.java:68) at wicket.request.compound.DefaultResponseStrategy.respond(DefaultResponseStrategy.java:49) at wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond(AbstractCompoundRequestCycleProcessor.java:66) at wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:869) at wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:896) at wicket.RequestCycle.step(RequestCycle.java:977) at wicket.RequestCycle.steps(RequestCycle.java:1051) at wicket.RequestCycle.request(RequestCycle.java:455) at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:356) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141) at org.mortbay.jetty.Server.handle(Server.java:269) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:687) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:492) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339) at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at wicket.request.target.resource.ComponentResourceRequestTarget.respond(ComponentResourceRequestTarget.java:64) ... 25 more Caused by: wicket.WicketRuntimeException: Unable to render resource stream [EMAIL PROTECTED] at wicket.Resource.respond(Resource.java:279) at wicket.Resource.onResourceRequested(Resource.java:135) at wicket.markup.html.link.ResourceLink.onResourceRequested(ResourceLink.java:124) ... 30 more Caused by: org.mortbay.jetty.EofException at org.mortbay.jetty.HttpGenerator.flushBuffers(HttpGenerator.java:856) at org.mortbay.jetty.HttpGenerator$Output.flush(HttpGenerator.java:1069) at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:764) at wicket.Resource.respond(Resource.java:245) ... 32 more Caused by: java.nio.channels.ClosedChannelException at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:125) at sun.nio.ch.SocketChannelImpl.write0(SocketChannelImpl.java:323) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:354) at java.nio.channels.SocketChannel.write(SocketChannel.java:360) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:238) at org.mortbay.jetty.nio.HttpChannelEndPoint.flush(HttpChannelEndPoint.java:140) at org.mortbay.jetty.HttpGenerator.flushBuffers(HttpGenerator.java:778) ... 35 more On 10/3/06, Johan Compagner <[EMAIL PROTECTED]> wrote: are you sure that the client/browser doesn't close the socket somehow? broken pipe or clientabort exceptions seems to me that the browser shutdown the request because the user closes the browser or did already
Re: Proglem generating resource: broken pipe
are you sure that the client/browser doesn't close the socket somehow?
broken pipe or clientabort exceptions seems to me that the browser shutdown
the request
because the user closes the browser or did already go to another page or
canceld the request.
Or the browser things that it already has it all? Because or the content
lenght that is set? (just a guess)
johan
On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
The exception occurs when copying the byte array into the output
stream, right after 8192 bytes have been copied. It feels like a jetty
bug, but I am not certain at this point.
from wicket.util.io.Streams
public static int copy(final InputStream in, final OutputStream
out)
throws IOException
{
final byte[] buffer = new byte[4096];
int bytesCopied = 0;
while (true)
{
int byteCount = in.read(buffer, 0, buffer.length);
if (byteCount <= 0)
{
break;
}
out.write(buffer, 0, byteCount);
bytesCopied += byteCount;
}
return bytesCopied;
}
On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> When I generate a dynamic web resource and it is about 7.2kb,
> generating and downloading the resource goes OK. When I create a
> (much) larger download, rendering the resource breaks with a broken
> pipe error.
>
> Does anyone know what happens here? I attached the stacktraces I get.
>
>
> wicket.WicketRuntimeException: method IResourceListener of interface
> wicket.IResourceListener targetted at component [MarkupContainer
> [Component id = aanmaken, page =
> nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage,
> path = 8:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned
> = false]] threw an exception
> at
wicket.request.target.resource.ComponentResourceRequestTarget.respond(
ComponentResourceRequestTarget.java:68)
> at wicket.request.compound.DefaultResponseStrategy.respond(
DefaultResponseStrategy.java:49)
> at
wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond(
AbstractCompoundRequestCycleProcessor.java:66)
> at wicket.RequestCycle.doProcessEventsAndRespond(
RequestCycle.java:869)
> at wicket.RequestCycle.processEventsAndRespond(RequestCycle.java
:896)
> at wicket.RequestCycle.step(RequestCycle.java:977)
> at wicket.RequestCycle.steps(RequestCycle.java:1051)
> at wicket.RequestCycle.request(RequestCycle.java:455)
> at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java
:215)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
> at org.mortbay.jetty.servlet.ServletHolder.handle(
ServletHolder.java:428)
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(
WebApplicationHandler.java:473)
> at org.mortbay.jetty.servlet.ServletHandler.handle(
ServletHandler.java:568)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> at org.mortbay.jetty.servlet.WebApplicationContext.handle(
WebApplicationContext.java:633)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> at org.mortbay.jetty.plus.PlusWebAppContext.handle(
PlusWebAppContext.java:158)
> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> at org.mortbay.http.HttpConnection.service(HttpConnection.java
:816)
> at org.mortbay.http.HttpConnection.handleNext(
HttpConnection.java:982)
> at org.mortbay.http.HttpConnection.handle(HttpConnection.java
:833)
> at org.mortbay.http.SocketListener.handleConnection(
SocketListener.java:244)
> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java
:357)
> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java
:534)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
wicket.request.target.resource.ComponentResourceRequestTarget.respond(
ComponentResourceRequestTarget.java:64)
> ... 24 more
> Caused by: wicket.WicketRuntimeException: Unable to render resource
> stream [EMAIL PROTECTED]
> at wicket.Resource.respond(Resource.java:279)
> at wicket.Resource.onResourceRequested(Resource.java:135)
> at wicket.markup.html.link.ResourceLink.onResourceRequested(
ResourceLink.java:124)
> ... 29 more
> Caused by: EOFException(java.net.SocketException: Broken pipe)
>
Re: Proglem generating resource: broken pipe
The exception occurs when copying the byte array into the output
stream, right after 8192 bytes have been copied. It feels like a jetty
bug, but I am not certain at this point.
from wicket.util.io.Streams
public static int copy(final InputStream in, final OutputStream out)
throws IOException
{
final byte[] buffer = new byte[4096];
int bytesCopied = 0;
while (true)
{
int byteCount = in.read(buffer, 0, buffer.length);
if (byteCount <= 0)
{
break;
}
out.write(buffer, 0, byteCount);
bytesCopied += byteCount;
}
return bytesCopied;
}
On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
When I generate a dynamic web resource and it is about 7.2kb,
generating and downloading the resource goes OK. When I create a
(much) larger download, rendering the resource breaks with a broken
pipe error.
Does anyone know what happens here? I attached the stacktraces I get.
wicket.WicketRuntimeException: method IResourceListener of interface
wicket.IResourceListener targetted at component [MarkupContainer
[Component id = aanmaken, page =
nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage,
path = 8:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned
= false]] threw an exception
at
wicket.request.target.resource.ComponentResourceRequestTarget.respond(ComponentResourceRequestTarget.java:68)
at
wicket.request.compound.DefaultResponseStrategy.respond(DefaultResponseStrategy.java:49)
at
wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond(AbstractCompoundRequestCycleProcessor.java:66)
at wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:869)
at wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:896)
at wicket.RequestCycle.step(RequestCycle.java:977)
at wicket.RequestCycle.steps(RequestCycle.java:1051)
at wicket.RequestCycle.request(RequestCycle.java:455)
at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:215)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:473)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at
org.mortbay.jetty.plus.PlusWebAppContext.handle(PlusWebAppContext.java:158)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
wicket.request.target.resource.ComponentResourceRequestTarget.respond(ComponentResourceRequestTarget.java:64)
... 24 more
Caused by: wicket.WicketRuntimeException: Unable to render resource
stream [EMAIL PROTECTED]
at wicket.Resource.respond(Resource.java:279)
at wicket.Resource.onResourceRequested(Resource.java:135)
at
wicket.markup.html.link.ResourceLink.onResourceRequested(ResourceLink.java:124)
... 29 more
Caused by: EOFException(java.net.SocketException: Broken pipe)
at
org.mortbay.http.BufferedOutputStream.flush(BufferedOutputStream.java:206)
at
org.mortbay.util.ByteBufferOutputStream.ensureSpareCapacity(ByteBufferOutputStream.java:357)
at
org.mortbay.util.ByteBufferOutputStream.write(ByteBufferOutputStream.java:197)
at
org.mortbay.http.BufferedOutputStream.write(BufferedOutputStream.java:146)
at org.mortbay.http.HttpOutputStream.write(HttpOutputStream.java:423)
at org.mortbay.jetty.servlet.ServletOut.write(ServletOut.java:54)
at wicket.util.io
Proglem generating resource: broken pipe
When I generate a dynamic web resource and it is about 7.2kb, generating and downloading the resource goes OK. When I create a (much) larger download, rendering the resource breaks with a broken pipe error. Does anyone know what happens here? I attached the stacktraces I get. wicket.WicketRuntimeException: method IResourceListener of interface wicket.IResourceListener targetted at component [MarkupContainer [Component id = aanmaken, page = nl.topicus.iridium.web.gui.financieel.incasso.IncassoRunTonenPage, path = 8:aanmaken.IncassoRunTonenPage$5, isVisible = true, isVersioned = false]] threw an exception at wicket.request.target.resource.ComponentResourceRequestTarget.respond(ComponentResourceRequestTarget.java:68) at wicket.request.compound.DefaultResponseStrategy.respond(DefaultResponseStrategy.java:49) at wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond(AbstractCompoundRequestCycleProcessor.java:66) at wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:869) at wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:896) at wicket.RequestCycle.step(RequestCycle.java:977) at wicket.RequestCycle.steps(RequestCycle.java:1051) at wicket.RequestCycle.request(RequestCycle.java:455) at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:596) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:473) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.jetty.plus.PlusWebAppContext.handle(PlusWebAppContext.java:158) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at wicket.request.target.resource.ComponentResourceRequestTarget.respond(ComponentResourceRequestTarget.java:64) ... 24 more Caused by: wicket.WicketRuntimeException: Unable to render resource stream [EMAIL PROTECTED] at wicket.Resource.respond(Resource.java:279) at wicket.Resource.onResourceRequested(Resource.java:135) at wicket.markup.html.link.ResourceLink.onResourceRequested(ResourceLink.java:124) ... 29 more Caused by: EOFException(java.net.SocketException: Broken pipe) at org.mortbay.http.BufferedOutputStream.flush(BufferedOutputStream.java:206) at org.mortbay.util.ByteBufferOutputStream.ensureSpareCapacity(ByteBufferOutputStream.java:357) at org.mortbay.util.ByteBufferOutputStream.write(ByteBufferOutputStream.java:197) at org.mortbay.http.BufferedOutputStream.write(BufferedOutputStream.java:146) at org.mortbay.http.HttpOutputStream.write(HttpOutputStream.java:423) at org.mortbay.jetty.servlet.ServletOut.write(ServletOut.java:54) at wicket.util.io.Streams.copy(Streams.java:56) at wicket.Resource.respond(Resource.java:240) ... 31 more -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
