[jira] Resolved: (TOMAHAWK-1119) add autocomplete attribute to InputTextHelp
[ https://issues.apache.org/jira/browse/TOMAHAWK-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved TOMAHAWK-1119. Resolution: Fixed add autocomplete attribute to InputTextHelp --- Key: TOMAHAWK-1119 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1119 Project: MyFaces Tomahawk Issue Type: Improvement Reporter: Mario Ivankovits Assignee: Mario Ivankovits Priority: Minor Fix For: 1.1.7-SNAPSHOT add autocomplete attribute to InputTextHelp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New AddResource handler: DojoAddResource
Ok, I've found the first problem, the stylesheets were inserted AFTER all the other stylesheets, so any overloaded stylesheet will be lost. Will think about if this can be fixed fixed! Ciao, Mario
Re: [tomahaw] ppr problems with log and tree2
Hi Ernst! Great you picked it up! I must have missed the point where this log got in - my guess is that it can optionally be defined or turned on in dojo or something. However I would think a check wether or not the object is defined before using it cannot hurt. Yea, I tried if (log), but even this lead to an exception ... I don't know why. I also like the suggestion of caching the patterns themselves and re-matching them against all inputs within updated areas. I have a relatively tight schedule this week, but I'll try to squeeze it in on the weekend. Oh - would be great if you could make it work :-) I'll spend you a beer - or two. Thanks! Ciao, Mario
[tomahawk] ppr and subform
Hi! It looks like the ppr do not work with subforms if you do not use a command* to trigger the ajax request. With a command* stuff the subform is able to catch the queueEvent stuff and set itself as submitted, but if you use the prr with a trigger pattern like partialTriggers=applyRightFilter(onkeyup) there is not command* involved and therefore the subform component is not able to determine if it has been submitted - well - and it skips its children processing. I've seen the subform renderer renders a javascript piece (maybe a relict) one can use to tell the system which subform is going to be submitted from javascript. It is not used by the subform component itself (can we remove this script?). Basend on this idea I'd like to enhance the ppr component to set this special hidden field to the component id of the subform where the ppr is embedded in - but it requires us to depend the ppr on the subform tag. Comments? Ciao, Mario
Re: [tomahawk] ppr and subform
Hi! Due to time constraints I hacked it that way for now (r577713). If someone came up with a better idea we can revert it then. Ciao, Mario Hi! It looks like the ppr do not work with subforms if you do not use a command* to trigger the ajax request. With a command* stuff the subform is able to catch the queueEvent stuff and set itself as submitted, but if you use the prr with a trigger pattern like partialTriggers=applyRightFilter(onkeyup) there is not command* involved and therefore the subform component is not able to determine if it has been submitted - well - and it skips its children processing. I've seen the subform renderer renders a javascript piece (maybe a relict) one can use to tell the system which subform is going to be submitted from javascript. It is not used by the subform component itself (can we remove this script?). Basend on this idea I'd like to enhance the ppr component to set this special hidden field to the component id of the subform where the ppr is embedded in - but it requires us to depend the ppr on the subform tag. Comments? Ciao, Mario -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: [tomahaw] ppr problems with log and tree2
Hi Ernst! I have a relatively tight schedule this week, but I'll try to squeeze it in on the weekend. I decided to have a look at it myself and it looks like I got it working. Please review r577913. Mainly I've cached the partialTrigger(Pattern) configuration and apply it after each ajax request by avoiding duplicates in oamPartialTriggersToZoneIds. BTW: I've seen some arrays are stored at window. instead of this.. I think this. should be sufficient here, no? Some code cleanup can be done after my changed, I just wanted to avoid to much changes - we can do it if we are happy with my changes. Ciao, Mario
New AddResource handler: DojoAddResource
Hi! I've started an experiment with our AddResource stuff - again. As you might know, we provide the StreamingAddResource which allows to add resources like javascript or css to the page without the need to buffer it and parse the response. Performance wise it should be a speedup, but StreamingAddResource needs some nasty tricks to get the css stuff in (I don't want to go into detail here, just e.g. threads, resource caching with timeout, ...). During playing around with the PPR stuff I had the idea to use dojo to deal with this. So I created the DojoAddResource (tomahawk-sandbox: org.apache.myfaces.custom.dojoaddresource.DojoAddResource). Much like the StreamingAddResource it will simply embedd any style or javascript into the page when requests (i.e. by not honoring the position info), but instead of using the nasty trick I simply use dojo.html.insertCssFile. Ok - this also is somehow tricky - but now it is no longer my beer ;-) Please give it a try. If you already use dojo components within your page it should not introduce any additional negative performance impact, otherwise dojo needs to be loaded which might take some time the first time. It is not well tested, anyway. Ciao, Mario
[tomahaw] ppr problems with log and tree2
Hi!
First, I've commented the using of the log stuff as it seems normally
thre is no log object around, at least I don't know where.
From our ppr.js:
if(formElement)
this._addEventHandler(formElement, connectToEventArr, eventHandler);
-else
+ /* where is the log?
+ else
log.error(Input element with id : +formElementId + not found.);
+*/
Now, my use-case started working again, well, mostly ... the next
problem I have is the following.
I'd like to use a server-side-toggling tree2 embedded in an pprPanelGroup:
s:pprPanelGroup
id=pprRoleTree
partialTriggerPattern=.*:t[0-9]+.*
t:tree2
value=#{adEditRolle.roleModel}
id=roleTree
var=node
varNodeToggler=t
showRootNode=false
preserveToggle=false
clientSideToggle=false
showNav=true
showLines=true
After triggering the first node its child nodes are shown ... fine, but
now, even if the partialTriggerPattern matches on their commandLinks
too, the ppr.js won't attach to them, only the already known elements
are reattached.
Is there a way to enhance the ppr.js in that direction?
I think caching the patterns and their zones and reapplying them
afterwards should do the trick, no?
To speed up things we should only process the components received from
the ajax call.
Mr. Ajax, willing to do this ;-) ?
Ciao,
Mario
Re: [Orchestra] Does Orchestra work with non web client?
Hi! Here is what have have in mind 1. have the JSF backing bean to have the same convesation name. The service bean is singleton scope 2. have the runnable in its own conversation, the conversation ends when the run method ends I also have another instance of same service bean, with different name in prototype mode. 3. The scheduler task in its own converstion scope, similar to 1 4. Use LocalFrameworkAdapter for each runnable and also in each scheduler task. It is so hard to tell without having a look at the code. If you could sometimes setup a small app showing the problems it would be a lot easier. What you have outlined above sounds not that bad - having an LFA per thread should fix any concurrency issues. You just have to keep in mind, that if you pass entities between threads the entity is detached for the other thread - or at least has a different EntityManager attached to it. Passing entities between conversations (which in fact is what you get with the LFA per thread scenario should be avoided - but ok, this depends on how to work with them. Ciao, Mario
[RESULT][VOTE] myfaces-maven and myfaces-shared release
Hi! The vote passed with: +1 Matthias Wessendorf Bernd Bohmann Grant Smith +0 Simon Lessard The voting thread can be found here [1]. Thanks for taking the time! Ciao, Mario [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg25507.html
[ANNOUNCE] myfaces-maven and myfaces-shared release
Hi! We are proud to announce the availability of myfaces-maven 1.0.6 and myfaces-shared 2.0.7. Ciao, Mario PS: Since this stuff is not that important to the community (I think) I didn't sent this announce to the [EMAIL PROTECTED] address. If you are not fine with this we can forward this mail later.
[jira] Created: (TRINIDAD-711) -IE7 - AutoComplete Does Not Work When You Use Script to Submit a Form
-IE7 - AutoComplete Does Not Work When You Use Script to Submit a Form -- Key: TRINIDAD-711 URL: https://issues.apache.org/jira/browse/TRINIDAD-711 Project: MyFaces Trinidad Issue Type: Bug Environment: Internet Explorer 7 Reporter: Mario Ivankovits Assignee: Matthias Weßendorf Fix For: 1.0.3-core AutoComplete Does Not Work When You Use Script to Submit a Form see http://support.microsoft.com/kb/329156/en-us Simon said in IE6 this is true as well, at least time by time -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ANNOUNCE] myfaces-maven and myfaces-shared release
Hi! We are proud to announce the availability of myfaces-maven 1.0.6 and myfaces-shared 2.0.7. Ciao, Mario PS: Since this stuff is not that important to the community (I think) I didn't sent this announce to the [EMAIL PROTECTED] address. If you are not fine with this we can forward this mail later.
Re: [jira] Resolved: (TRINIDAD-704) IE7 - AutoComplete Does Not Work When You Use Script to Submit a Form
Hi!
What about adding this to myfaces too?
if (window.external.AutoCompleteSaveForm)
{
window.external.AutoCompleteSaveForm(form)
}
should do the trick there too.
Ciao,
Mario
[
https://issues.apache.org/jira/browse/TRINIDAD-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf resolved TRINIDAD-704.
-
Resolution: Fixed
Fix Version/s: 1.0.3-core
added workaround, suggested by MS.
see commit log for more details.
IE7 - AutoComplete Does Not Work When You Use Script to Submit a Form
-
Key: TRINIDAD-704
URL: https://issues.apache.org/jira/browse/TRINIDAD-704
Project: MyFaces Trinidad
Issue Type: Bug
Environment: Internet Explorer 7
Reporter: Matthias Weßendorf
Assignee: Matthias Weßendorf
Fix For: 1.0.3-core
AutoComplete Does Not Work When You Use Script to Submit a Form
see
http://support.microsoft.com/kb/329156/en-us
Simon said in IE6 this is true as well, at least time by time
--
mit freundlichen Grüßen
Mario Ivankovits
Software Engineering
OPS EDV VertriebsgesmbH
A-1120 Wien, Michael-Bernhard-Gasse 10
Firmenbuch Nr.: FN51233v, Handelsgericht Wien
Tel.: +43-1-8938810; Fax: +43-1-8938810/3700
http://www.ops.co.at
E-Mail: [EMAIL PROTECTED]
Skype: mario_ivankovits
Re: release of shared
Matthias Wessendorf wrote: Perhaps we should do things like that on a separate branch and merge back to trunk, when everything is fine. there were some issues on trunk today, hopefully I got all of them... Thanks Matthias! Ciao, Mario
Re: number conversion and null values
Hi! The NumberConverter returns a Long instead of a Double! How can I get a simple automatic NumberConversion working ? This is really annoying! I am not sure if this has already been mentioned in this thread. But there is a numberConverter in Tomahawk's sandbox which will do the trick. Ciao, Mario
Re: number conversion and null values
Hi! Isn't the default converter useless in combination with doubles without this destType ? Notice, in most situations you do not have to set this destType, the converter will determine this automatically. Well, the default converter, I think the common strategy when using this converter is to use Number in your backing-bean which is able to take any type. Personally I don't like this so, yes, I'd render the default converter useless too but that's just my personal meaning. Ciao, Mario
Re: [Trinidad] browser build-in autocomplete box (IE 7 issue...)
Hi!
I noticed that this doesn't show up in IE7, but in FF2 it does.
(no Trinidad isn't rendering something like autocomplete=off)
Christian Swoboda already posted about a bug in IE
His text:
Hi!
We are developing a new application with myfaces 1.1.5 and discovered
that there's a problem with Internet Explorer's autocomplete
(Intelliforms)
feature. The text input fields do not remember their values, i. e.
Autocomplete does not work.
I found the following MS support article
http://support.microsoft.com/kb/329156/en-us
which declares that there's an Internet Explorer Bug ;-) when using
scripts to submit forms.
They offered the following workaround:
---
function subForm()
{
window.external.AutoCompleteSaveForm(f1);
f1.submit();
}
---
Could/should this be added to oamSubmitForm() ?
If yes, how?
But you already told me that you've experience the same with plain HTML
so might be another problem.
Ciao,
Mario
Re: [Orchestra] what happened to snapshot build?
yea, our continuum build is broken as the sandbox module is missing. I already raised it, but no luck yet. Will try again. :-) Mario -Original Message- From: Dan Tran [EMAIL PROTECTED] Date: Tuesday, Sep 11, 2007 7:51 am Subject: [Orchestra] what happened to snapshot build? To: Reply-MyFaces Development dev@myfaces.apache.orgTo: dev@myfaces.apache.org Have need seen a new build since sept 5 -D -- View this message in context: http://www.nabble.com/-Orchestra--what-happened-to-snapshot-build--tf4420427.html#a12608492 Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: [orchestra] sandbox on continuum
Hi! Could someone please take care of that - or tell me the credentials/infos for the continuum server. Thanks! Ciao, Mario Hi! Could someone please setup the myfaces-orchestra-sandbox [1] project on continuum. Currently the continuum build fails due to missing artifacts. Thanks! Ciao, Mario [1] https://svn.apache.org/repos/asf/myfaces/orchestra/trunk/sandbox
release of shared
Hi! For the Orchestra release I have to release shared first. Any objections to start the process? Ciao, Mario
[VOTE] myfaces-maven and myfaces-shared release
Hi all, this is the official vote for MyFaces Maven 1.0.6 and MyFaces Shared 2.0.7. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.maven v1.0.6 [1] 2. Maven artifact group org.apache.myfaces.shared v2.0.7 [2] [1] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/maven [2] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/shared [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks! Ciao, Mario BTW: This is for preparation for the Orchestra core release.
Re: Orchestra dependent on MyFaces 1.1.6-SNAPSHOT?
Hi! I don't think so. Just a standard error, that all trunk projects rely on the latest greatest (trunk) version of myfaces. See tomahawk (or it least was the case). Should be 1.1.5, that makes it also easier to release Orchestra. Yes, it would be necessary to downgrade to 1.1.5 for the release - and yes, Orchestra do not rely on any snapshot code, except for the examples where we need the latest tomahawk sandbox, but this wouldn't harm the release. Ciao, Mario
Re: Orchestra dependent on MyFaces 1.1.6-SNAPSHOT?
Ok, so I've seen we already moved on to myfaces 1.2.0 - so no SNAPSHOT here. The examples still run on 1.1.5 to ensure backward compatibility. Ciao, Mario
Re: [orchestra] Conversation Timeouts (was changed scope configuration)
Hi! IMHO, a conversation should behave exactly the same as the session does today - per default. There is nothing elementary different just because you can have a multitude of conversations per user. Getting in touch to the servlet timeout means we have to extend the FrameworkAdapter interface with something like getDefaultTimeout(), but, based on another ml thread, I thought about using Orchestra in a non-servlet-based environment and then why should this framework have a default timeout at all. A Swing-based application framework wouldn't provide any timeout value too. Which means, depending on the framework you use Orchestra with you have to set a timeout value or not. Regarding the session timeout. For example, we use a rather small session timeout and a regular AJAX poll to keep it alive. In such a setup (which might become even more popular) the default is just wrong and you'd set the conversation timeout to something different. Finally, I tend to NOT set any default value as it is easy to understand and document how to set one yourself, but it might become tricky to tell the user when a default timeout applies and when it doesn't. Ciao, Mario
Re: [orchestra] connectionManager package
You are so exact ;-)
But you are right, I had a problem in mind to solve which is not part (and
should not) of orchestra.
So yes, remove the listener stuf - and maybe move the whole stuff into the
sandbox?
Mario
-Original Message-
From: Simon Kitching [EMAIL PROTECTED]
Date: Monday, Sep 10, 2007 4:52 pm
Subject: [orchestra] connectionManager package
To: Reply-MyFaces Development dev@myfaces.apache.orgTo:
dev@myfaces.apache.org
Hi All,
The documentation for the connectionManager package currently states that
all this package provides is a workaround for the problem of ORMs that leak
database connections.
However it actually currently does more than that. The
ConnectionManagerDataSource class also provides a generic mechanism for
getting callbacks whenever a connection is borrowed from a DataSource or
returned to a DataSource.
Is it really necessary for Orchestra to provide such functionality? Orchestra
doesn't actually make any use of this at all (apart from an artificial
logging listener that could simply be replaced by adding a few log
statements into ConnectionManagerDataSource). And it just doesn't seem to me
to be part of Orchestra's core purpose to provide this sort of thing.
If it is felt that this really is is desirable, then perhaps we should
decouple the leak fixing part from the listening part? Currently, it's not
just a listener management tool because it cannot listen without also wrapping
connections in the special DisconnectableConnection proxy. We could instead:
(a)
replace
public Connection getConnection() throws SQLException
{
return DisconnectableConnectionFactory.create(this);
}
with a call to a factory object that is injected into it, and
(b)
move static method releaseAllBorrowedConnections into the
DisconnectableConnectionFactory class.
The ConnectionManagerDataSource would then be a simple standalone listener
mechanism rather than being half-user-tool and
half-solution-to-specific-jpa-problem.
Just to be clear, my current preference is to remove the listener
functionality: why ship/support code that isn't used?
This change would require existing Orchestra users who make use of the
ConnectionManagerDataSource to make a minor config file change.
Comments?
Cheers,
Simon
Re: [orchestra] wiki
Hi! I am not aware that we have an access control for our wiki. Just create a user yourself and you should be done. Mario -Original Message- From: Kito D. Mann [EMAIL PROTECTED] Date: Monday, Sep 10, 2007 6:34 pm Subject: [orchestra] wiki To: Reply-MyFaces Development dev@myfaces.apache.orgReply-To: [EMAIL PROTECTED]To: 'MyFaces Development' dev@myfaces.apache.org I'm currently reading over the Orchestra Wiki docs, and I see some things I could easily edit, but I don't have the rights. Could someone grant my Wiki rights? It'll be a lot faster than making a list of changes. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 *
Re: [Orchestra] FrameworkAdapter tidyup
Hi.
I am not sure if this overcomplicates things as then we provide something like
yet another filter interface for servlets, but what about simply combining both
classes. I have no pc here yet, but I think it could work.
Mario
-Original Message-
From: Simon Kitching [EMAIL PROTECTED]
Date: Monday, Sep 10, 2007 6:46 pm
Subject: [Orchestra] FrameworkAdapter tidyup
To: Reply-MyFaces Development dev@myfaces.apache.orgTo:
dev@myfaces.apache.org
Hi,
Currently the class FrameworkAdapterServletFilter caches the
HttpServletRequest and HttpServletResponse objects so that they can be
accessed by the JsfFrameworkAdapter class. This seems a little clumsy; it
would be nicer if the JsfFrameworkAdapter class was itself responsible for
caching any data it needed, and if the adapter implementation didn't have to
reference the original servlet.
How about introducing this new interface?
public interface ServletFrameworkAdapter
{
public void beginRequest(ServletRequest req, ServletResponse rsp);
public void endRequest();
}
The JsfFrameworkAdapter can then implement this, and the threadlocal stuff can
be moved out of the FrameworkAdapterServlet into JsfFrameworkAdapter. The
FrameworkAdapterServlet just needs to invoke the beginRequest/endRequest
methods and not care what the adapter does with them.
Thoughts?
Regards,
Simon
Re: [Orchestra] Does Orchestra work with non web client?
Hi! Like a scheduler within the webapp? this way i can have orchestra to keep EntityManager round to do lazy loading of a huge object. No, many of Orchestra's data-structures are kept in the session scope which is not available during a non http request. After thinking about again it I realized that I wrote nonsense here. In fact Orchestra WILL work in non servlet environments for example, we startup a compatible environment for our junit tests. And it sould be simple - it is all about the FrameworkAdapter. I've copied our mock class over to the core and now there is a org.apache.myfaces.orchestra.frameworkAdapter.local.LocalFrameworkAdapter class which should help you to solve the problem. Use it with something like this: LocalFrameworkAdapter frameworkAdapter = new LocalFrameworkAdapter(); frameworkAdapter.setApplicationContext(applicationContext); // = the Spring application context you have to gather from somewhere FrameworkAdapter.setInstance(frameworkAdapter); Notice, FrameworkAdapter.setInstance is thread bound, so you'll have to do this for each thread going to use Orchestra. If you use a fresh frameworkAdapter per run or share it over multiple runs is up to you, depending if you have conversations running longer than one sheduler task, however, the LocalFrameworkAdapter is not thread safe. If you need such a feature, just copy over the LocalFrameworkAdapter and synchronized the maps, however (2), the entity manager itself is not thread safe. I don't know how your sheduler works, but you also could configure this FrameworkAdapter as prototype in Spring and get the ApplicationContext injected ... automatically. Ciao, Mario
Re: [Orchestra] Does Orchestra work with non web client?
Hi! Like a scheduler within the webapp? this way i can have orchestra to keep EntityManager round to do lazy loading of a huge object. No, many of Orchestra's data-structures are kept in the session scope which is not available during a non http request. Is there any reason to use Orchestra for a non-request-based lifecycle? I mean, once the scheduler triggers an event a new bean might be instantiated doing all the work and holding the entityManager until the process ends - should work pretty well with plain Spring I think. Could you please provide some additional infos about what you would like to do. Ciao, Mario
Re: [orchestra] changed scope configuration
no no. I think you are right (if i understand you correctly). By default the conversation lives as long as the session which means a conversation can live far longer than just e.g. 30 min. I'd admit I am also one of those who would like to see a default timeout happening, though others wont (e.g. See shale-dialog). I am unsure about it.. Lets fell a community decision. Mario -Original Message- From: Martin Marinschek [EMAIL PROTECTED] Date: Saturday, Sep 8, 2007 1:17 am Subject: Re: [orchestra] changed scope configuration To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Ok, on rereading I see I did indeed take the wording wrongly. Sorry for the confusion. regards, Martin On 9/8/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Zubin, Mario specifically mentions that a setting HAS to be made - so I was wondering why we want to force users to do this, if it is not necessary. Might as well be that I understood his mail wrongly. regards, Martin On 9/8/07, Zubin Wadia [EMAIL PROTECTED] wrote: Martin, I think that's what is already happening. If nothing is set - the conversation dies with the session. It used to be that it was hard-wired to last 30 mins. If a specific setting is made in the config, then it supercedes the default which = session timeout. Cheers, Zubin On 9/7/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Simon, I would suspect the default should be same as session, and that the added value of Orchestra is that a conversation will time out if the session keeps being used, but only these conversation scoped beans are not used anymore. Configuration should be available, and it is good that it is, but my POV is a nice default value would be the session timeout. regards, Martin On 9/8/07, simon [EMAIL PROTECTED] wrote: Hi, Conversations are stored in the session (indirectly). So when the http session times out, the conversations automatically go too. The timeout mentioned here is just in case you want conversations to time out more quickly than the http session. Until recently this shorter timeout was hard-wired to 30 minutes. It is now configurable via the scope declaration in the spring file. And as Mario mentions, if you don't specify a timeout there the default is now *no* timeout (ie timeout only when session goes). I hope that's what you were asking about.. Kito, you might like to look at the new documentation added to the website recently (esp. in core). It's still a work in progress but any feedback on what's there so far would be very welcome.. Regards, Simon On Fri, 2007-09-07 at 23:35 +0200, Martin Marinschek wrote: Hi Mario,
Re: [orchestra] Conversation Timeouts (was changed scope configuration)
Hi! If no timeout property is present, then no timeout applies. Otherwise, the specified timeout applies. You are right too with all you said. Hmmm No pc here yet, but, how do a servlet container behave if there is no session timeout configured or is it a required configuration? Ciao, Mario
Re: [orchestra] Conversation Timeouts (was changed scope configuration)
Simon, If this element is not specified, the container must set its default timeout I think the spec is not very helpful with this text as it does not say what the container default value is. With respect to memory usage this is even more important for Orhestra as a developer often do not even know which entities live in the persitence context cache. I definitely think this small topic is worth discussing it - later we have to argue why we felt the decision in one way or the other - we should be prepared; regardless of what we decide at the end ... Mario -Original Message- From: simon [EMAIL PROTECTED] Date: Saturday, Sep 8, 2007 8:36 pm Subject: Re: [orchestra] Conversation Timeouts (was changed scope configuration) To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Ok, so I guess orchestra could use that same convention. This is still a magic number that people will need to look up in the docs, though. I still think it is more intuitive for people to not get a conversation timeout unless they configure one. There will be absolutely no surprised developers wondering where their beans went. The http session really does have to be a sane default as otherwise memory usage will eventually bring down the whole webapp. But with Orchestra, the conversations do eventually go away - when the session does. My, we have spent a lot of bandwidth on a very small point :-) It's nice to see people are interested in Orchestra though. Regards, Simon On Sat, 2007-09-08 at 19:03 +0200, Bernhard Huemer wrote: Hello, according to the Servlet specification: /// The session-timeout element defines the default session timeout interval for all sessions created in this web application. The specified timeout must be expressed in a whole number of minutes. If the timeout is 0 or less, the container ensures the default behaviour of sessions is never to time out. If this element is not specified, the container must set its default timeout period. \\\ regards, Bernhard On 08.09.2007 18:48, Mario Ivankovits wrote: Hi! If no timeout property is present, then no timeout applies. Otherwise, the specified timeout applies. You are right too with all you said. Hmmm No pc here yet, but, how do a servlet container behave if there is no session timeout configured or is it a required configuration? Ciao, Mario
Re: Orchestra integration with legacy Hibernate 2 app
Well, i haven't done it yet, but I am pretty sure there is a way.
Please send over a small app (including libs) with your setup so I can have a
look at it.
Thanks.
Mario
-Original Message-
From: William H. Mitchell [EMAIL PROTECTED]
Date: Saturday, Sep 8, 2007 5:49 am
Subject: Re: Orchestra integration with legacy Hibernate 2 app
To: Reply-MyFaces Discussion users@myfaces.apache.orgTo: MyFaces
Discussion users@myfaces.apache.org
Mario,
Thanks for that response to my question about that Session is closed! error
when trying to use HibernatePersistenceContextFactory (HPCF).
I made my simple test app work by stripping out all the JPA stuff I had, both
in the code and the applicationContext.xml, and then using Spring to inject
the DAO with a LocalSessionFactoryBean. Is that the right way to approach it?
(Or is that a naive solution, with lurking problems?)
Now I've started looking at making my test app work with Hibernate 2. Right
away I noticed that there's no SessionHolder in Spring's Hibernate 3 support.
I see some things further down that may be a problem, too, but my
understanding of the machinery is tenuous at best.
Can Orchestra be made to work with Hibernate 2? ('Sorry to ask this having
done so little homework on it...)
William Mitchell
Mitchell Software Engineering
Re: Orchestra integration with legacy Hibernate 2 app
Hi! I made my simple test app work by stripping out all the JPA stuff I had, both in the code and the applicationContext.xml, and then using Spring to inject the DAO with a LocalSessionFactoryBean. Is that the right way to approach it? (Or is that a naive solution, with lurking problems?) Just to be accurate, if you define a LocalSessionFactoryBean (where its super-class implements the FactoryBean interface) Spring in fact replaces it with the SessionFactory. So if you use the HibernateDaoSupport or HibernateTemplate, you'll inject a SessionFactory - and that should be enough for Orchestra. At least I've tried the same with Spring's JpaDaoSupport (without annotations) - it is pretty much the same as with hibernate then. Right away I noticed that there's no SessionHolder in Spring's Hibernate 3 support. I see some things further down that may be a problem, too, but my understanding of the machinery is tenuous at best. I've found a SessionHolder in my spring-2.0.6 jar: org.springframework.orm.hibernate3.SessionHolder What version of Spring are you going to use? Ciao, Mario
[orchestra] changed scope configuration
Hi! Today we cleaned up the way how to configure the different scopes. Basically this means: * you HAVE to configure a timeout now. The default is to never timeout a conversation on its own. * the flash scope is now configured through the lifetime property. Please see here an example or refer to the updated installation documentation (once it has been published which might take some hours) entry key=conversation.normal bean class=org.apache.myfaces.orchestra.conversation.spring.SpringConversationScope property name=timeout value=35 / property name=advices list ref bean=persistentContextConversationInterceptor/ /list /property /bean /entry entry key=conversation.flash bean class=org.apache.myfaces.orchestra.conversation.spring.SpringConversationScope property name=advices list ref bean=persistentContextConversationInterceptor/ /list /property property name=lifetime value=flash/ /bean /entry Ciao, Mario
Re: [orchestra] unable to persist in sub thread
Hi Dan! My thread has the same service bean that is in the main thread has, so I guess both thread sharing the same Persentent Context. Now I need to figure out how to Create my Persitent Context in the child thread which a little disappointed. My goal is to use the same service bean. Is there a way to use the same service bean but with diffrent persistent context? You mean the same instance of the bean or just the same class? The same instance might not be possible. But what if you configure your service bean two times? Then you'll be able to get two instances. If this wont help, could you provide some small code-pieces (spring config, beans, service bean, thread stuff) to figuring out what you'll going to do more exactly. Maybe as a patch against our examples would be great. Ciao, Mario
Re: JSF 1.2 API backward compatible?
Hi! I found the problem. I requested the to-be-decorated application within my constructor which failed as with an JSF 1.1. compiled class the FacesContext is required to find the JSF 1.2 default application implementation. JSF 1.2 will then dispatch the new methods to the default implementation automatically - _instead to the decorated one_. Which means, if you have a JSF 1.1. Application in the chain, inheritance do not work as expected as JSF 1.2 methods are not dispatched to the decorated application but to the default implementation. In MyFaces I can't find such a behavior at all, isn't it defined by the spec? I event can't use the proxy based solution as the Application isn't an interface and using AOP fails as the com.sun.faces.application.ApplicationAssociate checks that it hasn't been instantiated twice. (via ASSOCIATE_KEY in the application map) It's odd. Ciao, Mario
Re: [Orchestra] Latest snapshot throws UnsupportedException
Hi Dan! Ok, next try please. I've changed Orchestra to use JSF 1.2 during the build process so that I do not need a proxy based solution which seems to be not possible with the RI. Now the decorated application object should also correctly delegate the JSF 1.2 methods to the original application. Hope this will make it now Ciao, Mario
[orchestra] sandbox on continuum
Hi! Could someone please setup the myfaces-orchestra-sandbox [1] project on continuum. Currently the continuum build fails due to missing artifacts. Thanks! Ciao, Mario [1] https://svn.apache.org/repos/asf/myfaces/orchestra/trunk/sandbox
Re: [Orchestra] Latest snapshot throws UnsupportedException
Hi Dan! However, the example has compilation issue C:\dev\myfaces\orchestra\examples\src\main\java\org\apache\myfaces\examples\mops \backings\PetstoreData.java:[4,44] cannot find symbol symbol : class ShopCustomerDao location: package org.apache.myfaces.examples.mops.dao Hmm ... strange, please double-check your svn update, there must be something bad as it works here on two different pcs. Ciao, Mario
Re: JSF 1.2 API backward compatible?
Hi Simon! I guess you could use a ServletContextListener to extract the default factory from FactoryFinder and then set your own instance passing it the default implementation, but that would work only if JSF's own ServletContextListener is executed before, and I'm not aware of the listener priority when placed in a tld. Thanks for your support I've fixed it by using JSF 1.2 to compile the lib and test it using the JSF 1.1 implementation ... looks like it works fine now - even if it is a dangerous way as you have to ensure not to use any JSF 1.2 stuff if you would like to keep JSF 1.1 compatibility, but thats something a developer might understand ;-) Ciao, Mario
Re: [vfs] Re: Specifying options to FTP etc..
Hi! I think the use of the ?? would not be a good URI scheme. However, maybe we could simply make the VFS parameters unique. For example add vfs. in front of them. For example, http://www/path/cgi-bin/send.pl?FILE=ABCTYPE=PDFvfs.proxyHost=proxy.hostvfs.proxyPort=8080 Yes, for sure, this could make it too - I thought about it too. Even if I am still not that happy with this query-string parsing/repacking stuff I'd commit it if someone contributes a patch. I'll help with dealing with the details, but have not much time to do it myself yet. We have to figure out: * do we rely on url-escape strings with this url parameters too? (I'd say no - except for the character itself) * if we do - how to deal with the used charset? (I'd say we expect them to be in UTF-8 then, regardless of the charset of the other parameters) * do we strip these parameters off so that we have a query string without these special fields when sending to the remote host? (I'd say yes) * enhance the filename so that we have the queryString (as now) and a remoteQueryString which will be passed to the remote server * use the new remoteQueryString e.g. with the http filesystem implementation. It would be great if someone could open a JIRA ticket at least that we don't loose the request. Thanks! Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Orchestra integration with legacy Hibernate 2 app
Hi! The Orchestra installation page has a tantalizing sentence: The installation guide will show you how to setup a JPA entity manager ..., later a chapter explaining how to access Hibernate directly will be added. Yep, we use it here with a completely custom way of how to get in touch to the session. It seems that having a HibernatePersistenceContextFactory, an analog of JpaPersistenceContextFactory, might go a long ways. I Googled for that and found such a class on Mario's blog. I dropped that in to my trivial app and adjusted the related objects but the first database access fails with Session is closed! Hmmm ... thats strange, could you please try to add a breakpoint in HibernatePersistenceContextFactory at the close() method (statement: em.close();) You just have to ensure, that no one else closes the session you bound in the PersistenceContextFactory. Do you use the Spring hibernate templates? If you're still out of luck, could you please provide me a link to download your mini application to reproduce the problem. Here we do not even use the Spring templates but your own way of how to get access to the session opened in the PersistenceContextFactory. In fact we just allocate a session container in the PersistenceContextFactory and add the sessions required on demand. Ok - thats another story. I am pretty sure we'll find a solution. Ciao, Mario
Companies using Orchestra - wiki page
Hi! Just in case there are already people using MyFaces Orchestra in their day work (which will grow I hope), your are invited to add your company to the wiki page [1]. Thanks! Ciao, Mario [1] http://wiki.apache.org/myfaces/Companies_Using_Orchestra
Re: [Orchestra] Latest snapshot throws UnsupportedException
Hi Dan! Changes starting rev 572370 gives me this stack trace java.lang.UnsupportedOperationException I still develop with JSF 1.1 and I think a JSF 1.2 change triggers this exception - odd. Please try the latest version which should solve this problem for now by using a proxy instead of inheritance. Ciao, Mario
JSF 1.2 API backward compatible?
Hi! Is the JSF 1.2 API backward compatible? An application developed with the JSF 1.2 API should run on 1.1 as long as no 1.2 specific stuff will be used, no? I ask as I had a UOE in orchestra which seems happened after I override the ApplicationFactory (and the Application) but still use JSF 1.1. For now I changed to a proxy based solution, but it can't be that I now have to proxy every delegation, can it? Ciao, Mario
Re: JSF 1.2 API backward compatible?
Hi! It's the opposite, as for any backward compatible system. It means that you can, theoretically, run a JSF 1.1 application on a 1.2 system. I haven't looked at it in very detail, but it seems if you provide your own javax.faces.application.Application compiled with JSF1.1 the method getELResolve will be used from the JSF1.2 implementation which seems to throw an UOE as you can see here (reported from Dan Tran as Orchestra bug) java.lang.UnsupportedOperationException javax.faces.application.Application.getELResolver(Application.java:443) com.sun.faces.context.FacesContextImpl.getELContext(FacesContextImpl.java:174) javax.faces.component.UIViewRoot.setLocale(UIViewRoot.java:900) So, I'd say upward API compatibility is broken here. Ciao, Mario
Re: [Orchestra] Latest snapshot throws UnsupportedException
Hi! However, the proxy solution does not work either, unforturnately my app crashes at startup with no provided stacktrace. :( Please try again ... hope it works, else I'll have a look at it tomorrow setting up a JSF 1.2 environment. Thanks! Ciao, Mario
Re: JSF 1.2 API backward compatible?
Hi!
This is, indeed, a compatibility issue. However, I assume it's caused
because you did not use the decorator pattern when you applied your
custom Application implementation, so now you're inheriting from the
default implementation method behavior, which is to throw an
UnsupportedOperationException.
Sure, but what can I do other than from inherit from
javax.faces.application.Application? I am not aware of any other wrapper
class.
I have to simple classes:
public class OrchestraApplicationFactory extends ApplicationFactory
{
private final ApplicationFactory original;
public OrchestraApplicationFactory(ApplicationFactory original)
{
public class OrchestraApplication extends Application
{
private final Application original;
public OrchestraApplication(Application original)
{
this.original = original;
}
with implementing all the JSF 1.1 stuff and dispatch to this orignial
implementation. The factory simply create the application from the
original factory and wraps it using the OrchestraApplication.
I dont see how I can create a JSF 1.2 compatible Application with just
the JSF 1.1 libs.
So, I'd say upward API compatibility is broken here.
I call that a backward compatibility issue, since you're trying to
execute an application developed with an older API with a newer version.
Hehe - ok - I wont stress this :-)
Ciao,
Mario
Re: svn commit: r571710 - /myfaces/core/branches/1_2_1/api/src/main/java/javax/faces/webapp/_ErrorPageWriter.java
Hi!
+//handle JSP-Exceptions - equally long know for swallowing root-causes
;)
+if(ex.getClass().getName().equals(javax.servlet.jsp.JspException)) {
+initCausePerReflection(ex,getRootCause);
+}
Why do you check against the class name all over?
I think checking if there is a getRootCause else fallback to getCause
would do it, even for inherited classes then.
In shared.util we have a ExceptionUtils class which do it that way -
works pretty fine.
Ciao,
Mario
Re: [orchestra] ViewController package.html
Hi! Yes, I am perfectly fine with this. Ciao, Mario Hi, Here's a proposed package.html for the ViewController stuff in core. Mario, is this ok? (sorry, line-wrapping is stuffed up).. html body Provide lifecycle callbacks (on view creation, pre-render, etc) for managed beans. p The ConversationRequire annotation in Orchestra's core15 module requires lifecycle callbacks in order to work. It doesn't much matter what code triggers these callbacks, but unfortunately there is currently no open-source library available that does this and is compatible with Orchestra, so here an implementation is provided. p It is hoped that in future libraries such as Shale's ViewController module will be compatible with Orchestra, and perhaps that other alternatives also become available. p It is not one of Orchestra's goals to provide lifecycle callback features for managed beans, so this feature may be phased out when other alternatives are available. p See class ViewControllerManager for further documentation. /body /html Cheers, Simon -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: [orchestra] package javadoc for requestParameterProvider package
simon schrieb: Is the following a fair description of the requestParameterProvider package or not? It is! html body This package provides the ability for objects to add query parameters to every URL output in the page being rendered. This is used by Orchestra internally to attach the conversation context id to every link in a page (not just forms as a hidden field would do). p This feature is for the internal use of Orchestra only, and should not be used by external code; the API may change without notice. /body /html Regards, Simon -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
[orchestra] Re: no FlashScopeManager found
Hi Dan! It is stranged that i have to register that configuration file. Do you know a way how to provide configuration files for spring within an JAR which spring will automatically process? Is there any magic naming scheme? Anyhow, I follow the advice, and run into this another error. The error complain about bean not found But i do see the class in orchestra-core jar file. It is fixed now. Sorry for the inconvenience. Ciao, Mario
[orchestra] conversation timeout checking thread change
Hi! I made some changes to conserve resources regarding the conversation-timeout-checking thread. We had one thread per session which might become heavy-weight if you have to deal with a lot of sessions. Using a listener we are now able to drop down to just one thread per context. Those already using Orchestra and using the latest head version have to add the following listener to their web.xml configuration: listener listener-classorg.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener/listener-class /listener Ciao, Mario
Re: [vfs] Re: Specifying options to FTP etc..
Hi! I think we should leave it upto the scheme to decide. So http may decide to pass it to the server, while ftp may decide to use it to talk to the server. i.e. each implementation will know the options they understand, enforce them and pass any remainder to the server. How does that sound? It sounds complicated ... :-( We have to parse all the url parameters and use a special naming scheme to avoid naming clashes,no? I am not convinced that this is a good idea - you have to deal with all the url encoding stuff etc.. maybe even with the charset - which is also a FileSystemOption for some filesystems. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javax.faces.ViewState contents?
Hi!
With client state saving, I was under the impression that only managed
beans in session scope or used in t:saveState would be serialized into
the hidden javax.faces.ViewState variable. However, my application's
creating ViewStates in pages with very simple forms that are almost 70
kb long!
I've create a simple ViewState dumper which allows you to .. well ...
dump the view state :-) ... as long as you do not compression or encryption.
Just set the viewState variable to the content of the viewState in the
HTML output.
Maybe you can figure out what happens.
Unhappily there is no information about which component added the data
to the state, though, it might be a start anyway.
import org.apache.commons.codec.binary.Base64;
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.util.Collection;
public class ViewStateDumper
{
public static void main(String[] args) throws IOException,
ClassNotFoundException
{
String viewState=;
byte[] viewStateData =
Base64.decodeBase64(viewState.getBytes(US-ASCII));
ObjectInputStream ois = new ObjectInputStream(new
ByteArrayInputStream(viewStateData));
Object[] state = (Object[]) ois.readObject();
dumpState(, state);
}
private static void dumpState(String prefix, Object[] state)
{
for (Object object : state)
{
System.err.print(prefix);
if (object == null)
{
System.err.println(#null?);
}
else if (object instanceof Object[])
{
System.err.println(prefix + array);
dumpState(prefix + , (Object[]) object);
}
else if (object instanceof Collection)
{
System.err.println(prefix + collection);
dumpState(prefix + , ((Collection) object).toArray());
}
else
{
System.err.print(object.getClass().getName());
System.err.print( );
System.err.println(object.toString());
}
}
}
}
Ciao,
Mario
Re: [Orchestra] Need ability to reopen jiar issue
Dan Tran schrieb: Just sent in another patch for ORCHESTRA-4 Applied - Thanks :-) -D Dan Tran wrote: Please configure Orchestra Jira to allow a closed jira to be reopenned. I just submitted an another patch for ORCHESTRA-4 -D -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: [jira] Created: (ORCHESTRA-5) Unable to load orchestra into eclipse
Hi! Unable to load orchestra into eclipse Can someone confirm this too? I'd wonder as this will affect tomahawk too. No one complained about it till today, or? - svn move core myfaces-orchestra-core - svn move core15 myfaces-orchestra-core15 - svn move examples myfaces-orchestra-examples What do we think about this? It is not our standard naming convention. Should we really adjust the names just to make eclipse happy? Ciao, Mario smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r567449 - in /myfaces/orchestra/trunk: core/src/main/resources/META-INF/LICENSE.txt core15/src/main/resources/META-INF/LICENSE.txt examples/src/main/resources/META-INF/LICENSE.txt
Hi Wendy! On 8/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: imario Date: Sun Aug 19 11:17:41 2007 New Revision: 567449 URL: http://svn.apache.org/viewvc?view=revrev=567449 Log: added license file The remote resources plugin can do this for you. It also generates the notice file based on the declared dependencies. Wow - coll stuff. Thanks for the tip! Ciao, Mario
myfaces-master release
Hi! Is there any need to release the myfaces-master before an orchestra release or can we just use the 1.0.5 release? --- Mario
Re: myfaces-master release
Thanks Matthias, I already found the page. What I'd like to know is, if its required to release myfaces-master or if I can move on with the already released 1.0.5 one. Mario -Original Message- From: Matthias Wessendorf [EMAIL PROTECTED] Date: Tuesday, Aug 21, 2007 10:17 pm Subject: Re: myfaces-master release To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org there is a wiki, created by manfred core 1.1.5 diary (or something like that) -M On 8/21/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Is there any need to release the myfaces-master before an orchestra release or can we just use the 1.0.5 release? --- Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
[jira] Reopened: (ORCHESTRA-4) Clean up build files
[ https://issues.apache.org/jira/browse/ORCHESTRA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits reopened ORCHESTRA-4: -- Clean up build files Key: ORCHESTRA-4 URL: https://issues.apache.org/jira/browse/ORCHESTRA-4 Project: MyFaces Orchestra Issue Type: Improvement Affects Versions: 1.0-SNAPSHOT Environment: xp Reporter: Dan Tran Assignee: Mario Ivankovits Attachments: ORCHESTRA-4-2.patch, ORCHESTRA-4.diff the pom files can be cleanup based on the following facts: - core15 depends on core, therefore lots of core15's dependencies can be removed. There is no need to unpack orchestra-share either - Repositories: remove iblio repo can be removed, maven already includes repo1.maven.org/maven2 use faster java.net maven repo. Refactor repository to the root pom - remove unnessesary unpacking of orchestra-share classes in core since we build it from source any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-4) Clean up build files
[ https://issues.apache.org/jira/browse/ORCHESTRA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-4. -- Resolution: Fixed Fixed, thanks! I don't have sufficient permisions - or don't know how - to change jira to allow reopening. Lets see if someone on the ml knows something about it. Clean up build files Key: ORCHESTRA-4 URL: https://issues.apache.org/jira/browse/ORCHESTRA-4 Project: MyFaces Orchestra Issue Type: Improvement Affects Versions: 1.0-SNAPSHOT Environment: xp Reporter: Dan Tran Assignee: Mario Ivankovits Attachments: ORCHESTRA-4-2.patch, ORCHESTRA-4.diff the pom files can be cleanup based on the following facts: - core15 depends on core, therefore lots of core15's dependencies can be removed. There is no need to unpack orchestra-share either - Repositories: remove iblio repo can be removed, maven already includes repo1.maven.org/maven2 use faster java.net maven repo. Refactor repository to the root pom - remove unnessesary unpacking of orchestra-share classes in core since we build it from source any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [orchestra] conversation timeouts
Hi! Currently orchestra has a feature that causes conversations that have not been accessed within 30 minutes to automatically be deleted. Similarly, conversation-contexts that have not been accessed within 30 minutes also get deleted. This came up [1] in relation to Shale dialogs [2], and some of the things you bring up here along with trying to encourage better developer discipline have kept us from introducing any notion of dialog timeouts there till date. I don't see that DBCP and e.g. HTTP Session timeout is comparable. With DBCP the developer clearly has a chance to provide a clean code which returns a borrowed connection - this is not the case for a HTTP Session nor for a conversation. The user can close a window or the browser or navigate to some other place within the application and you just couldn't know that. If the user came back to a page and the conversation is still active, fine, it is likely to assume that he/she would like to continue the work. If not, its clearly that we have a stale object which we have to get rid of. However, having a conversation-timeout=0 could be possible to disable any automatic cleanup - for those who requires it. IMHO a conversation or dialog timeout is in the same level than the session timeout, and no one would argue that we have to deal with that. Being able to disable it would be a fine addition, though. Ciao, Mario
Re: [orchestra] Shale overlap (was Re: ViewController stuff)
Hi! If the view-controller stuff is an optional feature of Orchestra I'd be fine with directing the users to the shale-view stuff. However, there is a single feature (@ConversationRequire) which has to be in Orchestra core15 which requires a view-controller like framework. Given the number of jars and the impact shale/shale-view has I am unsure to force it as an required dependency. With impact I mean e.g. that it replaces the UIViewRoot implementation to catch all the exception stuff. The shale-tiger stuff replaces the VariableResolver with something which explicitly checks the tree scopes to decide if it has to create the bean by itself. The VariableResolver will work with Orchestra as it won't find the bean definition, but some shale-tiger annotations wont work then. Resulting in a documentation page where we direct the user to the shale-* stuff, but telling them what Shale stuff will NOT work is also not a nice thing. What I mean is, we can direct the users to shale-view/shale-tiger for the ViewController stuff, but many of the other functions do not work - also some - ok; at least one ;-) - ViewController event wont work as shale-view explicitly tries to remove the ViewController from the request-map to force a destroy() event at the end of the request. I know, in Shale a ViewController has to be a request-scoped bean. I don't think we should force the user in this question. I wont argue against Shale at all - it is fantastic what has been done there! What I wanted to do is just something like cherry picking. IF we find a way how to provide a @ConversationRequire thing without the need of a ViewController framework we can drop Orchestras implementation. Though, everything which came in my mind so far results in ugly code. I can crop our ViewController that it just supports this single annotation Ciao, Mario
[orchestra] FrameworkAdapter setup (was Re: [orchestra] servlet filters ..)
Hi! So I am fine by adding some Framework-Adapter specified stuff to the OrchestraServletFilter - instead of creating a new filter. Isn't OrchestraServletFilter currently optional [1]? Using it to set up the FrameworkAdapter would make it mandatory... Sorry Mario, I should have read your email more carefully. As OrchestraServletFilter *is* required when using JsfFrameworkAdapter, then setting the FrameworkAdapter threadlocal makes perfect sense there. Simon, I've never received a message with the text Isn't OrchestraServletFilter . I hope there are no other messages I've lost from you :-( I am currently cleaning up the RequestParameterProvider (as proposed by Matthias). I'll now provide a FacesContextFactory and the filter. When testing the filter I've found, that it also requires the FrameworkAdapter which requires the OrchestraServletFilter to have the httpServlet* thread-locals setup appropriate. Now, my test is to configure the RequestParameterServletFilter for a non JSF request - currently it fails as the OrchestraServletFilter has not been configured for such non JSF requests - and I think it is not a good idea to do so. What if we create a FrameworkAdapterFilter to setup the stuff required for the FrameworkAdapter itself. It makes things cleaner, no? Though, then we have yet another configuration option ... :-( Maybe we can call the FrameworkAdapterFilter from the OrchestraServletFilter so that one has to configure the FrameworkAdapterFilter only in special cases. What do you think? Ciao, Mario
Re: [orchestra] missing emails from me
Hi! Simon, I've never received a message with the text Isn't OrchestraServletFilter . I hope there are no other messages I've lost from you :-( Aargh, yes there are. /snip Ouch - I already wondered why you didn't respond to my responses :-) Ciao, Mario
Re: [Fwd: Re: [orchestra] ConnectionManagerDataSource.isWrapperFor]
Hi! Hi! In ConnectionManagerDataSource, method isWrapperFor currently returns false. Perhaps it should throw UnsupportedOperationException instead? And what about a solution using reflection? Maybe the most correct solution could be: Yes, I agree that using reflection is the 100% correct solution. However it's also the most complicated. When we discussed this earlier, I think we agreed we didn't really need to do this. Yes, you are right. I've committed the throw UOE now with the reflection code in comment - just in case we need it later. Ciao, Mario
Re: [Fwd: Re: [orchestra] conversation timeouts]
Hi! One issue is that garbage collection only happens at some random time after the session is no longer used. So the timeout thread could end up calling into the ConversationManager even after the session has been explicitly removed. Possibly the ConversationManager could implement HttpSessionBindingListener and remove itself from the weak list. Is this called when a session is deleted? I think this works only for listeners configured within the web.xml. IF we create such a listener we could invalidate the conversation manager at all (e.g. on unbind) our thread can check this flag then. We can start up and shutdown the thread within this listener then. Another is that there could be potential locking issues re someone accessing a session at the same time that the timeout thread stars processing the ConversationManager in that same session. currently the thread synchronize against the conversationManager instance ... should work then too. And I'm not sure what the implications are with respect to distributed sessions. Distributed sessions are a pain (for us). The best we can do is to ensure that the conversationManager instance is correctly replicated to another node so that it has no running conversation there. On failover the other node will have no conversation and the user is redirected to the conversation start page. I'd say this is just a short interruption in the workflow - especially since I do not know how JPA at all has some definition how to replicate its session data. I need to read up on distributed sessions.. So should I :-) Ciao, Mario
Re: [orchestra] ViewController stuff
Hi! If, we have to use the (never ;-) ) upcoming myfaces-commons project. Are you willing to volunteer? What, is tomahawk dead? I must check the myfaces archives No, tomahawk is not dead, it is just that tomahawk should be a component library only while myfaces-commons has something like validators, phase-listeners, etc but no components. One might argue this should be part of Shale I don't know. We also have the AnnotationsViewControllerManager which uses the @ViewController annotation where you can configure which view-ids the bean belongs to. Hmm..this really tightly couples the source code of the bean to the current JSP structure. Moving a JSP page means changing the source code for a class... I think the whole separation between page author and bean developer works as long as you have beans just providing a service and a page uses many different beans to render its output. If you have a controller bean which gathers all the data required for the page they are coupled whatever you'll do. It still feels a little wrong to me though. /snip An alternate solution would be to force a page to declare all the beans it uses at the top of the page, and for it to be an error for any EL expression to reference a variable that has not been declared. The declarations could then be inspected to find beans to invoke lifecycle methods on. However that's not part of the JSF spec. Ok, so what we can try is to create a jsf tag which allows one to configure (all) the bean-name(s) acting as view-controller for the page. Now as the page author is the one who knows what views exist, surely it must be this person who is also responsible for defining the view-to-bean mappings. How can the application developer who writes the backing beans do this when the views (theoretically) are not written until later? It is a question of what happens first :-) I think first a view will be created acting as prototype and later the bean will be developed. But I won't get cumbersome on this. Am I right that the whole point of this ViewController stuff is just to allow the dynaForm component to work? If so, maybe what we need to do is not debate the ViewController stuff but look at whether dynaForm can be implemented in a way that doesn't need it.. No, the ViewController stuff in Orchestra is just to have a simple ViewController and based on this the @ConversationRequire annotation working. The dynaForm do not require it. Ciao, Mario
[jira] Resolved: (ORCHESTRA-4) Clean up build files
[ https://issues.apache.org/jira/browse/ORCHESTRA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-4. -- Resolution: Fixed Assignee: Mario Ivankovits Not, that I really know what I have done, but I've committed your patch. If there is something broken in the maven build - say for the next one and a half light-year - I'll ask you to fix it - I'll promise ;-) Thanks for the patch! Clean up build files Key: ORCHESTRA-4 URL: https://issues.apache.org/jira/browse/ORCHESTRA-4 Project: MyFaces Orchestra Issue Type: Improvement Affects Versions: 1.0-SNAPSHOT Environment: xp Reporter: Dan Tran Assignee: Mario Ivankovits Attachments: ORCHESTRA-4.diff the pom files can be cleanup based on the following facts: - core15 depends on core, therefore lots of core15's dependencies can be removed. There is no need to unpack orchestra-share either - Repositories: remove iblio repo can be removed, maven already includes repo1.maven.org/maven2 use faster java.net maven repo. Refactor repository to the root pom - remove unnessesary unpacking of orchestra-share classes in core since we build it from source any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [orchestra] conversation timeouts
Hi! Currently orchestra has a feature that causes conversations that have not been accessed within 30 minutes to automatically be deleted. Similarly, conversation-contexts that have not been accessed within 30 minutes also get deleted. I don't personally see the use of this, but have been assured it is important. And Seam has this feature, so I suppose we need to offer it too :-). One reason is to keep resources low. A conversation can have accessed a huge amount of database records, for every record the EntityManager hold an entities in its session cache ... resulting in a major memory consumption. Secondly, I'm worried about the scalability: a system with 1000 users will have 1000 threads created. These will mostly just be sleeping, but threads are still not light-weight objects. The main idea of a thread is to be lightweight, no? But I see the point, in terms of 1000 users it might be no longer lightweight. I briefly considered having an app-scope list of weak references to ConversationManagers, with instances adding themselves to this list as they are created but that has a number of difficult problems related to timeout/removal of http sessions. If we are using weak references there should be no problems with http sessions, are there? Once the http session has been invalidated the conversation manager should only be reachable through the weak reference (all maps have been cleared) which means it can be gc'd. This could work. At least this might help in dropping down to just 1 thread. So why not try it? (a) Do people think the current thread-based solution is really a problem? Not for a 1.0 release, however, changing to the above should be easy. if (a !b) then I would suggest removing this timeout feature from the first release to allow time to come up with an alternative. In any case, I don't think removing this feature is an alternative. IMHO it is too important. If we need alternatives we should try to find them now. In the worst case, we have to delay the release. Ciao, Mario
Re: [orchestra] ViewController stuff
Hi! There is already an implementation of this sort of thing in the Shale project's view-controller module: http://shale.apache.org/shale-view/index.html I do not have any good argument why I didn't go the shale way. Maybe I was just to shy to convince the shale people about the surely required API change which might have been resulted in an huge patch And I just doesn't know at the time of writing this stuff what the exact API changes in Shale would have been. I'd say, Orchestras implementation is just a lightweight variant of the shale stuff. If we would like to go the shale way, we have to add the shale, shale-view and shale-tiger jar to the project which requires the view controller stuff. Doesn't really help in lowering the stack required to startup an Orchestra application, does it? If the orchestra view-controller code is significantly different from shale (I don't know the shale code very well) then perhaps it could be merged into Tomahawk rather than exist in Orchestra? If, we have to use the (never ;-) ) upcoming myfaces-commons project. Are you willing to volunteer? And separately, both Shale and Orchestra ViewController implementations depend upon having managed beans with names that match viewIds in order for the controller to figure out which bean to invoke methods on. I'm not very enthusiastic about this approach as it seems fragile: We also have the AnnotationsViewControllerManager which uses the @ViewController annotation where you can configure which view-ids the bean belongs to. I would rather see something based on the JSF12 approach of phase-listeners attached to views. Ah, I should finally take some time to have a look at the new stuff in JSF12 (- any good summary about that somewhere?) In JSF12, the UIViewRoot component can now have phase listeners attached to it, and they get invoked for processing phases. These listeners are attached by adding f:phaseListener tags to the page. As a convenience, there are also attributes on f:view to configure a default Woho I wonder why the page designer should bother invoking the right phase methods on the backing bean. Isn't it the same (let's say) wrong concept than the t:saveState where every now and then people arguing that this has nothing to do in the view? Note that although the f:phaseListener tag does require the target to implement PhaseListener, I'm not suggesting that this point directly at the backing bean. Requiring a backing bean to implement PhaseListener is not very nice. There are a number of possible solutions to this that I can post if people think this approach is worth investigating further. However, if people think this is the way to go, I am sure it is easy to create such a JSF tag too. Ciao, Mario
Re: [orchestra] Dependency on tomahawk sandbox
Hi! For the release expected this week, is the orchestra core15 module (which includes dynaForm) expected to be in the release? If so, it currently depends on tomahawk sandbox component TypedNumberConverter which will make things difficult. In fact, I thought about NOT releasing the core15 module exactly due to this nasty thingy. Also the dynaForm stuff in core15 isn't documented yet and this might be a significant amount of work to do. Perhaps the right thing to do would be to copy that component into orchestra-core15 and remove it later when TypedNumberConverter makes it into an official tomahawk release? We also use the tomahawk calendar component and the InputSuggestAjax. Let's not release core15 for now ...;-) In fact, that Orchestra has a dependency into tomahawk isn't nice at all. Another solution could be to move the org.apache.myfaces.orchestra.dynaForm.guiBuilder.impl.myfaces.MyFacesGuiBuilder implementation to the tomahawk-sandbox and let the sandbox depend on Orchestra. Then we should be able to get rid on the tomahawk-sandbox at all ... and being able to release core15 soon. Should be possible I think. Ciao, Mario
Re: [orchestra] ConnectionManagerDataSource.isWrapperFor
Hi!
In ConnectionManagerDataSource, method isWrapperFor currently returns
false. Perhaps it should throw UnsupportedOperationException instead?
And what about a solution using reflection?
Maybe the most correct solution could be:
public Object unwrap(Class iface) throws SQLException
{
try
{
if (iface.isAssignableFrom(dataSource.getClass()))
{
return dataSource;
}
Method method = dataSource.getClass().getMethod(unwrap,
new Class[]{Class.class});
return method.invoke(dataSource, new Object[] { iface });
}
catch (NoSuchMethodException e)
{
throw new UnsupportedOperationException();
}
catch (IllegalAccessException e)
{
throw new SQLException(e);
}
catch (InvocationTargetException e)
{
throw new SQLException(e);
}
}
public boolean isWrapperFor(Class iface) throws SQLException
{
try
{
if (iface.isAssignableFrom(dataSource.getClass()))
{
return true;
}
Method method =
dataSource.getClass().getMethod(isWrapperFor, new Class[]{Class.class});
return Boolean.TRUE.equals(method.invoke(dataSource, new
Object[] { iface }));
}
catch (NoSuchMethodException e)
{
throw new UnsupportedOperationException();
}
catch (IllegalAccessException e)
{
throw new SQLException(e);
}
catch (InvocationTargetException e)
{
throw new SQLException(e);
}
}
What do you think?
If you don't like it, simply change the return false to the Exception
you proposed.
Ciao,
Mario
Re: [orchestra] EndConversationMethodBindingFacade
Hi! The errorOutcome attribute allows nice handling of the case where an action method throws an exception. However it doesn't close the current conversation. Yep, this is intentional. We don't wanted to force the close of an conversation as we don't know if the exception is one which requires it. Even if - in the end - the user see a error-page, no one can tell you if the webapp allows you to go back and retry. In the default Orchestra installation the developer is responsible to close the conversation when required. For our own application I've written an ActionListener/Interceptor pair which automatically closes the conversation when an exception happened and some SQL has been sent to the database. I plan to open-source this code in a different project - see myfaces-dev - but releasing Orchestra has a higher priority. Though, to make this work, you need access to internals of the JPA implementation, say, the current code just works with hibernate. Ciao, Mario
Re: [orchestra] FrameworkAdapter
Hi! The FrameworkAdapter class currently uses a static variable to find its singleton object. However static variables are tricky in unit testing, and are a problem when a library is deployed via a shared classloader. The only thing which comes to mind is using a ThreadLocal, and having a servlet request filter that sets up the threadlocal on request start and resets it on request end. This is effectively how FacesContext.getCurrentInstance works. I see no problem in doing so, just add it to the OrchestraServletFilter. Ciao, Mario
Re: [orchestra] servlet filters ..
Hi! However, I noticed that several filters are already used by orchestra, like to one to wrap the request (RequestParameterResponseWrapper) BTW also something which should make it into a myfaces-commons. Why not using a FacesContextFactoryImpl ? Hehe, we tried several things to make this work, but didn't think about this. Great idea! This will avoid one configuration step. The only advantage of the current way (servlet filter) is, that it works in an mixed webapp environment (JSF/JSP) However, we can provide your's as the default and provide mine as an alternative if we would like to. Ciao, Mario
Re: [orchestra] servlet filters ..
Hi! The only advantage of the current way (servlet filter) is, that it works in an mixed webapp environment (JSF/JSP) However, we can provide your's as the default and provide mine as an alternative if we would like to. jo, that's why I think the framework-adapter might be fine in a filter ?! I don't understand the question. You asked about the RequestParameterResponseWrapper. The Framework-Adapter is another story. I had the need to access the request/session map outside of an already setup facesContext. The JsfFrameworkAdapter already depends on the OrchestraServletFilter where we setup two thread-locals to get access to the request/response object outside of a ready setup Faces-Context, which is required right in the OrchestraServletFilter. So I am fine by adding some Framework-Adapter specified stuff to the OrchestraServletFilter - instead of creating a new filter. Ciao, Mario
Re: [orchestra] servlet filters ..
Hi! Ok, I've created a patch for review. My stupid email client wraps lines at 80 chars, so I've attached it instead of providing it inline. Using this place also to configure the FrameworkAdapter was exactly what I thought too :-) Just, maybe we can use frameworkAdapterClass as configuration parameter value? Hmmm And I am not sure if it shouldn't be a context parameter. In JSF/MyFaces nearly everything regarding the JSF System is a context parameter. But then the value should be org.apache.myfaces.orchestra.FRAMEWORK_ADAPTER_CLASS. Just an idea! Ciao, Mario
Orchestra dokumentation [was Re: svn commit: r567017 - /myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/jsf/filter/OrchestraServletFilter.java]
Hi Simon!
Thanks for all the hard work you put into documentation and cleanup of
the Orchestra API.
This really brings the project even further!
Have a nice Weekend!
Ciao,
Mario
[EMAIL PROTECTED] schrieb:
Author: skitching
Date: Fri Aug 17 04:19:22 2007
New Revision: 567017
URL: http://svn.apache.org/viewvc?view=revrev=567017
Log:
Add javadoc only.
Modified:
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/jsf/filter/OrchestraServletFilter.java
Modified:
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/jsf/filter/OrchestraServletFilter.java
URL:
http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/jsf/filter/OrchestraServletFilter.java?view=diffrev=567017r1=567016r2=567017
==
---
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/jsf/filter/OrchestraServletFilter.java
(original)
+++
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/jsf/filter/OrchestraServletFilter.java
Fri Aug 17 04:19:22 2007
@@ -33,14 +33,46 @@
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
+/**
+ * Ensures that only one request per conversationContext can be processed at
a time,
+ * and also ensure all JDBC connections are returned to the pool.
+ * p
+ * h2Request Synchronization/h2
+ * It is possible for multiple requests associated with the same http
session to be
+ * received concurrently. In particular, ajax pages can cause this.
+ * p
+ * By default, the servlet engine simply processes all requests concurrently
+ * in different threads. However that can cause all sorts of unexpected
problems with
+ * session-scoped objects.
+ * p
+ * The usual solution is to apply a filter to all requests which uses
standard java
+ * synchronisation on a session-scoped object, taking the lock on request
entry and
+ * releasing it on request exit. This ensures that only one request for that
session
+ * runs at a time, with the others waiting until they can obtain a lock on
the
+ * appropriate object.
+ * p
+ * When using an Orchestra conversationContext, session-scoped data should
be avoided and
+ * conversation-scoped beans used instead. If there is no session-scoped
data in use by
+ * an application then it is possible to allow concurrent requests to the
same http session,
+ * but NOT concurrent access to the same orchestra conversationContext. This
filter
+ * implements that, by holding a lock on a mutex object held by the
appropriate
+ * conversationContext.
+ * p
+ * This filter can be enabled or disabled via a filter init parameter;
setting
+ * serializeRequests to false disables this filter. Default value: true
(enabled).
+ * p
+ * h2JDBC Connection Management/h2
+ * Orchestra provides a special DataSource wrapper that can be configured
for any
+ * datasource used by the application. The datasource simply wraps all real
Connection
+ * objects it returns in a proxy, and keeps track of them. Here in this
servlet it
+ * checks whether all connections borrowed by this thread have been
returned, and if
+ * not returns the real connection nulls out the connection held by the
proxy. See
+ * ConnectionManagerDataSource for more details.
+ */
public class OrchestraServletFilter implements Filter
{
/**
- * true|false
- * Allows to configure if Orchestra should serialize each request
against the conversationContext.
- * This means, that e.g. if multiple threads (in an ajax environment)
concurrently access the
- * conversationContext would not bother each other.
- * Default: true
+ * This filter init property can be set to true or false. Default:
true.
*/
public final static String SERIALIZE_REQUESTS = serializeRequests; //
NON-NLS
private final static String CONTEXT_MUTEXT_OBJECT =
OrchestraServletFilter.class.getName() + .SER_MUTEX;
Re: svn commit: r566325 - /myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/ppr/PPRPanelGroupRenderer.java
Hi!
Where does the responseWriter get the encoding from?
Is that configured?
Like your code, it gets it from
pageContext.getRequest().getCharacterEncoding() (in UIComponentTag),
however, there is no need to do any instanceof and cast if you ask the
ResponseWriter later then.
Ciao,
Mario
cheers
Ernst
On 8/15/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/ppr/PPRPanelGroupRenderer.java?view=diffrev=566325r1=566324r2=566325
+ String encoding = UTF-8 ; // Hardcoded default
+ if(externalContext.getRequest() instanceof HttpServletRequest){
+ HttpServletRequest request = (HttpServletRequest)
externalContext.getRequest();
+ if(request.getCharacterEncoding() != null)
+ encoding = request.getCharacterEncoding();
+ }
Hmmm wouldn't be the correct way to do this to ask the
ResponseWriter about the encoding?
Something like:
String encoding = facesContext.getResponseWriter().getCharacterEncoding();
Ciao,
Mario
Re: [orchestra] first release
Hi! Do we still plan to cut the first release soon ?? Yes, just hat to do some enhancements (annotations) and had to write an article. Next is to finish some online documentation which should happen during the weekend. Next week is the release week. At least, thats the master plan :-) Ciao, Mario
Re: [orchestra] first release
Dan, they are already committed and fixed! Ciao, Mario Anxious to see my patches into the release. Thanks -D Mario Ivankovits wrote: Hi! Do we still plan to cut the first release soon ?? Yes, just hat to do some enhancements (annotations) and had to write an article. Next is to finish some online documentation which should happen during the weekend. Next week is the release week. At least, thats the master plan :-) Ciao, Mario -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: ClassCastException trying to cast MemoryUserDatabase to UserDatabase
Hi!
A more flexible option is to use securityfilter
(http://securityfilter.sourceforge.net) to handle everything.
If you are already using spring have a look at ACEGI.
It is not really easy to install, but allows you to e.g. have different
login methods within the same webapp.
Regarding the principal. Remember, you can always use reflection to
break into an object (given you use no securitymanager or a liberal
configured one).
For example, I used for a while:
try
{
Method hasRoleMeth =
principal.getClass().getMethod(hasRole, String.class);
return (Boolean) hasRoleMeth.invoke(principal, role);
}
catch (NoSuchMethodException e)
{
log.error(e.getLocalizedMessage(), e);
}
catch (IllegalAccessException e)
{
log.error(e.getLocalizedMessage(), e);
}
catch (InvocationTargetException e)
{
log.error(e.getLocalizedMessage(), e);
}
Ciao,
Mario
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClassCastException trying to cast MemoryUserDatabase to UserDatabase
Hi! Mario, you are a hero. do women come and worship you in the street? Haha! Oh boy ... you don't want to know ... Glad it helped you! :-) Ciao, Mario - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r566325 - /myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/ppr/PPRPanelGroupRenderer.java
Hi!
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/ppr/PPRPanelGroupRenderer.java?view=diffrev=566325r1=566324r2=566325
+ String encoding = UTF-8 ; // Hardcoded default
+ if(externalContext.getRequest() instanceof HttpServletRequest){
+ HttpServletRequest request = (HttpServletRequest)
externalContext.getRequest();
+ if(request.getCharacterEncoding() != null)
+ encoding = request.getCharacterEncoding();
+ }
Hmmm wouldn't be the correct way to do this to ask the
ResponseWriter about the encoding?
Something like:
String encoding = facesContext.getResponseWriter().getCharacterEncoding();
Ciao,
Mario
Re: [orchestra] question about Spring custom scopes
Hi! I would say your assessment is correct. If this is slow, how about caching the connection of bean-name - scope-name somewhere? I've talked to Simon, lets create a test case first to measure the times. Lets see action afterwards. Ciao, Mario smime.p7s Description: S/MIME Cryptographic Signature
Re: Is it possible to develop a JSF application that gracefully degrades?
Hi! Manfred Geiler is going to commit something to MyFaces (impl) soon which will allow JSF without JavaScript, even displaying things like links (by styling buttons as links). Stay tuned... With having f:param still working? Cool stuff! Ciao, Mario
Re: [orchestra] introduction
Hi Simon! I just wanted to let you know that I'm back working on JSF stuff again, and in particular plan to help Mario with Orchestra. I think it would be fair to tell the list also that we are co-worker for the next (approximately) 2 years. I hope it's ok if I use those existing commit rights again! I won't be making any changes without getting agreement on the list first... Naturally I would be happy if you use your existing commit rights to help with further development :-) --- Mario
Re: [orchestra] static log objects
Hi! I've noticed that a number of Orchestra classes use private static final Log log = ; See class ConversationManager for an example. I don't think static log objects are a good idea in libraries, as described here: http://wiki.apache.org/jakarta-commons/Logging/StaticLog Yepp, I know. I just did it that way to hear/read your words about this topic again :-D ... Sorry, couldn't resist ;-) So, yes, please change it the way it should be. Maybe this could be a template for tomahawk/myfaces too ... later. Ciao, Mario
Re: [orchestra] ConnectionManagerDataSource and java1.6
Hi! ConnectionManagerDataSource doesn't compile with java1.6, because Sun added a new ancestor interface (Wrapper) to DataSource:-(. The new methods are isWrapperFor and unwrap. I think the best solution is just to add stub implementations of the new methods that throw UnsupportedOperationException. Ok, should be done. The alternative is for our implementations to use reflection on the underlying DataSource object to determine whether the methods are there at runtime, and if so then forward the call to the underlying datasource. This is quite doable, but probably not necessary. Yes, lets keep this thing once we really need it. Btw: do one know a concrete example whats the java.sql.Wrapper is good for? For me it sounds a little bit hacky to provide a way to bypass the proxy. Ciao, Mario
Re: [orchestra] minor issues
Hi! MockFrameworkAdapter is checked in twice * core/src/test/java/org/apache/myfaces/orchestra/frameworkAdapter * core/src/main/java/org/apache/myfaces/orchestra/frameworkAdapter This causes Eclipse to complain (as it should). Thanks for the heads up. I'll remove it. There are a number of classes that are Serializable but do not declare a serialVersionUID value. Serializable classes really should, so that later changes which don't break serializable compatibility but do change the class checksum can be correctly handled as compatible. Normally, I like starting serialVersionUID at 1 and incrementing from there for each incompatible change. AFAIK there is no way in readObject to get the serialVersionUID of the stored object, is there a way? I'd generate the serialVersionUID with any number and use a second local version which will be written first to the the stream. That way, we can react in readObject appropriate. A little bit more complex, but robust about changes. I don't think orchestra is widely enough used yet to worry about compatibility, so how about we add Especially that we have no release yet should allow us to easily change this. Also the fact, that most of the classes implement Serializable to make the webapp-container not complaining during startup/shutdown. In ConversationManager, constant CONVERSATION_CONTEXT_PARAM is public. The only user (and the only sensible user) is class ConversationRequestParameterProvider in the same package. So could this be made package-scope to avoid exposing this constant in the user API? I am not sure about this. I often found myself in bad need to get some access to a static value like this. On the other hand, I wont veto against this change. So if you think its better to have it package-scope, please do so. Ciao, Mario
[jira] Resolved: (ORCHESTRA-1) Use servlet 2.4
[
https://issues.apache.org/jira/browse/ORCHESTRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved ORCHESTRA-1.
--
Resolution: Fixed
Fix Version/s: 1.0-SNAPSHOT
thanks for the patch!
Use servlet 2.4
---
Key: ORCHESTRA-1
URL: https://issues.apache.org/jira/browse/ORCHESTRA-1
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Affects Versions: 1.0-SNAPSHOT
Environment: xp, spring 2.0.6, jsf-1.2 ri
Reporter: Dan Tran
Priority: Blocker
Fix For: 1.0-SNAPSHOT
the current orchestra fails to start my app with 2.4 container.
Please change the poms to use servlet 2.4 and add this changes
---
core/src/main/java/org/apache/myfaces/orchestra/requestParameterProvider/RequestParameterResponseWrapper.java
(revision 562289)
+++
core/src/main/java/org/apache/myfaces/orchestra/requestParameterProvider/RequestParameterResponseWrapper.java
(working copy)
@@ -187,7 +187,7 @@
{
this.original.setContentType(string);
}
-
+
public void setBufferSize(int i)
{
this.original.setBufferSize(i);
@@ -227,4 +227,18 @@
{
return this.original.getLocale();
}
+
+ public String getContentType()
+ {
+ return this.original.getContentType();
+ }
+
+ public void setCharacterEncoding( String encoding )
+ {
+ this.original.setCharacterEncoding(encoding);
+ }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-2) NPE during startup with spring 2.0.6 with orchestra:name configured
[ https://issues.apache.org/jira/browse/ORCHESTRA-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-2. -- Resolution: Fixed Fix Version/s: 1.0-SNAPSHOT thanks for the patch! NPE during startup with spring 2.0.6 with orchestra:name configured --- Key: ORCHESTRA-2 URL: https://issues.apache.org/jira/browse/ORCHESTRA-2 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Environment: xp, jsf 1.2 ri Reporter: Dan Tran Priority: Blocker Fix For: 1.0-SNAPSHOT spring 2.0.6 has some fixed that trigger orchestra to fail at startup. Here is the required change Index: core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/BeanDefinitionConversationNameAttrDecorator.java === --- core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/BeanDefinitionConversationNameAttrDecorator.java (revision 562307) +++ core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/BeanDefinitionConversationNameAttrDecorator.java (working copy) @@ -39,6 +39,6 @@ definition.getBeanDefinition().setAttribute(CONVERSATION_NAME_ATTRIBUTE, conversationName); } - return null; + return definition; } } -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [orchestra] code spawns thread
Hi! I see that currently Orchestra has a feature that allows conversation contexts to be timed out (deleted) automatically. I'm a little curious about why this feature is needed. When a user's session times out the conversation data is discarded anyway. There is not only a singe conversation. A session can hold multiple conversationContexts and a lot of conversations. Thats why we have to keep track of their timeouts separate. When is it useful to have a conversation timeout shorter than the http session timeout? Always The conversation lifetime is directly connection to the database session (e.g. the Session class in hibernate or the PersistenceContext in JPA). Normally stuff like the PersistenceContext holds a local cache of all the entities handed out to the user - if you keep the conversation as long as the http session you'll also keep these object that long time ... and even worse, you'll accumulate any accessed entity there. Also, the implementation spawns a thread to periodically monitor conversations for timeout. The j2ee spec is pretty threatening about code spawning threads. In practice I've not had problems with this but nevertheless it makes me a little nervous. Hmmm ... there are tons of libraries spawning threads ... Looks like the j2ee spec is the looser in this respect. Would it be possible to instead check for conversation timeouts from a PhaseListener? Sure, would be possible. If required, we can provide both ways and allowing it to configure through a configuration option. I wouldn't mind. Ciao, Mario
Re: [orchestra] ConnectionManagerDataSource and java1.6
Hi! ConnectionManagerDataSource doesn't compile with java1.6, because Sun added a new ancestor interface (Wrapper) to DataSource:-(. The new methods are isWrapperFor and unwrap. I think the best solution is just to add stub implementations of the new methods that throw UnsupportedOperationException. Ok, should be done. Due to local testing purposes I've added these methods now. --- Mario
[jira] Commented: (ORCHESTRA-3) PropertyPlaceholderConfigurer STOPS working after the introduction of orchestra into my configuration
[
https://issues.apache.org/jira/browse/ORCHESTRA-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519214
]
Mario Ivankovits commented on ORCHESTRA-3:
--
This looks like a bug in spring.
The problem is, that
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean implements the
method afterPropertiesSet() which will be called before the
PropertyPlaceholderConfigurer was able to do its job.
I think the AbstractEntityManagerFactoryBean should implement the
BeanFactoryPostProcessor instead so that one can make use of the ordered
attribute.
I'll raise this on the spring ml.
PropertyPlaceholderConfigurer STOPS working after the introduction of
orchestra into my configuration
--
Key: ORCHESTRA-3
URL: https://issues.apache.org/jira/browse/ORCHESTRA-3
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Environment: xp, spring 2.0.6, jsf-1.2 ri
Reporter: Dan Tran
Here is my configuration, any thoughts? or can some one confirm this?
!-- Configurer that replaces ${...} placeholders with values from a
properties file --
!-- (in this case, JDBC-related settings for the dataSource definition
below) --
!-- THIS STOPS WORKING SINCE INTRODUCTION OF ORCHESTRA BEANS --
bean id=propertyConfigurer
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=location value=/WEB-INF/jdbc-hsqldb.properties/
/bean
!-- EL expression is not translated --
bean id=dataSource
class=org.springframework.jdbc.datasource.DriverManagerDataSource
property name=driverClassName value=${jdbc.driverClassName}/
property name=url value=${jdbc.url}/
property name=username value=${jdbc.username}/
property name=password value=${jdbc.password}/
/bean
The error is
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC
driver class '${jdbc.driverClassName}'
It is producable using orchestra example
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-3) PropertyPlaceholderConfigurer STOPS working after the introduction of orchestra into my configuration
[
https://issues.apache.org/jira/browse/ORCHESTRA-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519215
]
Mario Ivankovits commented on ORCHESTRA-3:
--
http://forum.springframework.org/showthread.php?t=42549
PropertyPlaceholderConfigurer STOPS working after the introduction of
orchestra into my configuration
--
Key: ORCHESTRA-3
URL: https://issues.apache.org/jira/browse/ORCHESTRA-3
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Environment: xp, spring 2.0.6, jsf-1.2 ri
Reporter: Dan Tran
Here is my configuration, any thoughts? or can some one confirm this?
!-- Configurer that replaces ${...} placeholders with values from a
properties file --
!-- (in this case, JDBC-related settings for the dataSource definition
below) --
!-- THIS STOPS WORKING SINCE INTRODUCTION OF ORCHESTRA BEANS --
bean id=propertyConfigurer
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=location value=/WEB-INF/jdbc-hsqldb.properties/
/bean
!-- EL expression is not translated --
bean id=dataSource
class=org.springframework.jdbc.datasource.DriverManagerDataSource
property name=driverClassName value=${jdbc.driverClassName}/
property name=url value=${jdbc.url}/
property name=username value=${jdbc.username}/
property name=password value=${jdbc.password}/
/bean
The error is
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC
driver class '${jdbc.driverClassName}'
It is producable using orchestra example
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
