DO NOT REPLY [Bug 25594] - [PATCH] StreamGenerator can't handle multipart request parameters correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25594. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25594 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2005-04-18 08:12 --- It seems like patch for bug 25594 (from version 2.1.5.1) makes StreamGenerator to lose form character encodings. Special characters (i.e. äöå) in a form encoded in utf-8 read in using StreamGenerator get messed up. Code works and is tested on Cocoon 2.1.4, but when migrating to 2.1.7 this came up. Building Cocoon with the old java-file solves the problem. Configuration: -cocoon 2.1.7 -run on jetty-4.2.22 -web.xml: -container-encoding: ISO-8859-1 -form-encoding: UTF-8 -tested generator with different defaultContentType parameters -the original message: surnameÖöliä läikkyy/surname -url-encoded utf-8 message the server receives: %3Csurname%3E%C3%96%C3%B6li%C3%A4+l%C3%A4ikkyy%3C%2Fsurname%3E -what we get: surnameÃ#150;öliä läikkyy/surname -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Java components in blocks
Daniel Fagerstrom wrote:
So WDYT, does this make sense for your use cases?
Yes, for the pipelines part but that's not the whole story.
Just two thoughts: Don't know what we gain when we introduce two separate
deployment units (bundles and blocks). Maybe it's more confusing than helping.
If necessary we can have different types of blocks.
Second, I don't see our flowscript usecase
var true = cocoon.blocks.myblockA.confirmDialog(Are you sure?) or
var newCustomer = cocoon.blocks.crm.createCustomer()
is covered so far, isn't it?.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Java components in blocks
Ralph Goers wrote: Daniel Fagerstrom wrote: Blocks are of course also packaged, distributed and dependency resolved much like the bundles above. --- o0o --- So WDYT, does this make sense for your use cases? Thanks. Yes, this makes a lot more sense. I'm not sure how workable it will be, but it is possible it might be. The only real issue I see is for the person trying to construct a portal. They need: a. A main sitemap that defines the portal sitemap components, the component-configurations section that defines the name of the portal and its profiles, and the main portal pipeline. b. additions to cocoon.xconf (presumably through their own xconf) that configures components that are in the portal bundle, or possibly in their own bundle if they choose to implement their own features. c. the portal definition files (these are obtained via pipelines in the user's main portal sitemap and might be dynamically generated). The portal definition files define how individual portlets are invoked and rendered. As I stated before, ideally these would be separate blocks. However, since many will contain java code, it sounds like many portlets would have to be a block with a matching bundle. A block can contain code. It is just (at least in the first step) not allowed to expose components. So if the portlet components need to be accessible from other parts of the system you need both a bundle and a block. But if the components only are needed internally and the portlet can expose all its functionality as pipeline functionality, it is enough with a block. JSR-168 portlets I guess would have to be bundles, if they are packaged for Cocoon, as they don't contain a sitemap of any kind. Seem reasonable. So as I understand it, a block would have the sitemap and would require a companion bundle which contained the xconf file if it had any components that need to be configured, or if it needs to configure components provided in another bundle. Is that correct? See above. The block can import and configure components as much as it like. As I have described in previous discussions, one way to make block extensible and configurable is by using polymorphic sitemap rules. The block, e.g. a portlet, contains configurations and default content that are used through polymorphic sitemap rules. Then a user can extend the original block and overide the sitemap rules that are needed for the application. We could also let extending blocks get access to the component manager and classloader from the extended block whithout introducing to much complexity. Parent - child classloader dependencies is still easy enough to manage. The problem comes when the blocks start to have mutual depdencies on the Java level. My only concern here is simply how many moving parts it will take to construct a portal. If that becomes a problem we must of course solve that. The main point is that Pier allready has a working system that solves important parts of the bundle aspect. According to what he have writen, it is used at VNU and solves a number of our current problems in Cocoon. And I feel rather confident in start building the blocks part as soon as I find some time for it. We use some simple block like mechanism in our internal webapps, and we have very good experience in. So if we start with those aspects we might have something much more concrete to discuss about in a close future. If that is enough, that is fine, if not we do something about it. /Daniel
Re: Java components in blocks
Reinhard Poetz wrote: Daniel Fagerstrom wrote: So WDYT, does this make sense for your use cases? Yes, for the pipelines part but that's not the whole story. Just two thoughts: Don't know what we gain when we introduce two separate deployment units (bundles and blocks). Maybe it's more confusing than helping. If necessary we can have different types of blocks. Sure, I called them bundles and block to make the discussion more concrete, we could call them component blocks and sitemap block or whatever. From a repository and deployment perspective they will have much in common so we should of course use the same mechanism as long as possible. Second, I don't see our flowscript usecase var true = cocoon.blocks.myblockA.confirmDialog(Are you sure?) or This is a page flow and would fall into the reponsibility area of blocks. It could be implemented as some flowscript VPC. In that case we need to restrict what kind of objects that can be returned to those that are part of the core classloader. We could also have a more request/repsponse oriented approach and make it possible to put the true/false and other data in the reponse object, in that case we would rather get: var result = cocoon.sendPageAndWait(block:myblockA://areYouSure); var newCustomer = cocoon.blocks.crm.createCustomer() This falls in the area of bundles and component management, if the Customer interface is defined in crm, the user of it must have access to the Customer interafce from its classloader. We could develop some mechanism that makes it possible to implement components in JS but that would not be related to flow IMO. is covered so far, isn't it?. Maybe not, but those are areas that are rather vague anyway, we where the only ones who thought it had much importance the last time we discussed it. /Daniel
Re: Java components in blocks
Daniel Fagerstrom wrote:
Maybe not, but those are areas that are rather vague anyway, we where
the only ones who thought it had much importance the last time we
discussed it.
Maybe it had the appearance but I can't believe this. (Recently I had a
discussion with Sylvain and he really wants this feature too. So we are at least
three ;-) )
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Java components in blocks
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Maybe not, but those are areas that are rather vague anyway, we where
the only ones who thought it had much importance the last time we
discussed it.
Maybe it had the appearance but I can't believe this. (Recently I had
a discussion with Sylvain and he really wants this feature too. So we
are at least three ;-) )
Might be, we still need to know the use cases to provide a good
solution. Any comments to what I suggested in my response? BTW I rather
meant:
var result = cocoon.sendPageAndWait(block:myblockA://confirmDialog,
{msg: areYouSure});
/Daniel
Re: [CocoonInAction] 2 new articles
Erik Bruchez wrote: Stefano Mazzocchi wrote: o We do strongly believe that the XML pipeline language in OPS beats the ... out of Cocoon pipelines ;-) Oh, that's a bold statement :-) Yes ;-) eheh, one step up and two step back. Your pipeline language feels turing complete (haven't proved it but I think it's duable), if that is what you mean by beating the ... out of, well, we have a different definition of '...' :-) Honestly, I wouldn't be able to tell you for sure if it is turing complete or not. XPL was not designed to be a general-purpose programming language, or anything even close. If you try to write a chess program in XPL, you will give up rapidly! In fact, XPL was designed to address a number of practical use cases directly related to processing XML documents / infosets. Yes there are conditionals and iterations, but it stops there. I do see value in more expressive power, but I also see a lot of danger in introducing turing completeness in an XML syntax. Everytime I see if or foreach I puke. XSLT made that mistake first and now everybody is trying to make the same mistake. Not sure why this is a mistake. As far as using an XML-based syntax, I am still of the school that it is a good thing: you can more easily automatically generate programs, even dynamically; creating software that creates a graphical representation of the program is easier; etc. You can also develop a non-XML compact syntax in addition to the XML syntax. This is what Relax NG has done. Let's agree to disagree then. -- Stefano.
[OT] Help with JAI
Sorry for the OT and the crosspost, but I'm running out of resources and I need this for a Cocoon-based webapp anyway. If anyone here has any experience with Java Advanced Imaging, would he/she please have a look at this question: http://agylen.com/2005/04/18/lazyweb-how-to-create-an-image-from-a- byte-array-using-jai/ ? Thanks in Advance, Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Source.zone: http://sourcezone.info/ Wine Food Blog: http://www.divinocibo.it/ smime.p7s Description: S/MIME cryptographic signature
Re: [OT] Help with JAI
answered on the web site :) -- dims On 4/18/05, Ugo Cei [EMAIL PROTECTED] wrote: Sorry for the OT and the crosspost, but I'm running out of resources and I need this for a Cocoon-based webapp anyway. If anyone here has any experience with Java Advanced Imaging, would he/she please have a look at this question: http://agylen.com/2005/04/18/lazyweb-how-to-create-an-image-from-a- byte-array-using-jai/ ? Thanks in Advance, Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Source.zone: http://sourcezone.info/ Wine Food Blog: http://www.divinocibo.it/ -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Java components in blocks
On Apr 18, 2005, at 7:05 AM, Daniel Fagerstrom wrote: The portal definition files define how individual portlets are invoked and rendered. As I stated before, ideally these would be separate blocks. However, since many will contain java code, it sounds like many portlets would have to be a block with a matching bundle. A block can contain code. It is just (at least in the first step) not allowed to expose components. So if the portlet components need to be accessible from other parts of the system you need both a bundle and a block. But if the components only are needed internally and the portlet can expose all its functionality as pipeline functionality, it is enough with a block. Sorry to be late to the party, but I was unsure where this discussion was headed and choose to keep my mouth shut. I'm glad to see to that blocks can have code again.;-) I think the issue of exposing components is a non issue. We are after all talking about java byte code, if some one wants to use the jar/class file it just needs to be on the classpath. The issue here is one of deployment, where to locate the class and which ClassLoader will load the class. It seems to me that if we have two component deployment levels, global and sitemap, we can pretty much accomplish the same thing as exposing or not exposing components. WDYT? Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Authentication not working with 2.1.7
Hi, We just updated from 2.1.5 to 2.1.7, and the authentication (login-action) stopped functioning. It seems that no parameters are no longer forwarded to the authentication resource. We have the same configuration as in the samples, using: cocoon:raw:/authenticate as the authentication resource. Could someone please confirm this? Thanks, Tuomo
