[jira] Created: (EXTSCRIPT-142) Missing license files
Missing license files - Key: EXTSCRIPT-142 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-142 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Bernhard Huemer Assignee: Bernhard Huemer The extscript-cdi extension that has been developed is missing required license files sometimes, e.g. http://svn.apache.org/viewvc/myfaces/extensions/scripting/branches/extscript-cdi/src/main/java/org/apache/myfaces/extensions/scripting/cdi/context/ReloadingBeanManager.java?view=3Dmarkuppathrev=3D986983 http://svn.apache.org/viewvc/myfaces/extensions/scripting/branches/extscript-cdi/src/main/java/org/apache/myfaces/extensions/scripting/cdi/context/OpenWebBeansReloadingListener.java?view=3Dmarkuppathrev=3D986983 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2485) Ensure invocation of @PreDestroy methods on container shutdown/restart
[ https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800189#action_12800189 ] Bernhard Huemer commented on MYFACES-2485: -- To be honest, I'd consider this as the expected behaviour, just imagine a clustered environment. Additionally keeping for example Tomcat in mind, knowing that Tomcat serializes sessions at shutdown, I don't really know whether it's necessary to invalidate session beans in this case. Ensure invocation of @PreDestroy methods on container shutdown/restart -- Key: MYFACES-2485 URL: https://issues.apache.org/jira/browse/MYFACES-2485 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.0-alpha Reporter: Jakob Korherr Because of the fact that only ServletContextListener.contextDestroyed() is invoked on a container shutdown/restart, the correct destruction of ManagedBeans in session, view and request scope is not ensured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [core] Introduce ManagedBeanRegistry
Hey, sorry, I haven't noticed this thread, so I've already commented on the according JIRA issue (https://issues.apache.org/jira/browse/MYFACES-2485). Basically I've already mentioned it there, but I think the reason why only the contextDestroyed-callbacks are invoked is that Tomcat, by default, serializes and preserves sessions once it shuts down. However, I'm pretty much sure that implementing such a registry introduces more issues than it resolves (assuming that you consider this to be an issue at all - which I wouldn't do). As Jan-Kees has already pointed out, you can't just invalidate sessions once a container shuts down in a clustered environment. I think it would break the whole idea of a clustered environment. regards, Bernhard Jakob Korherr wrote on 01/13/2010 09:17 PM (GMT): Hi, MyFaces is already using all available Listeners (HttpSessionAttributeListener, HttpSessionListener, ServletContextListener, ServletContextAttributeListener, ServletRequestListener, ServletRequestAttributeListener) to invoke @PreDestroy on the Managed Beans and this happens via a pass-through from StartupServletContextListener, so you don't have to configure two listeners in web.xml (or tld). The problem is, as you thought, that those listeners (e.g. HttpSessionListener) are not invoked on a container shutdown/restart. Only contextDestroyed from ServletContextListener is invoked (tested today on Apache Tomcat 6). I will not change anything of the existing behavior, I just want to make sure that all still existing ManagedBeans get their @PreDestroy method called in contextDestroyed. But I would not get a reference to them, if I do not register them in a ManagedBeanRegistry. Regards, Jakob 2010/1/13 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com Hey, How about an HttpSessionListener? I'm not sure if HttpSessionListener.contextDestroyed is invoked on shutdownthough. Probably not... I'm afraid the only option is custom bookkeeping, maybe using an HttpSessionListener/ServletContextListener to publish events to the Registry. I see some issues with this approach: 1 Configuration becomes more difficult for the application developer, because these two Listeners become required configuration. 2 Managing objects yourself may be tricky business. An option could be to use WeakReference/WeakHashMap for this so you don't accidentally keep your objects alive. 3 What to do with regards to session replication on a clustered environment? I'm not sure this will become an issue, but it wouldn't surprise me if it will. Regards, Jan-Kees 2010/1/13 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com: Hi guys, To ensure the execution of the ManagedBean's @PreDestroy methods on a container shutdown/restart, I would like to introduce a ManagedBeanRegistry, in which all active ManagedBeans from all scopes are referenced. The problem is the following: At the moment on a container shutdown or restart, only contextDestroyed is invoked (tested in tomcat 6), thus only the @PreDestroy methods of all ApplicationScoped ManagedBeans will be invoked, but not those of any existing ManagedBeans in session, request, view (and maybe also custom) scope, because they can not be referenced in contextDestroyed(). Any opinions on that? Thanks in advance! Regards, Jakob
[jira] Commented: (MYFACES-2485) Ensure invocation of @PreDestroy methods on container shutdown/restart
[ https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800198#action_12800198 ] Bernhard Huemer commented on MYFACES-2485: -- What I'm saying is basically don't try to mess with the container. If it really turns out to be an issue, it's definitely container related and has nothing to do with MyFaces (and I'd even suggest not to work around that issue in this case, because we'd possibly mess up things regarding holding invalid references and so on ..). It's the container's responsibility to invalidate the session properly. If the user doesn't like the serialization-default he just has to configure Tomcat accordingly and I just presume that the session callbacks will then be called once the container shuts down (otherwise I'd consider this as a container bug probably). So why am I against working around this, if it really turns out be an issue? Well, basically because destructing session beans solves that issue only partly, what about the StateManager's views? What about basically everything else that's in the session? Regarding the view and request scoped beans, well if you're able to find a request scoped bean that hasn't been destroyed once the container shuts down (assuming that there is no active request), congratulations, you've found another container bug. View-scoped beans are probably somehow saved in the user's session, aren't they (sorry, I don't know JSF 2.0 very well)? If that's the case, you don't even have to consider it, because what I've written above just applies to these beans as well (i.e. don't try to mess with the container's responsibilities). Ensure invocation of @PreDestroy methods on container shutdown/restart -- Key: MYFACES-2485 URL: https://issues.apache.org/jira/browse/MYFACES-2485 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.0-alpha Reporter: Jakob Korherr Because of the fact that only ServletContextListener.contextDestroyed() is invoked on a container shutdown/restart, the correct destruction of ManagedBeans in session, view and request scope is not ensured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2485) Ensure invocation of @PreDestroy methods on container shutdown/restart
[ https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800228#action_12800228 ] Bernhard Huemer commented on MYFACES-2485: -- Well, again I beg to differ, because a container only shuts down after all threads within any servlet's service method have exited or after a certain timeout period has passed (that's at least how it's supposed to be the case according to Sun - otherwise you've come across an issue ..). So, if you know that you've got potentially long-running requests, just increase that timeout period, just to be sure - that's it. Regarding the client-side state view-scoped beans, I'm just curious, how are you going to destroy those beans if they are actually saved client-side? There's no connection to that client anymore after all? Does the view itself get invalidated as well if the container restarts? Ensure invocation of @PreDestroy methods on container shutdown/restart -- Key: MYFACES-2485 URL: https://issues.apache.org/jira/browse/MYFACES-2485 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.0-alpha Reporter: Jakob Korherr Because of the fact that only ServletContextListener.contextDestroyed() is invoked on a container shutdown/restart, the correct destruction of ManagedBeans in session, view and request scope is not ensured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2485) Ensure invocation of @PreDestroy methods on container shutdown/restart
[ https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800252#action_12800252 ] Bernhard Huemer commented on MYFACES-2485: -- Yep, leaving it as it is is basically what I'm suggesting. I think there's actually no need to change anything, it's simply put none of our business if there's a bug in terms of cleaning up a container that shuts down. In fact, I can't think of another web framework that cares about it either (though this carelessness of course doesn't necessarily mean it's not an issue that has to be resolved, but I think I've already explained why those frameworks probably don't care). Have a nice day, regards! :-) Ensure invocation of @PreDestroy methods on container shutdown/restart -- Key: MYFACES-2485 URL: https://issues.apache.org/jira/browse/MYFACES-2485 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.0-alpha Reporter: Jakob Korherr Because of the fact that only ServletContextListener.contextDestroyed() is invoked on a container shutdown/restart, the correct destruction of ManagedBeans in session, view and request scope is not ensured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ext-scripting status
Under normal no locking circumstances, the beans get replaced in the middle of the request because someone else triggered it for the application singleton, which is probably fine but somewhat dirty because in some cases this might end up with a temporary classcast exception which is resolved then at the following request cleanly. Well, you're listing more and more issues that are only valid if you refresh beans at the beginning of a request. What you're saying is that the application is in an inconsistent state from the moment you recompile classes until the beginning of the next request that refreshes beans, renderer, etc. for which those recompiled classes are relevant. However, to be more precise you'd have to say that the application is in an inconsistent state from the moment you recompile until all the relevant artifacts are refreshed. As you refresh artifacts only at the beginning of a request, you'll have to somehow synchronize requests, granted, but that doesn't mean that it's necessarily also the case if you'd refresh artifacts in your daemon thread instead. Ensuring that the recompile/refresh operation is an atomic one is just so much easier, if you don't have to wait for the next request for the refresh (as - again - that's where you refresh artifacts). What we are talking about here is a 1% corner case which imposes 90% extra work in that area, and that is definitely a post 1.0 thing to solve. Granted, but just don't get me wrong. I've never meant to point out every single tiny, inconvenient and maybe even insignificant issue as you were the one who brought up the Windows file locking issue (which I btw. still doubt that it exists as even Windows provides - if I'm not mistaken and if not specified otherwise - exclusive read, write and delete access to one process at a time only). What I'm saying is, yes, there are certain race conditions, but that's at least partly a result of your JSP-like refresh approach. [...] (the biggest issue simply is the singleton constructs like application scoped managed beans, that means double buffer the class files so every compile has to go into a separate dir, [...] Why do you think that you have to use separate directories all the time? Once the class loader has loaded the class, it's in the main memory anyway, just reuse the in-memory definition of the class and then you could basically drop the class file on the file system. What you mean is probably to somehow freeze the reloading process so that it only picks up reloaded classes at a certain time, but that doesn't require you to use separate directories (and again, that's only required if you refresh artifacts JSP-like). For example, you could do something like: save the time stamp of the beginning of the request and only reload class definitions if the last modified time stamp of the according class file is less than the previously saved one (i.e. basically if the class file has been recompiled before the beginning of the current request, use it - which also means, you won't care about recompiled classes during the request). However, that's just an idea, I haven't tried it as I don't have to implement something like that in my case. And to go back to the original discussion, the compile trigger point is mostly a matter of preferrence, I have to admit doing the compile on request start was just because I had jsps behavior in mind, when I was coding it, I was not even thinking of doing it parallely in the watchdog daemon thread. .. which is why I told you about the possibility of doing it that way now. You know, four eyes can see more than two and I really like this module, I think it could be a great advantage of MyFaces. That's why I'm trying to suggest improvements as far as possible. ;-) regards, Bernhard Werner Punz wrote on 12/12/2009 10:31 AM (GMT): Bernhard Huemer schrieb: I´d rather have a single pretictable triggering point than having the compiler being triggered continously in unpredictable manner. A standalone developer can code and save and can cause continous errors. But at the time he hits refresh, he can be pretty sure that his code should work (well often it does not but that is a different matter) Even if you compile continuously the developer can introduce mistakes, save them and the application won't pick them up as it simply doesn't compile anyway - or do you mean runtime errors? Just thinking about it - apparently it doesn't really matter at which point you pick up the changes as long as you pick them up at all (which you do), which basically means, if the developer introduces runtime errors at runtime it will affect your application regardless of whether you recompile it JSP-like or not (btw. using the term JSP-like as a way to express how you manage compilation isn't really precise either as e.g. the Jasper 2 engine provides background compilation as well - but let's stick with the usual approach
Re: ext-scripting status
If you compile and refresh asynchronously without having old states of the objects not only the classes you basically exchange classes and objects in the middle of a request. Ok granted this does not happen to often but it can happen! So what happens, is that a) the user has to wait in the middle of request processing that the atomic compile and refresh is done (or not depending what you want to lock there) and then to the worse you suddenly in the middle of the request you have the beans and classes exchanged. Ok this is not too different to what happens if you refresh in request level if you dont streamline the requests during the compile and refresh cycle. So pretty much you end up with one request in an inconsistent state and probably errors. Yes, both beans and classes will be refreshed at any time during the request, but unfortunately I can't see how that - and please correct me if I'm wrong as I think you haven't really explained that either - introduces inconsistency. It's basically just a clone using a different class, in fact (if it wouldn't raise a ClassCastException) you could even call something like oldBean.equals(newBean) and it would return true. Apart from the fact that the new bean is an instance of a different class, those two versions don't differ at all. Well, the fact that they're using two different classes might seem like big deal at first, I mean, if that's not a huge difference, what else is? However, the refresh operation drops all outdated beans, renderer, etc. at once, so unless you somehow cache those outdated beans on your own as well, it won't introduce inconsistencies. The former problem's something that neither a new request can fix though. I've got the feeling, however, that you've implemented more aspects differently, I don't know. See it that way, bean a references classes b and c, c on a later stage loaded dynamically. By the time the class of a and b and c gets recompiled c has not been loaded, a developer/user hits the refresh at a time the compile is in full force or has a running request at the time he still has the old reference to a, but then because the classes are exchanged exactly at the request b and c get refreshed, b and c are referenced, b is still picked up because the old version is in the ram, but c is loaded dynamically and not yet in ram, and you might end up with an error because something does not match (in the worst case classcast along the lines of c cannot be cast to c), because for a and b you are still on the old version while c is loaded from the new version. Okay, I'll tell you how that works in my case, though I'm not really sure if I got your example entirely right (in fact I am most probably mistaken). The thing is if class A somehow references class C, C already has to be loaded at that time - you cannot even load the class A otherwise. Now if the developer modifies the class C, obviously the daemon thread will notify the system to refresh all relevant beans. If it turns out, that there is a relevant bean of a different class (e.g. the relevant bean somehow has a dependency on something that is of the type C), the system will tell the reloading class loader in my case to forcefully reload that particular class (i.e. assuming that the relevant bean is an instance of the class A, it will also reload A again, regardless of whether the source actually changed or not). The purpose of this forceful reload is to correct linkage dependencies, i.e. if the class A on its own depends on class C (e.g. there's a setter setC(C c)), it will reload A just in order to ensure that it's using the correct version of C. You cannot really implement it in a different way I suppose as otherwise you've got to take care with the order how you refresh classes and beans (i.e. determine the class that no other class depends on and refresh that at first, etc.. - doesn't work for cycles though). regards, Bernhard Werner Punz wrote on 12/12/2009 03:09 PM (GMT): Bernhard Huemer schrieb: Under normal no locking circumstances, the beans get replaced in the middle of the request because someone else triggered it for the application singleton, which is probably fine but somewhat dirty because in some cases this might end up with a temporary classcast exception which is resolved then at the following request cleanly. Well, you're listing more and more issues that are only valid if you refresh beans at the beginning of a request. What you're saying is that the application is in an inconsistent state from the moment you recompile classes until the beginning of the next request that refreshes beans, renderer, etc. for which those recompiled classes are relevant. However, to be more precise you'd have to say that the application is in an inconsistent state from the moment you recompile until all the relevant artifacts are refreshed. As you refresh artifacts only at the beginning
Re: ext-scripting status
What about following hypothetical case
private void doSomething() {
.. long running
C myVar = appContext.getBean(C);
.. long running
}
Okay, first of all, yes, that will eventually result in a
ClassCastException, but there is a different reason for that. If you
circumvent dependency management, well then, sorry, there's no way to
get to know that dependency then. However, the cause of this problem is
not a race condition, it's just missing information. So basically it
will always raise an exception, regardless of how many more requests the
user initiates (i.e. the only advantage that synchronizing requests
has in this case is that it won't fail for that particular request, but
it will fail for the following ones as well).
regards,
Bernhard
Werner Punz wrote on 12/12/2009 08:00 PM (GMT):
Bernhard Huemer schrieb:
Okay, I'll tell you how that works in my case, though I'm not really
sure if I got your example entirely right (in fact I am most probably
mistaken). The thing is if class A somehow references class C, C
already has to be loaded at that time - you cannot even load the class
A otherwise. Now if the developer modifies the class C, obviously the
daemon thread will notify the system to refresh all relevant beans. If
it turns out, that there is a relevant bean of a different class (e.g.
the relevant bean somehow has a dependency on something that is of the
type C), the system will tell the reloading class loader in my case to
forcefully reload that particular class (i.e. assuming that the
relevant bean is an instance of the class A, it will also reload A
again, regardless of whether the source actually changed or not). The
purpose of this forceful reload is to correct linkage dependencies,
i.e. if the class A on its own depends on class C (e.g. there's a
setter setC(C c)), it will reload A just in order to ensure that it's
using the correct version of C.
Well I do the same but I drop just the beans for not having the same
control as you have in spring.
As far as I know your system that only works on spring level and do you
put the requests on hold while the object and class refresh happens?
What about following hypothetical case
private void doSomething() {
.. long running
C myVar = appContext.getBean(C);
.. long running
}
Now lets assume following case:
A is currently processing doSomething, the compile is in full process
and has compiled C, you load C via the app context, the running A
then assignes a new class of C to the old C myVar and you run into
the famous classcast exception.
I am in this case somewhat safe in single user environments because
the refresh happens synchronously, and I still think that either
synchrionizing the compile operation between requests is the cheapest
way to go to prevent a situation like that.
So there are either two chances, you have to find a way that doSomething
does not start in the first case or you have to wait until doSomething
has stopped before doing the compile.
The forceful reload is quite nice, I use it very similarily, but since I
dont have springs dependency capabilities I do it differently, but the
issue still stays, you will run into a classcast Exception that way.
Give it a try do something along the lines of
private void doSomething() {
..
while(true) {
C myVar = appContext.getBean(C);
Thread.sleep(...)
}
}
and then chance C you will get the classcast exception here! Because you
cannot terminate the doSomething here but the classloader will push in
the C to the old reference!
You cannot really implement it in a different way I suppose as
otherwise you've got to take care with the order how you refresh
classes and beans (i.e. determine the class that no other class
depends on and refresh that at first, etc.. - doesn't work for cycles
though).
regards,
Bernhard
Werner Punz wrote on 12/12/2009 03:09 PM (GMT):
Bernhard Huemer schrieb:
Under normal no locking circumstances, the beans get
replaced in the middle of the request because someone
else triggered it for the application singleton, which
is probably fine but somewhat dirty because in some
cases this might end up with a temporary classcast
exception which is resolved then at the following
request cleanly.
Well, you're listing more and more issues that are only valid if you
refresh beans at the beginning of a request. What you're saying is
that the application is in an inconsistent state from the moment you
recompile classes until the beginning of the next request that
refreshes beans, renderer, etc. for which those recompiled classes
are relevant. However, to be more precise you'd have to say that the
application is in an inconsistent state from the moment you
recompile until all the relevant artifacts are refreshed. As you
refresh artifacts only at the beginning of a request, you'll have to
somehow synchronize requests, granted
Re: ext-scripting status
Hey, but there is another issue regarding Windows yet, I also have not set the mutexes in the compiler parts to avoid windows filelocking if more than one user hits the server. now I'm not entirely sure anymore what you think this module's usage is intended to be like or maybe I'm just getting some implementation details wrong, but I thought that it's a developer changing some bits of a source file who triggers the compilation process (i.e. a daemon thread will pick up those changes and issue compilation, isn't that the case?)? There's no user (user != developer) involved in the whole process at all, is there? Hence the only race condition that I can see is like what happens if two or more developers edit the same source file, and I doubt you want to even bear that race condition in mind. Even if it's the user who triggers the compilation process (i.e. this case assumes you only recompile changed source files on demand), I think you don't have to worry about file locking as long as you synchronize the compiler usage. Nonetheless I still doubt that it's the user who triggers that, so that's just hypothetical and irrelevant nonsense anyway. regards, Bernhard Werner Punz wrote on 12/11/2009 03:28 PM (GMT): Jan-Kees van Andel schrieb: Yeah, so do I, but at work I have to use Windows (at least I have Cygwin installed) and at home I also like to play recent games. ;-) But if it's only a file separator issue, I can maybe fix it myself and build from the sources. (and of course commit it) Sorry for answering so late, but I had a hellish ride back from Zurich , came home basically at 2h30 in the morning, in between I have seen parts of Vienna I probably really would not have wanted to see, at least not during the night. Anyway back to the topic. It is probably just a handful of file separator issues with backslashes being used automatically by File.separator in Regexps. I only can guess there as well, because I have not had time yet to look into it. It is probably easily fixed by just using the commons-io Filenameutils instead, but there is another issue regarding Windows yet,I also have not set the mutexes in the compiler parts to avoid windows filelocking if more than one user hits the server. This has the same reasons, I know about it, but yet have not had time to fix it yet. The multiuser area is the one I started the day before yesterday and probably will be finalized around next week. The reason for the Windows bugs, is simply that I develop on OSX (before Linux), due to the abundance of filelocking, and the windows issues are more or less a pre alpha bugfixing thing. Getting all the features in I want comes first before going into that bugfixing round. Sorry for that, but there is only so much time I can dedicate to the project ;-), so it is either nail down the bugs, send in the patches or wait until I have fixed then, or simply use a vm for a quick testing with a Linux image ;-) Werner
Re: ext-scripting status
I´d rather have a single pretictable triggering point than having the compiler being triggered continously in unpredictable manner. A standalone developer can code and save and can cause continous errors. But at the time he hits refresh, he can be pretty sure that his code should work (well often it does not but that is a different matter) Even if you compile continuously the developer can introduce mistakes, save them and the application won't pick them up as it simply doesn't compile anyway - or do you mean runtime errors? Just thinking about it - apparently it doesn't really matter at which point you pick up the changes as long as you pick them up at all (which you do), which basically means, if the developer introduces runtime errors at runtime it will affect your application regardless of whether you recompile it JSP-like or not (btw. using the term JSP-like as a way to express how you manage compilation isn't really precise either as e.g. the Jasper 2 engine provides background compilation as well - but let's stick with the usual approach to define what JSP-like means). Anyhow if it works JSP-like in your case, then you can't just treat users and developers the same. The relationship that any developer who uses your module is a user of your module doesn't really matter when it comes to race conditions, so I'd suggest we'll ignore that fact. However, what matters is that there are people who issue requests to the web server, namely the users, and people who actually modify the source files of those applications, the developers. The problem with the users requests being the compilation trigger is apparently that you'll have to deal with race conditions as there are multiple possible request threads. If, however, the developer, or more precisely said the daemon thread that checks for file modifications, triggers compilations you've only got one thread - the file monitoring thread - that could possibly access the compiler, hence no need for synchronization at all in this case! Well, we've already talked about it a lot anyway, and it's probably just a matter of preference, I just wanted to point out some issues and compare different approaches. Maybe others want to follow that discussion as well, which is why I'm still responding to this emails as well. regards, Bernhard Werner Punz wrote on 12/11/2009 09:57 PM (GMT): Bernhard Huemer schrieb: Hey, but there is another issue regarding Windows yet, I also have not set the mutexes in the compiler parts to avoid windows filelocking if more than one user hits the server. now I'm not entirely sure anymore what you think this module's usage is intended to be like or maybe I'm just getting some implementation details wrong, but I thought that it's a developer changing some bits of a source file who triggers the compilation process (i.e. a daemon thread will pick up those changes and issue compilation, isn't that the case?)? There's no user (user != developer) involved in the whole process at all, is there? Hence the only race condition that I can see is like what happens if two or more developers edit the same source file, and I doubt you want to even bear that race condition in mind. First: developer == user in my description, the users for me are the users of the extension which is the developers! Now to the details: The daemon thread just marks the files as tainted and tbe compile then happens at the next request before the jsf lifecycle kicks in. (jsp like) I´d rather have a single pretictable triggering point than having the compiler being triggered continously in unpredictable manner. A standalone developer can code and save and can cause continous errors. But at the time he hits refresh, he can be pretty sure that his code should work (well often it does not but that is a different matter) Even if it's the user who triggers the compilation process (i.e. this case assumes you only recompile changed source files on demand), I think you don't have to worry about file locking as long as you synchronize the compiler usage. Those are the mutexes I was talking about which are currently missing ;-), I have not coded them in yet. A compiler for a single language should only be triggered by one user at all even in concurrency mode, hence you have to set a mutex/synchronized region per language. Windows really enforces this, two people compiling at the same time - file locks! In unix well no one cares! Anyway we probably can ease that limitation between languages so parallel java and groovy compile should not be an issue. But parallel java compilation is a no go! Nonetheless I still doubt that it's the user who triggers that, so that's just hypothetical and irrelevant nonsense anyway. Ouch that did hurt ;-) No this is not hypothethical nonsense, you just get this usecase basically if you have to hot patch deployments and several people work on it. Several developers
[jira] Commented: (EXTSCRIPT-27) myfaces 1.2. example doesn't run on Windoze...
[ https://issues.apache.org/jira/browse/EXTSCRIPT-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12788897#action_12788897 ] Bernhard Huemer commented on EXTSCRIPT-27: -- That's the issue I've already told you about Werner, just check whether File.separator equals \\ and if that's the case, use instead (i.e. a kinda regex-escaped escaped backslash). Should be rather easy to fix, if you haven't done it already. myfaces 1.2. example doesn't run on Windoze... -- Key: EXTSCRIPT-27 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-27 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Werner Punz 2009-12-05 13:46:20.312::WARN: Error starting handlers java.lang.ExceptionInInitializerError at org.apache.myfaces.shared_impl.webapp.webxml.WebXml.init(WebXml.java:243) at org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getWebXml(WebXml.java:228) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:74) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:139) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511) at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) at org.mortbay.jetty.Server.doStart(Server.java:210) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:134) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:332) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:277) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:195) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:183) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 1 at java.lang.String.charAt(String.java:687) at java.util.regex.Matcher.appendReplacement(Matcher.java:703) at java.util.regex.Matcher.replaceAll
[jira] Commented: (ORCHESTRA-45) Support for JSF 2.0
[ https://issues.apache.org/jira/browse/ORCHESTRA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12786455#action_12786455 ] Bernhard Huemer commented on ORCHESTRA-45: -- Unfortunately I'm not really experienced regarding JSF 2.0, but are those decorators really the only thing that you have to change in order to make Orchestra JSF 2.0 compatible? I'm just wondering, because that means that there's only a set of like three or four classes that demands the introduction of another branch? That looks like there's going to be a lot of redundant work in the future then if both versions will be maintained, isn't it? Even though this issue has already been marked as resolved, I'd hence like to propose a different solution (btw. I couldn't manage to find the discussion thread on the MyFaces mailing list? - otherwise I would have proposed it there). Apparently the problem is that if we want to support both, JSF 1.x and JSF 2.0 at once, we'll have to provide two different sets of decorators, one set that implements / extends the JSF 1.x API and one set that implements the JSF 2.0 API. The compiler can't differ between those different versions and thus the whole project has to stick to a certain version. However, to be more specific, a single compiler configuration can't differ between different versions, multiple compiler configurations in fact can! Unfortunately Maven doesn't really support the usage of multiple compiler configurations, but I've already managed to implement something similar. Basically we would have to write a custom CompilerMojo that lets you configure the compile classpath to use for a certain source folder. At runtime Orchestra would have to determine the current JSF version (which is really easy to do) and depending on this version number it would choose the set of decorators to use. For example, the project layout could as a result of that look like the following: - src\main\java - Common code for all JSF versions (even though it's called common, it compiles against the JSF 2.0 API) - src\main\jsf1x - JSF 1.x specific code (i.e. JSF 1.x specific decorators) - src\main\jsf20 - JSF 2.0 specific code (i.e. JSF 2.0 specific decorators) Basically it's as if we introduced three different modules, orchestra-common, orchestra-jsf1x and orchestra-jsf20, but it's still just a single Maven module. Of course, this solutions has got some drawbacks as well, as it will definitely confuse IDEs, i.e. you'll end up with several error messages that the IDE complains about even though it actually compiles without any errors at all. Just let me know, what you think about it. :-) Support for JSF 2.0 --- Key: ORCHESTRA-45 URL: https://issues.apache.org/jira/browse/ORCHESTRA-45 Project: MyFaces Orchestra Issue Type: Improvement Components: FrameworkAdapter Affects Versions: 1.3.1 Reporter: Martin Marinschek Assignee: Leonardo Uribe Fix For: 1.4 Attachments: jsf20upgrade.patch Orchestra should support JSF 2.0. The supplied patch changes the decorators in Orchestra to allow this, however, the patch is not backwards compatible with the 1.2/1.1 version (and contrary to supporting both 1.1 and 1.2 in one version, this is not possible with 2.0 anymore, as the interfaces have new methods which in turn have parameters/return types which are only available in JSF 2.0). The question will be how we will be able to continue. I see two options: a) a branch, and two independent releases b) adding a common JSF 1.2 compatibility library, which would allow to a certain extent to mimick basic JSF 2.0 infrastructure (it would not try to reimplement features from 2.0, however) I will also post this question to the MyFaces mailing-list, and we will see how to proceed from here. regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
Hello,
well, of course you could as well just pass the proxy, it would work.
The difference is just that in my version the proxy actually will never
be called, i.e. there's definitely no performance impact. It's just as
I've mentioned a workaround for the not-null-check in the constructor of
those wrapper classes. :-)
regards,
Bernhard
Scott O'Bryan wrote:
I don't know why you couldn't just pass the proxy, and just throw
IllegalOperationExceptions for unrecognized methods. But this one may
be a bit cleaner. Don't know.
Sent from my iPhone
On Dec 1, 2009, at 6:21 PM, Bernhard Huemer bernhard.hue...@gmail.com
wrote:
Hello,
regarding the 1st solution:
According to the JavaDocs the ServletRequestWrapper throws an
IllegalArgumentException if you pass null as delegate, so this won't
work (I'll come back to that later though). However, given that you're
worried about NullPointerExceptions in case someone calls methods that
have been introduced in the Servlet 3.0 version release, I assume that
MyFaces isn't really concerned about those methods anyway. Otherwise
you'd probably override those methods? If I'm mistaken, please correct
me as some suggestions later on rely on this assumption.
regarding the 2nd solution:
Just ignoring the @Override annotation won't work as the respective
interfaces introduce dependencies to artifacts that are only available
in a Servlet 3.0 environment (for example, there's the startAsync()
method that returns an AsyncContext). If a class loader were to load
your request / response dummy class, he would now also have to load
the class AsyncContext as it's a dependency of your class itself,
which apparently the class loader cannot do in a Servlet 2.5 environment.
Given that I'd say you'll have to create two different dummy
implementations, one that implements the Servlet 2.5 ServletRequest
interface and one that implements the Servlet 3.0 ServletRequest (i.e.
the only thing that changes is the set of methods you have to
implement). However, now another problem arises as you can't just use
two different versions of the same API in a single build, i.e. there's
no way to tell the compiler that one class just implements the methods
in the Servlet 2.5 version whereas another class has to implement the
methods of the Servlet 3.0 version. Both versions have to be
compilable using the same Servlet API version and as the Servlet 2.5
API is just a subset of the Servlet 3.0 API, both versions have to be
compilable using the Servlet 3.0 version.
The big issue now is that we've got a contradiction now. If we want to
support a Servlet 3.0 environment, we'll have to use this version in
our build (again, Servlet 3.0 is if I'm not mistaken a superset of
Servlet 2.5, that's the reason for that). However, the 2.5 version of
the dummy class cannot compile if one uses the 3.0 version for the
actual build. Maybe that sounds a little bit strange up until now, but
hopefully now it will get clearer: A 2.5 compatible implementation of
the ServletRequest interface must not implement the method
startAsync as it introduces an unsatisfiable dependency, but a 3.0
compatible build environment requires any implementation to implement
the method startAsync (amongs others) as it is a part of the
interface after all.
Hence I'm afraid but this solution just won't work either. Of course,
the third solution would probably work, but why bother about the
performance implications if there's another solution? :-)
I think the preferable solution is actually the first one. It's easy
to implement as we don't have to deal with the difference between the
Servlet 2.5 API and Servlet 3.0 API, but as I've already mentioned
there is the IllegalArgumentException issue that you just can't ignore
either. We just want to get rid of the null value somehow, so why not
use a dummy proxy instead? Note that there are no performance
implications if you override the wrapped methods anyway, i.e. in fact,
the proxy won't be called even once. It's sole purpose is to replace
the null, that's it. It could look like the following:
///
public class DummyServletRequest extends ServletRequestWrapper {
public DummyServletRequest() {
super(Proxy.newProxyInstance(
DummyServletRequest.class.getClassLoader(),
new Class[] { ServletRequest.class },
new InvocationHandler() {
public Object invoke(Object proxy, Method m, Object[] args) {
throw new UnsupportedOperationException(...);
}
}
);
}
// - Implement the interface ServletRequest now!
public Object getAttribute(String name) {
// ...
}
// ...
}
\\\
Hope that helps. :-)
regards,
Bernhard Huemer
On 12/01/2009 09:48PM GMT, Michael Concini wrote:
I need some help with the best way to handle updating the dummy
request/response objects that we use for system event listeners
kicked off when there isn't a request context. Currently, we're
implementing ServletRequest
Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
Hello,
regarding the 1st solution:
According to the JavaDocs the ServletRequestWrapper throws an
IllegalArgumentException if you pass null as delegate, so this won't
work (I'll come back to that later though). However, given that you're
worried about NullPointerExceptions in case someone calls methods that
have been introduced in the Servlet 3.0 version release, I assume that
MyFaces isn't really concerned about those methods anyway. Otherwise
you'd probably override those methods? If I'm mistaken, please correct
me as some suggestions later on rely on this assumption.
regarding the 2nd solution:
Just ignoring the @Override annotation won't work as the respective
interfaces introduce dependencies to artifacts that are only available
in a Servlet 3.0 environment (for example, there's the startAsync()
method that returns an AsyncContext). If a class loader were to load
your request / response dummy class, he would now also have to load the
class AsyncContext as it's a dependency of your class itself, which
apparently the class loader cannot do in a Servlet 2.5 environment.
Given that I'd say you'll have to create two different dummy
implementations, one that implements the Servlet 2.5 ServletRequest
interface and one that implements the Servlet 3.0 ServletRequest (i.e.
the only thing that changes is the set of methods you have to
implement). However, now another problem arises as you can't just use
two different versions of the same API in a single build, i.e. there's
no way to tell the compiler that one class just implements the methods
in the Servlet 2.5 version whereas another class has to implement the
methods of the Servlet 3.0 version. Both versions have to be compilable
using the same Servlet API version and as the Servlet 2.5 API is just a
subset of the Servlet 3.0 API, both versions have to be compilable using
the Servlet 3.0 version.
The big issue now is that we've got a contradiction now. If we want to
support a Servlet 3.0 environment, we'll have to use this version in our
build (again, Servlet 3.0 is if I'm not mistaken a superset of Servlet
2.5, that's the reason for that). However, the 2.5 version of the dummy
class cannot compile if one uses the 3.0 version for the actual build.
Maybe that sounds a little bit strange up until now, but hopefully now
it will get clearer: A 2.5 compatible implementation of the
ServletRequest interface must not implement the method startAsync as
it introduces an unsatisfiable dependency, but a 3.0 compatible build
environment requires any implementation to implement the method
startAsync (amongs others) as it is a part of the interface after all.
Hence I'm afraid but this solution just won't work either. Of course,
the third solution would probably work, but why bother about the
performance implications if there's another solution? :-)
I think the preferable solution is actually the first one. It's easy to
implement as we don't have to deal with the difference between the
Servlet 2.5 API and Servlet 3.0 API, but as I've already mentioned there
is the IllegalArgumentException issue that you just can't ignore either.
We just want to get rid of the null value somehow, so why not use a
dummy proxy instead? Note that there are no performance implications if
you override the wrapped methods anyway, i.e. in fact, the proxy won't
be called even once. It's sole purpose is to replace the null, that's
it. It could look like the following:
///
public class DummyServletRequest extends ServletRequestWrapper {
public DummyServletRequest() {
super(Proxy.newProxyInstance(
DummyServletRequest.class.getClassLoader(),
new Class[] { ServletRequest.class },
new InvocationHandler() {
public Object invoke(Object proxy, Method m, Object[] args) {
throw new UnsupportedOperationException(...);
}
}
);
}
// - Implement the interface ServletRequest now!
public Object getAttribute(String name) {
// ...
}
// ...
}
\\\
Hope that helps. :-)
regards,
Bernhard Huemer
On 12/01/2009 09:48PM GMT, Michael Concini wrote:
I need some help with the best way to handle updating the dummy
request/response objects that we use for system event listeners kicked
off when there isn't a request context. Currently, we're implementing
ServletRequest and ServletResponse directly. This is broken when using
a servlet 3.0 runtime though since we're not implementing the new
methods added by the servlet 3.0 spec.
I tried already updating the classes to extend the request/response
wrapper classes, but that turned out to be problematic since the
constructor requires a request/response object to be passed. Since we
don't have access to that as we're outside of a request I hit an NPE try
to use FacesContext that wasn't there.
I've come up with a couple of potential solutions on this and would like
some input as to the best way to go.
1) We could also extend
Re: myfaces classloaders
Personally I would prefer it if the artifact itself is responsible for
providing the corresponding class loader instead of using a try error
approach. This means that we would have to rewrite the configuration
parts of MyFaces so that not only the class name but also the class
loader to use are stored.
Note that, if I'm referring to a class loader, I don't necessarily mean
the java.util.ClassLoader, i.e. we could introduce an own ClassLoader
interface with different implementations like for example
ThreadContextClassLoader (a class that provides the current behaviour
by obtaining the webapp class loader at first), a GroovyClassLoader or
an OsgiClassLoader, etc:
///
public interface ClassLoader {
public Class? loadClass(String className);
}
public class ThreadContextClassLoader implements ClassLoader {
public Class? loadClass(String className) {
ClassLoader classLoader = getContextClassLoader();
if (classLoader == null) {
classLoader = ThreadContextClassLoader.class.getClassLoader();
}
return Class.forName(className, false, classLoader);
}
}
// ...
\\\
In doing so we would still maintain the boundaries of each Classloader.
I think otherwise it can be quite difficult to determine which class
loader has instantiated a certain JSF artifact.
regards,
Bernhard
P.S. I offer to rewrite the configuration parts of MyFaces (I've already
done that before locally for the purpose of integrating OSGi)!
Werner Punz wrote:
Well if osgi needs a different classloader which at some stages is not
the context classloader the current classloader then yes
this would help.
Werner
Bruno Aranda schrieb:
I agree if I understand it correctly. This would help as well to deal
with the classloading stuff for OSGi,
Cheers,
Bruno
2009/8/14 Werner Punz werner.p...@gmail.com:
Hia, while I am still preparing my groovy stuff I digged through
the myfaces class loading code.
Here is my problem, I currently use a custom classloader which roots
into
the groovy code and if a file is present loads the class dynamically
if not
it loads the class via the classloader currently set.
This mechanism is needed to be able to load the groovy artefacts from
various parts of jsf like view handlers, managed beans etc...
However this is messy, adding a classloader to a webapp is a no go.
I noticed that due to an issue regarding webapp startups (ear containers
change classloaders on the fly so you cannot rely on the context
classloader
alone) all the forName code already has a centralized loading
location in
place for artefacts.
To be able to deal with this problem in a clean way I would propose
following.
We should change the pattern of the classloading code to a chain of
responsibility pattern which means instead of:
public static Class classForName(String type)
throws ClassNotFoundException
{
if (type == null) throw new NullPointerException(type);
try
{
// Try WebApp ClassLoader first
return Class.forName(type,
false, // do not initialize for faster
startup
getContextClassLoader());
}
catch (ClassNotFoundException ignore)
{
// fallback: Try ClassLoader for ClassUtils (i.e. the
myfaces.jar
lib)
return Class.forName(type,
false, // do not initialize for faster
startup
ClassUtils.class.getClassLoader());
}
}
we should do it the following way
public static Class classForName(String type)
throws ClassNotFoundException
{
if (type == null) throw new NullPointerException(type);
for(ClassLoaderExtension extension: classLoadingExtensions) {
Class retVal = extension.forName(type);
if(retVal != null) {
return retVal;
}
}
throw new ClassNotFoundException(name);
}
The main issue is all the existing methods are static so we
have to add the datastructures as well in a static way
(and probably we wont need a thread safety as well so we can
get a better performance for not doing it synchronized)
With the core logic of forName being distributed over several chain
objects
And if we have a lot of those forName calls we might have a small
probably neglectable performance impact (might be fixable if we go
from arraylists to real arrays which are on assembler level cause
less operations).
This method would enable to plug in other loading mechanisms without
having to change the context classloader.
The other thing is, we need some kind of init code of the startup
servlet
context which allows to setup such custom loaders.
along the lines of
_servletContext.getInitParam(org.apache.myfaces.CustomLoaders);
I will try to prototype all this with the current myfaces trunk.
If all goes well and I can eliminate the classloader we probably should
add those extensions to
Re: myfaces classloaders
To clarify that a little bit more:
I'm more or less suggesting to introduce class loader extensions as
well, but I don't think that they should be stored centrally. Instead I
think each artifact should be able to provide the class loader extension!
Bernhard Huemer wrote:
Personally I would prefer it if the artifact itself is responsible for
providing the corresponding class loader instead of using a try error
approach. This means that we would have to rewrite the configuration
parts of MyFaces so that not only the class name but also the class
loader to use are stored.
Note that, if I'm referring to a class loader, I don't necessarily mean
the java.util.ClassLoader, i.e. we could introduce an own ClassLoader
interface with different implementations like for example
ThreadContextClassLoader (a class that provides the current behaviour
by obtaining the webapp class loader at first), a GroovyClassLoader or
an OsgiClassLoader, etc:
///
public interface ClassLoader {
public Class? loadClass(String className);
}
public class ThreadContextClassLoader implements ClassLoader {
public Class? loadClass(String className) {
ClassLoader classLoader = getContextClassLoader();
if (classLoader == null) {
classLoader = ThreadContextClassLoader.class.getClassLoader();
}
return Class.forName(className, false, classLoader);
}
}
// ...
\\\
In doing so we would still maintain the boundaries of each Classloader.
I think otherwise it can be quite difficult to determine which class
loader has instantiated a certain JSF artifact.
regards,
Bernhard
P.S. I offer to rewrite the configuration parts of MyFaces (I've already
done that before locally for the purpose of integrating OSGi)!
Werner Punz wrote:
Well if osgi needs a different classloader which at some stages is not
the context classloader the current classloader then yes
this would help.
Werner
Bruno Aranda schrieb:
I agree if I understand it correctly. This would help as well to deal
with the classloading stuff for OSGi,
Cheers,
Bruno
2009/8/14 Werner Punz werner.p...@gmail.com:
Hia, while I am still preparing my groovy stuff I digged through
the myfaces class loading code.
Here is my problem, I currently use a custom classloader which roots
into
the groovy code and if a file is present loads the class dynamically
if not
it loads the class via the classloader currently set.
This mechanism is needed to be able to load the groovy artefacts from
various parts of jsf like view handlers, managed beans etc...
However this is messy, adding a classloader to a webapp is a no go.
I noticed that due to an issue regarding webapp startups (ear
containers
change classloaders on the fly so you cannot rely on the context
classloader
alone) all the forName code already has a centralized loading
location in
place for artefacts.
To be able to deal with this problem in a clean way I would propose
following.
We should change the pattern of the classloading code to a chain of
responsibility pattern which means instead of:
public static Class classForName(String type)
throws ClassNotFoundException
{
if (type == null) throw new NullPointerException(type);
try
{
// Try WebApp ClassLoader first
return Class.forName(type,
false, // do not initialize for faster
startup
getContextClassLoader());
}
catch (ClassNotFoundException ignore)
{
// fallback: Try ClassLoader for ClassUtils (i.e. the
myfaces.jar
lib)
return Class.forName(type,
false, // do not initialize for faster
startup
ClassUtils.class.getClassLoader());
}
}
we should do it the following way
public static Class classForName(String type)
throws ClassNotFoundException
{
if (type == null) throw new NullPointerException(type);
for(ClassLoaderExtension extension: classLoadingExtensions) {
Class retVal = extension.forName(type);
if(retVal != null) {
return retVal;
}
}
throw new ClassNotFoundException(name);
}
The main issue is all the existing methods are static so we
have to add the datastructures as well in a static way
(and probably we wont need a thread safety as well so we can
get a better performance for not doing it synchronized)
With the core logic of forName being distributed over several chain
objects
And if we have a lot of those forName calls we might have a small
probably neglectable performance impact (might be fixable if we go
from arraylists to real arrays which are on assembler level cause
less operations).
This method would enable to plug in other loading mechanisms without
having to change the context classloader.
The other thing is, we need some kind of init code of the startup
servlet
context which allows
Re: MyFaces Core + Trinidad + Facelets in OSGi container
in
different web applications. However, I'm not too sure if such a
feature is really required or if I've over-engineered the whole OSGi
support thingy a little bit.
regards,
Bernhard
[1]: http://www.osgi.org/javadoc/r4v41/org/osgi/service/http/HttpService.html
Am 10. Juli 2009 03:20 schrieb Felix Röthenbacher froethenbac...@apache.org:
Bernhard Huemer schrieb:
Hi,
as I've announced something similar a few weeks ago (due to a disease,
however, I didn't have the time to contribute these changes yet), I'm
wondering how you implemented that with some modifications?
Hope you have recovered and all is well.
For example, Facelets built-in components (h:form, ...) didn't work
for me as Facelets doesn't know how to parse bundles. Of course, a
bundle is basically just a plain JAR file, but the resource URL of
those JAR files start with bundle:// instead of jar:// or
something similar which Facelets doesn't recognize properly, hence it
won't the taglibs. Additionally the default Facelets view resource
loader assumes that the views can be accessed using the
ExternalContext (i.e. it's assuming that it's deployed within a proper
WAR file, which isn't the case). Therefore I had to implement a custom
Facelets resource loader as well.
Here you are talking about using Facelets as a bundle, which is another
story. My mail referred to modifications to MyFaces Core and Trinidad.
My expression some modifications is related to MyFaces Core and Trinidad,
not Facelets.
I'm not sure what you mean with h:form is a built-in Facelets component?
I assume that you mean Facelets needs a way to parse taglibs from
other bundles like Myfaces Core and Trinidad. Just a short summary
of the way I deal with Facelets. First, I didn't find a bundled version
for Facelets version 1.1.14. So I re-package it myself adding the necessary
metadata.
Facelets uses the ContextClassLoader quite often. Luckily, there are
well defined entry points into the Facelets bundle which is the
FaceletViewHandler. I wrote a wrapper for FaceletViewHandler which sets
the ContextClassLoader of the current thread to an appropriate bundle
classloader. Hence, resources are loaded through this bundle classloader.
How do you know which bundle to use for class loading when parsing an
expression string like #{bean.propery}, where bean is a managed
bean? Don't you map beans to bundles somehow? At least I assume that
you don't based on the statement that the class loading problem
requires just some small modifications to ClassUtil.
Class loading for beans is done through the bundle classloader. If
you declare your bean packages properly in your MANIFEST.MF this
class loader will find it.
Additionally I've struggled with the dependencies of MyFaces as well,
for example, all those common-* projects, as they don't provide bundle
information within their manifest files and hence aren't recognized by
the OSGi container. However, somehow these classes have to be
accessible and therefore I have created another Maven plugin that
embeds these dependencies if the developer wants to create a OSGi
compatible MyFaces build. Basically it just creates a folder called
/META-INF/lib/ similar to /WEB-INF/lib/ and uses the manifest file
statement Bundle-ClassPath to load those libraries.
...
I use bundled versions of these libraries rather than embedding them
in my war bundle. You can find these bundles in various bundle repositories.
Don't get me wrong, if you really just require a few changes, then
feel free to contribute them, but I doubt that those changes are
sufficient. However, in order to ensure that we're not talking at
cross-purposes, please describe your execution environment a little
bit more. It seems that you're using Equinox, does Equinox provide an
OSGi HTTP service implementation on it's own? How does deployment
work, i.e does the OSGi HTTP service implementation know how to parse
a web.xml file, or do you have to register the FacesServlet
programmatically somehow?
Your question seems to be geared towards how to setup and run a working
OSGi environment. Despite this is probably not the right mailing list
just a few hints:
- Equinox as OSGi container
- HTTP service is provided by Tomcat. Could also be Jetty but
I didn't manage to setup a working environment in combination
with JSP (though PAX web apparently provides one).
- I use Spring DM tools for WAR deployment. A similar solution
exists from PAX Web for Jetty.
Actually, from my own experience, setting up a running OSGi environment
for your needs can be quite tricky and cumbersome.
- Felix
regards,
Bernhard
Am 9. Juli 2009 06:22 schrieb Felix Röthenbacher
froethenbac...@apache.org:
Hi
I recently made some modifications to MyFaces Core and MyFaces Trinidad
to get it running in an OSGi container (Equinox) together with Facelets.
I wonder if there is any interest in adding bundle metadata to MyFaces
Core and Trinidad to make
Re: MyFaces Core + Trinidad + Facelets in OSGi container
Hi,
as I've announced something similar a few weeks ago (due to a disease,
however, I didn't have the time to contribute these changes yet), I'm
wondering how you implemented that with some modifications?
For example, Facelets built-in components (h:form, ...) didn't work
for me as Facelets doesn't know how to parse bundles. Of course, a
bundle is basically just a plain JAR file, but the resource URL of
those JAR files start with bundle:// instead of jar:// or
something similar which Facelets doesn't recognize properly, hence it
won't the taglibs. Additionally the default Facelets view resource
loader assumes that the views can be accessed using the
ExternalContext (i.e. it's assuming that it's deployed within a proper
WAR file, which isn't the case). Therefore I had to implement a custom
Facelets resource loader as well.
How do you know which bundle to use for class loading when parsing an
expression string like #{bean.propery}, where bean is a managed
bean? Don't you map beans to bundles somehow? At least I assume that
you don't based on the statement that the class loading problem
requires just some small modifications to ClassUtil.
Additionally I've struggled with the dependencies of MyFaces as well,
for example, all those common-* projects, as they don't provide bundle
information within their manifest files and hence aren't recognized by
the OSGi container. However, somehow these classes have to be
accessible and therefore I have created another Maven plugin that
embeds these dependencies if the developer wants to create a OSGi
compatible MyFaces build. Basically it just creates a folder called
/META-INF/lib/ similar to /WEB-INF/lib/ and uses the manifest file
statement Bundle-ClassPath to load those libraries.
...
Don't get me wrong, if you really just require a few changes, then
feel free to contribute them, but I doubt that those changes are
sufficient. However, in order to ensure that we're not talking at
cross-purposes, please describe your execution environment a little
bit more. It seems that you're using Equinox, does Equinox provide an
OSGi HTTP service implementation on it's own? How does deployment
work, i.e does the OSGi HTTP service implementation know how to parse
a web.xml file, or do you have to register the FacesServlet
programmatically somehow?
regards,
Bernhard
Am 9. Juli 2009 06:22 schrieb Felix Röthenbacher froethenbac...@apache.org:
Hi
I recently made some modifications to MyFaces Core and MyFaces Trinidad
to get it running in an OSGi container (Equinox) together with Facelets.
I wonder if there is any interest in adding bundle metadata to MyFaces
Core and Trinidad to make them runnable in an OSGi environment? If so,
I could finalize my modifications and submit a patch with the necessary
changes.
Basically, the changes include:
- adding bundle information in MANIFEST.MF (uses Maven bundle plugin)
- assure that classes and resources are loaded with proper class loaders
The changes to MyFaces core are minor, e.g. adding a bundle activator
and small modifications to ClassUtil for class loading.
Modifications to Trinidad comprise a systematic use of ClassLoaderUtils to
load classes and resources. Currently, often
Thread.currentThread.getContextClassLoader() is used directly, which doesn't
work well in an OSGi environment.
WDYT?
- Felix
MyFaces in an OSGi environment
Hello, recently I've thought of using JSF in an OSGi environment because of the greater modularity it would provide for developers. JSF already provides reusability regarding the user interface, i.e. JSF provides the possibility to create user interface components, but what do you do if you want to reuse more aspects of previous applications than just user interface fragements? How to reuse dialogs, i.e. certain workflows, etc..? OSGi already does provide these reusability features and hence I've adapted MyFaces in a way so that it's runnable in an OSGi container. Basically you just have to deploy an implementation of the OSGi HTTP Service (e.g. Pax Web [1]), the two MyFaces bundles (myfaces-api and myfaces-impl) and your web application bundles. Basically a BundleListener keeps track of all bundles being deployed to the OSGi container, so if the user installs a JSF bundle MyFaces gets notified and merges the current configuration with the configuration of the new bundle. However, even though I've been able to implement a running version, I had to change major parts of MyFaces. For example, using OSGi you can't use the context class loader if you want to create a new instance for a class that resides in a different bundle (think of managed beans, MyFaces is responsible for creating the instance, but the class file is located in a different bundle) and hence I had to rewrite the configuration module (e.g. a LifecycleProvider implementation receives just a class name of the managed bean to instantiate assuming that it can load the class using the context class loader, but that won't work in the case of an OSGi environment). Therefore I'd like to know if I should start contributing these changes? (and if so, should I create a different branch at first, etc.?) regards, Bernhard [1]: http://wiki.ops4j.org/display/paxweb/Pax+Web
Re: MyFaces in an OSGi environment
Hello, well, you can't simply attach OSGi support to an existing MyFaces release. There are dozens of core classes that have to be changed. As I've already mentioned, currently MyFaces assumes that it's sufficient to save the class names (e.g. managed bean classes) as every class will be loaded using the context class loader, but the OSGi-fied version of MyFaces would also have to save the bundle to use for loading that class, etc.. Hence I don't think that it's possible to create a new MyFaces commons module for OSGi support. regards, Bernhard Leonardo Uribe wrote: Hi Maybe a new module in myfaces commons is the right place to put this efforts. regards Leonardo Uribe 2009/5/29 Bernhard Huemer bernhard.hue...@gmail.com mailto:bernhard.hue...@gmail.com Hello, recently I've thought of using JSF in an OSGi environment because of the greater modularity it would provide for developers. JSF already provides reusability regarding the user interface, i.e. JSF provides the possibility to create user interface components, but what do you do if you want to reuse more aspects of previous applications than just user interface fragements? How to reuse dialogs, i.e. certain workflows, etc..? OSGi already does provide these reusability features and hence I've adapted MyFaces in a way so that it's runnable in an OSGi container. Basically you just have to deploy an implementation of the OSGi HTTP Service (e.g. Pax Web [1]), the two MyFaces bundles (myfaces-api and myfaces-impl) and your web application bundles. Basically a BundleListener keeps track of all bundles being deployed to the OSGi container, so if the user installs a JSF bundle MyFaces gets notified and merges the current configuration with the configuration of the new bundle. However, even though I've been able to implement a running version, I had to change major parts of MyFaces. For example, using OSGi you can't use the context class loader if you want to create a new instance for a class that resides in a different bundle (think of managed beans, MyFaces is responsible for creating the instance, but the class file is located in a different bundle) and hence I had to rewrite the configuration module (e.g. a LifecycleProvider implementation receives just a class name of the managed bean to instantiate assuming that it can load the class using the context class loader, but that won't work in the case of an OSGi environment). Therefore I'd like to know if I should start contributing these changes? (and if so, should I create a different branch at first, etc.?) regards, Bernhard [1]: http://wiki.ops4j.org/display/paxweb/Pax+Web
Re: MyFaces in an OSGi environment
I think I'll have to explain that a little more:
The current OSGi-fied version of MyFaces that I've implemented doesn't
save class names in the runtime configuration but rather a combination
of a class name and a class loader.
///
public interface ClassLoader {
public Class loadClass(String className)
throws ClassNotFoundException;
}
/**
* ClassLoader implementation that uses the context class loader
* in order to load Java classes.
*/
public class JavaVmClassLoader implements ClassLoader {
private java.lang.ClassLoader classLoader;
public JavaVmClassLoader(java.lang.ClassLoader classLoader) {
this.classLoader = classLoader;
}
public Class loadClass(String className)
throws ClassNotFoundException {
return Class.forName(className, false, classLoader);
}
}
/**
* ClassLoader implementation that uses an OSGi bundle in order to
* load Java classes.
*/
public class OsgiClassLoader implements ClassLoader {
private Bundle bundle;
public OsgiClassLoader(Bundle bundle) {
this.bundle = bundle;
}
public Class loadClass(String className)
throws ClassNotFoundException {
return bundle.loadClass(className);
}
}
\\\
However, there are other issue as well besides this one (no JSP
available, different approach to resource loading, some dependencies of
MyFaces aren't OSGi-friendly, ...).
regards,
Bernhard
Bernhard Huemer wrote:
Hello,
well, you can't simply attach OSGi support to an existing MyFaces
release. There are dozens of core classes that have to be changed. As
I've already mentioned, currently MyFaces assumes that it's sufficient
to save the class names (e.g. managed bean classes) as every class will
be loaded using the context class loader, but the OSGi-fied version of
MyFaces would also have to save the bundle to use for loading that
class, etc..
Hence I don't think that it's possible to create a new MyFaces commons
module for OSGi support.
regards,
Bernhard
Leonardo Uribe wrote:
Hi
Maybe a new module in myfaces commons is the right place to put this
efforts.
regards
Leonardo Uribe
2009/5/29 Bernhard Huemer bernhard.hue...@gmail.com
mailto:bernhard.hue...@gmail.com
Hello,
recently I've thought of using JSF in an OSGi environment because of
the greater modularity it would provide for developers. JSF already
provides reusability regarding the user interface, i.e. JSF provides
the possibility to create user interface components, but what do you
do if you want to reuse more aspects of previous applications than
just user interface fragements? How to reuse dialogs, i.e. certain
workflows, etc..?
OSGi already does provide these reusability features and hence I've
adapted MyFaces in a way so that it's runnable in an OSGi container.
Basically you just have to deploy an implementation of the OSGi HTTP
Service (e.g. Pax Web [1]), the two MyFaces bundles (myfaces-api and
myfaces-impl) and your web application bundles. Basically a
BundleListener keeps track of all bundles being deployed to the OSGi
container, so if the user installs a JSF bundle MyFaces gets
notified and merges the current configuration with the configuration
of the new bundle.
However, even though I've been able to implement a running version,
I had to change major parts of MyFaces. For example, using OSGi you
can't use the context class loader if you want to create a new
instance for a class that resides in a different bundle (think of
managed beans, MyFaces is responsible for creating the instance, but
the class file is located in a different bundle) and hence I had to
rewrite the configuration module (e.g. a LifecycleProvider
implementation receives just a class name of the managed bean to
instantiate assuming that it can load the class using the context
class loader, but that won't work in the case of an OSGi
environment).
Therefore I'd like to know if I should start contributing these
changes? (and if so, should I create a different branch at first,
etc.?)
regards,
Bernhard
[1]: http://wiki.ops4j.org/display/paxweb/Pax+Web
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hello again, However due to the map based approach, the impact of not having a converation closed is much less, and if the user navigates back it can resume the work automagically. Of course that's a nice feature of Orchestra by now, but that's what I'd call an implementation detail, because you can provide this behaviour with a single conversation model too. Manual conversations also have a timeout; when not used for a while they are garbage-collected. Will this work as well in your approach? The not used thing won't work so well, yes? Why shouldn't it work too? I meen, what's the matter with saving the last-access-time? Of course this will work too. Reloading the page, however, doesn't matter. Well, of course, it creates another conversation but sooner a later a timeout will invalidate the one that has been created first. But then you can not talk about nested conversations, then you too have the same flat structure as Orchestra has by today. When you talk about nested conversation you normally also mean to invalidate all child conversations once the parent timeout. This clearly can not work for your scenario. Well, I think that a parent conversation can't time out if there are any child conversations. Actually I really ment to invalidate only the child conversation that has been created first. However, I don't see why this should require a flat structure. If I refresh a page, the action method will be executed again, of course. However, it doesn't know anything about the conversation that has already been created before, because there's no indication for it (the URL has changed as we're just refreshing, the state remains the same, ..). The NavigationHandler was just supposed to be an example. However, somewhere, of course, you have to implement that logic, i.e. some callback method is needed in order to handle the conversation selection, for example, you could use a ViewController for GET Requests. But then again you do not know if you'd like to start or end a conversation without specific external configuration. You can not state this as implementation detail. Starting and ending a conversation in a reasonable and controlled way is what it is all about. Orchestra just allowes to handle it in a less hot way. Again, Orchestra wouldn't provide such a NavigationHandler or ViewController implementation, because as you've already said, specific external configuration would be needed in that case. The developer who is using Orchestra would have to provide such a NavigationHandler or ViewController by himself, which is no problem as it's a rather easy task. How many levels do you want the developer to keep in mind? If you separate the conversation from the persistence scope you also have to be aware that, once the persistence context dies all the conversation cached in a conversation bean is detached. Creating a new persistence scope and pulling in conversation beans with entites loaded using another persistence scope will not work. The only workaround is to NOT cache any entity in the conversation bean and look it up from the persistence context each and every time. Which is doable, for clustering probably needed, but hard to code. That might be true for a flat conversation structure, but it isn't for a nested conversation structure. I'll give you an exemplary structure: Start Conversation #1: (+ Persistence Context) Start Conversation #2 Start Conversation #3 Stop Conversation #3 Stop Conversation #2 Stop Conversation #1 (close Entity Manager) It's perfectly fine to cache entities in a nested conversation. However, if you pass entities to a totally different conversation, then of course, you've got a problem. However, using nested conversations I'm able to use the same persistence context within conversations that I'd like to invalidate earlier. However, I think I'll just have to convince you by implementing my idea, but I'm going to use a seperate branch just as Simon suggested it. ;-) regards, Bernhard Huemer On 10/28/2008 +0100, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! The problem is, that it is hard to ensure having a stopConversation for each startConversation, and what about reloading the page where possibly the startConversation gets called twice. Well, if I'm not completely mistaken, you also have to invalidate all Orchestra conversations manually by now. Well, for conversation.access this is no problem, they die with any request not accessing any bean in the conversation. For manual-scoped conversations, this is true. However due to the map based approach, the impact of not having a converation closed is much less, and if the user navigates back it can resume the work automagically. Manual conversations also have a timeout; when not used for a while they are garbage-collected. Will this work as well in your approach? The not used thing won't work so well, yes? I don't see the point, why forcing
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hello,
Any new ideas that could improve Orchestra would be great.
I'm not sure at the moment exactly what this rewrite
would do; what exactly are you proposing?
Well, basically I'd refactor the ConversationContext so that it's
actually the main conversation of Orchestra. The conversation itself is
almost independent of Spring (of course, there's still an according
implementation of the Scope interface, but it will be implemented way
easier). It's possible to nest conversations, i.e. a there's a certain
hierarchy of conversations.
Each conversation has got it's own lifecycle and therefore it's possible
to register so-called conversation listeners in order to hook logic
into such lifecycle phases.
- listener.conversationStarted(ConversationEvent event);
This method will be called once a conversation starts as the name
implies. The default implementation requires the user to start
conversations explicitly, for example by calling
manager.startConversation() where manager is a ConversationManager
that you can inject into your beans (or lookup via an EL-expression).
- listener.conversationResumed(ConversationEvent event);
This method will be called once the user accesses a URL with the
according request parameter of the conversation, i.e. if the user
accesses the URL http://localhost:8080/something.jsf?conversationId=1;.
- listener.conversationSuspended(ConversationEvent event);
This method will be called once such a request as above has been processed.
- listener.conversationEnded(ConversationEvent event);
This method will be called once the user invalidates a conversation.
The following example describes the most obvious usecase:
JpaPersistenceListener
- listener.conversationStarted():
Create the persistence context and put it into the conversation.
- listener.conversationResumed():
Bind the persistence context of the conversation
- listener.conversationSuspended():
Unbind the persistence context of the conversation
- listener.conversationEnded():
Close the persistence context
No additional proxy class is needed in that case and a persistence
context is available to the whole application (you don't have to call
DAO methods through conversation-scoped beans). If you don't persistence
context support, then just don't configure the JpaPersistenceListener.
Those who know Spring Web Flow will think that I'm just proposing to do
it like Spring Web Flow does - and yeah, they're right as I think that's
the way to go. However, there's still the need for a persistence
interceptor as you're still able to use the current conversation model
of Orchestra. The difference is that such conversations will be nested
within the main conversation of Orchestra and not within a
ConversationContext.
In doing so, it's not required to specify the conversation you'd like to
use on your bean definitions, as there's just one conversation: the
current one and Orchestra is responsible for determining that one. Of
course, this approach doesn't allow you to use two different
conversations on the same view, but then you can still use the previous
conversation model of Orchestra.
The SpringSingleConversationScope (or whatever it was called like) was a
start in the right direction, but I think it's wrong to implement a
single conversation-model on a named conversation-model. I'd propose to
do it the other way around.
regards,
Bernhard Huemer
On 10/27/2008 +0100,
Simon Kitching [EMAIL PROTECTED] wrote:
Hi Bernhard,
It's great to see some design discussion about Orchestra!
Bernhard Huemer schrieb:
Hi folks,
I've been using Orchestra for a few months now and in doing so I've
been questioning some major implementation decisions, to be more
specific I really want to discuss if it's really necessary to bind
beans to a certain conversation (and therefore also a certein
persistence context!). Let me give you some examples:
Example 1)
I've developed some views for a search dialog that I wanted to use in
at least two different conversations. Everything worked fine for the
first conversation. The following code listing should give you an idea
of the problem.
///
view.xhtml
h:inputText value=#{conversationBean.value} /
spring-bean-config.xml
bean id=conversationBean class=... scope=conversation.manual
orchestra:conversationName=conversationA /
\\\
Maybe some of you have realized my problem by now: The bean somehow
depends on the conversation and as the view depends on the bean I
can't use it with a different conversation (or at least I'm missing a
major feature of Orchestra). :-f
The approach we (Mario I) use in these kind of situations is to
deliberately *not* share a conversation between the calling and called
pages. We pass input parameters to the called page (your search
dialog) and it returns some values. But it doesn't use the conversation
of the caller. Of course this means that it cannot access the
persistence context of the caller; in particular it cannot perform
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hello, The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. Well, no, you don't have to use a flow definition. Managing the conversation from a user's perspective is clearly defined as an according API will be provided. If the user doesn't call a method like conversation.invalidate() the conversation won't end. For example, I'm thinking of creating a configurable artifact that manages the lifecycle of a conversation - a so-called ConversationManager. The basic implementation would require the user to call the method manager.startConversation(), i.e. the user would have to configure the beans so that a ConversationManager will be injected. However, another ConversationManager could possibly know how to deal with annotations like @Create or @End. It would be even possible to configure a special ConversationManager that automatically creates a new conversation if you try to access it (i.e. just as it is now) and of course there's the possibility of using a flow definition for that purpose. In a web-application, where you have global menues where the user is able to suspend the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this free-floating-named-conversations in our application. Well, I'm not particularly against named conversations. I'm just saying that neither the view nor a Spring bean is responsible for determining the name of this conversation, but a special flow logic is (and I'm still not talking about flow definitions). For example, in this case I'd prefer to write a NavigationHandler for my application that knows how to deal with this usecase. Basically it uses the according API to suspend the current conversation and resume the according one. Of course, Orchestra could only do that automatically if there was something like a flow definition, but I'd prefer to expose an API so that the user is able to write such a NavigationHandler on his own. However, this approach enables you to control conversations in a more fine-grained way. For example, if you've got a master-/detail-view being surrounded by global navigation menus, you could use the exposed API so that you'll resume the conversation for the detail you've choosen previously if you select it again (of course, assuming that you only have suspended the conversation, i.e. you've clicked on a global menu entry before). Also no user-interaction is required (pause, restart, etc) and no other sort of convention. Well, of course you could say that this is a burden for the user, but it comes with great flexibility too (see my master-/detail-view example). Convenient default implementations could then reduce the complexity without limitating the user's flexibility. For me the single-conversation approach looks like a limitation, which to break out requires a flow-description. Simply said, yes that's true, but the flow description doesn't have to be an XML flow definition. What I'd like to see, is an Orchestra API that allows me to describe my flows programmatically at runtime as this is a much more powerful approach for managing conversations. regards, Bernhard On 10/27/2008 +0100, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Well, basically I'd refactor the ConversationContext so that it's actually the main conversation of Orchestra. The conversation itself is almost independent of Spring (of course, there's still an according implementation of the Scope interface, but it will be implemented way easier). It's possible to nest conversations, i.e. a there's a certain hierarchy of conversations. The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. In a web-application, where you have global menues where the user is able to suspend the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this free-floating-named-conversations in our application. As far as I know Spring WebFlow is such a system and is able to deal with persistence contexts already. Each conversation has got it's own lifecycle and therefore it's possible to register so-called conversation listeners in order to hook logic into such lifecycle phases. Some of the events you outlined are already there in Orchestra. Also using Orchestra without persistence at all works great, on a
[Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi folks,
I've been using Orchestra for a few months now and in doing so I've been
questioning some major implementation decisions, to be more specific I
really want to discuss if it's really necessary to bind beans to a
certain conversation (and therefore also a certein persistence
context!). Let me give you some examples:
Example 1)
I've developed some views for a search dialog that I wanted to use in at
least two different conversations. Everything worked fine for the first
conversation. The following code listing should give you an idea of the
problem.
///
view.xhtml
h:inputText value=#{conversationBean.value} /
spring-bean-config.xml
bean id=conversationBean class=... scope=conversation.manual
orchestra:conversationName=conversationA /
\\\
Maybe some of you have realized my problem by now: The bean somehow
depends on the conversation and as the view depends on the bean I can't
use it with a different conversation (or at least I'm missing a major
feature of Orchestra). :-f
I've solved this issue by creating some Facelets components so that I'm
able to pass the conversation bean as parameter. However, I had to
duplicate navigation rules, etc, i.e. now I've got the following structure:
///
viewA.xhtml
my:view bean=#{conversationABean} /
viewB.xhtml
my:view bean=#{conversationBBean} /
view.xhtml
h:inputText value=#{bean.value} /
spring-bean-config.xml
bean id=conversationABean class=... scope=conversation.manual
orchestra:conversationName=conversationA /
bean id=conversationBBean class=... scope=conversation.manual
orchestra:conversationName=conversationB /
\\\
Example 2)
In a different part of the same application I've created a view that
should serve for three different usecases. Basically the view doesn't
change for these usecases at all, but the logic of the backing bean
does. My first approach was to determine the specific page bean at
runtime in the action method that navigates to this view. This action
method was supposed to register the specific page bean under a common
name. So somehow it can be said that I wanted to use polymorphic beans.
///
public String action() {
Conversation conversation = getCurrentConversation();
switch (criterium) {
case CASE_A:
conversation.setAttribute(commonBean, specificBeanA);
break;
case CASE_B:
conversation.setAttribute(commonBean, specificBeanB);
break;
case CASE_C:
conversation.setAttribute(commonBean, specificBeanC);
break;
default:
throw new IllegalStateException(); // shouldn't occur anway
}
return outcome;
}
view.xhtml
h:commandButton action=#{commonBean.save} /
\\\
However, that wouldn't work for two reasons:
- Orchestra only knows how to resolve Spring beans as the bean
definition determines the conversation being used (well, Orchestra
doesn't know how to resolve anything, actually it's the
EL-/VariableResolver of Spring that does this job in this case). It's
only possible to resolve such variables if the view knows which
conversation it should access (i.e. if one would develop a custom
ELResolver that knows how to resolve expressions like
#{conversation.conversationA.commonBean} - *cough* problem of the first
example *cough*).
- Orchestra wouldn't create a persistence context for that bean as the
persistence interceptor only gets attached to Spring beans. (No, I'm not
telling you to modify the setAttribute method so that advices will be
attached. I'm rather telling you to use conversation listeners instead
for persistence support, just like Web Flow does).
I was able to work around this issue by introducing an additional
indirection, i.e. I'm resolving that bean with the expression
#{pageAccessor['commonBean']}, but that's just not intuitional.
However, please don't get me wrong. I don't want to hear anything about
certain workarounds that I could have used in these cases as I think
that these usecases aren't exceptional enough to justify workarounds. Of
course, the current approach has got its advantages too (e.g. switching
arbitrarily between different conversations as there is no hierarchical
structure), but at least I haven't needed this feature yet.
Summarizing it can be stated that I'd propose you to rewrite
conversation handling for the next major release and I'd be willing to
contribute. Note that I don't want to drop support for these named
conversations, but I think that this usecase is not the default one for
conversations.
regards,
Bernhard Huemer
[jira] Updated: (ORCHESTRA-17) RequestParameterFacesContextFactory only works with HttpServletResponse
[
https://issues.apache.org/jira/browse/ORCHESTRA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated ORCHESTRA-17:
-
Status: Patch Available (was: Reopened)
RequestParameterFacesContextFactory only works with HttpServletResponse
---
Key: ORCHESTRA-17
URL: https://issues.apache.org/jira/browse/ORCHESTRA-17
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0, 1.1
Environment: Liferay Portlet Container
Reporter: Martin Marinschek
The following snippet wrongly casts to HttpServletResponse, therefore
portlet-environments will not work:
if (response instanceof HttpServletResponse)
{
HttpServletRequest httpServletRequest = (HttpServletRequest)
request;
// Wrap this request only if something else (eg a
RequestParameterServletFilter) has not already wrapped it.
if
(!Boolean.TRUE.equals(httpServletRequest.getAttribute(RequestParameterServletFilter.REQUEST_PARAM_FILTER_CALLED)))
{
I will commit a solution very soon.
regards,
Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-17) RequestParameterFacesContextFactory only works with HttpServletResponse
[
https://issues.apache.org/jira/browse/ORCHESTRA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607762#action_12607762
]
Bernhard Huemer commented on ORCHESTRA-17:
--
I've created a patch that is similiar to the one Martin has provided a while
ago but I've extended it a little bit as it is unlike the previous version now
compatible with both JSF 1.1 and JSF 1.2 (thanks to a small hack). Even
though I could commit it myself I'd like someone else to review it (Simon or
Mario?). I've already tested it with Apache Pluto and the JSR-301 Portlet
Bridge.
RequestParameterFacesContextFactory only works with HttpServletResponse
---
Key: ORCHESTRA-17
URL: https://issues.apache.org/jira/browse/ORCHESTRA-17
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0, 1.1
Environment: Liferay Portlet Container
Reporter: Martin Marinschek
Attachments: ORCHESTRA-17.patch
The following snippet wrongly casts to HttpServletResponse, therefore
portlet-environments will not work:
if (response instanceof HttpServletResponse)
{
HttpServletRequest httpServletRequest = (HttpServletRequest)
request;
// Wrap this request only if something else (eg a
RequestParameterServletFilter) has not already wrapped it.
if
(!Boolean.TRUE.equals(httpServletRequest.getAttribute(RequestParameterServletFilter.REQUEST_PARAM_FILTER_CALLED)))
{
I will commit a solution very soon.
regards,
Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1693) Make JSP 2.1 optional
[ https://issues.apache.org/jira/browse/MYFACES-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585411#action_12585411 ] Bernhard Huemer commented on MYFACES-1693: -- Note that you can't use JSP 2.0 (or lower), you have to use Facelets if you're running MyFaces 1.2.x in a J2EE 1.4 environment. Make JSP 2.1 optional -- Key: MYFACES-1693 URL: https://issues.apache.org/jira/browse/MYFACES-1693 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Affects Versions: 1.2.0 Reporter: Achim Hügen Fix For: 1.2.2 Attachments: facelets-jsf12-debug.zip, MYFACES-1693.patch Myfaces 1.2.0 requires JSP 2.1 to be present. Otherwise the StartupServletContextListener fails with this error: Exception sending context initialized event to listener instance of class org.apache.myfaces.webapp.StartupServletContextListener java.lang.NoSuchMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; at org.apache.myfaces.webapp.DefaultFacesInitializer.initFaces(DefaultFacesInitializer.java:102) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:57) JSP version 2.1 or better JSP in general should be an optional dependency, like discussed here and implemented in Sun RI too: http://www.nabble.com/Does-MyFaces-1.2-require-JSP-2.1--tf4112432.html#a11693501 Use cases: - Run Myfaces 1.2.0 in JEE 1.4 environment (Tomcat 5.x). - Easier setup and smaller distributions when running Myfaces in an embedded servlet container (jetty) with facelets. For example I'm using jetty for junit tests. I haven't found a working setup which solves the jsp problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Orchestra with Request Scope
Hello, I think that providing integration with the OpenEntityManagerInViewFilter is much more preferable to adding another managed scope. For example, think of a master-detail view at which the user starts a new conversation by selecting one of the entries being loaded via a PersistenceContext. Supposing Orchestra reuses the PersistenceContext provided by the Filter? Wouldn't you be able to deal with those request-scoped entities just like as if they had been loaded within a conversation? regards, Bernhard On 03/29/2008 +0100, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! In my app, there is an org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter that binds an entityManager to each request. With Orchestra do I really have to remove this filter? No. Orchestra does not help with request scoped beans. Mixing OEMIVF with Orchestra should work I think. For example I have a backing bean with request scope that lists entities, removing this filter adding orchestra, it starts failing. Another solution might be to put your request scoped bean into a flash scope, though, you have to be aware that then it might be possible to not see fresh data from the database as the ORM PersistenceContext caches the data. If you change data this is something you would like to have to utilize optimistic locking. If it is just to output data you then have to clear() the persistence context before fetching new data. Probably we should add an Orchestra managed request scope too Ciao, Mario
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Hello,
additionally I'm concerned whether this breaks compatibility with
current (non JSR-301) portlet bridges ..
regards,
Bernhard
On 02/20/2008 +0100,
Matthias Wessendorf [EMAIL PROTECTED] wrote:
also...
doesn't this belong to the 12x trunk ?
My understanding is that the JSR 301 is kind of depending on JSF 1.2
-M
On Feb 20, 2008 3:31 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
dependency
+groupIdorg.apache.myfaces.portlet-bridge/groupId
+artifactIdportlet-bridge-api/artifactId
+version1.0.0-alpha/version
+scopeprovided/scope
+ /dependency
I wonder fi is the right scope.
Pretty much all containers don't really ship that JAR.
-M
+
+ dependency
groupIdorg.apache.myfaces.core/groupId
artifactIdmyfaces-api/artifactId
version${myfaces.version}/version
Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242r1=629241r2=629242view=diff
==
--- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
+++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
@@ -206,6 +206,11 @@
/dependency
dependency
+ groupIdorg.apache.myfaces.portlet-bridge/groupId
+ artifactIdportlet-bridge-api/artifactId
+/dependency
+
+dependency
groupIdorg.apache.myfaces.trinidad/groupId
artifactIdtrinidad-build/artifactId
/dependency
Modified:
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242r1=629241r2=629242view=diff
==
---
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
(original)
+++
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Tue Feb 19 13:35:43 2008
@@ -51,6 +51,11 @@
import java.io.IOException;
+import javax.portlet.faces.annotation.PortletNamingContainer;
+import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
+
+import org.apache.myfaces.trinidad.util.ExternalContextUtils;
+
/**
* StateManager that handles a hybrid client/server strategy: a
* SerializedView is stored on the server, and only a small token
@@ -966,6 +971,17 @@
UIViewRoot newRoot = (UIViewRoot)
fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
+//This code handles automatic namespacing in a JSR-301 environment
+if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
+{
+ //To avoid introducing a runtime dependency on the bridge,
+ //this method should only be executed when we have a portlet
+ //request. If we do have a portlet request then the bridge
+ //should be available anyway.
+ newRoot = _getPortletRoot(newRoot);
+}
+
+
// must call restoreState so that we setup attributes, listeners,
// uniqueIds, etc ...
newRoot.restoreState(fc, viewRootState);
@@ -984,6 +1000,37 @@
return null;
}
+
+/**
+ * This should only be executed if we are currently in a Portlet Request.
+ * If executed, this method introduces a dependency on the JSR-301 bridge
+ * which is required for Trinidad to run in a portal environment. If this
+ * method is not run, then the bridge api's remain optional at runtime.
+ *
+ * This method checks the current UIViewRoot to see if it is a
+ * PortletNamingContainer. If it is, then this class simply returns the
+ * UIViewRoot. If it does not then the current UIViewRoot is used to
create
+ * a new PortletNamingContainerUIViewRoot.
+ */
+private UIViewRoot _getPortletRoot(UIViewRoot root)
+{
+ Class? extends UIViewRoot rootClass = root.getClass();
+ //If the current root is not the real UIViewRoot object in faces then
+ //is no need to escape it. It is assumed it handles namespacing on its
+ //own. This is the same as the logic in the JSR-301 Bridge spec.
+ if(rootClass == UIViewRoot.class)
+ {
+_LOG.fine(Creating PortletUIViewRoot for use with the portal.);
+root = new PortletNamingContainerUIViewRoot(root);
+ }
+
+ //TODO: Do we need a warning here if the view root is not annotated
+ //properly? This could happen if another renderkit is involved and does
+ //not correctly implement JSR-301. This will NOT be an issue in Trin
only
+ //environments.
+ return root;
+}
+
}
--
Matthias Wessendorf
further stuff:
blog:
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Hello,
actually, I'm using Trinidad with a non JSR-301 bridge (even though it
requires some workarounds ..). Isn't it possible to make this bugfix
optional, for example by introducing a Jsr301StateManagerImpl?
regards,
Bernhard
On 02/20/2008 +0100,
Scott O'Bryan [EMAIL PROTECTED] wrote:
There is no compatibility for Trinidad with non JSR-301 bridges.
Scott
Bernhard Huemer wrote:
Hello,
additionally I'm concerned whether this breaks compatibility with
current (non JSR-301) portlet bridges ..
regards,
Bernhard
On 02/20/2008 +0100,
Matthias Wessendorf [EMAIL PROTECTED] wrote:
also...
doesn't this belong to the 12x trunk ?
My understanding is that the JSR 301 is kind of depending on JSF 1.2
-M
On Feb 20, 2008 3:31 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
dependency
+groupIdorg.apache.myfaces.portlet-bridge/groupId
+artifactIdportlet-bridge-api/artifactId
+version1.0.0-alpha/version
+scopeprovided/scope
+ /dependency
I wonder fi is the right scope.
Pretty much all containers don't really ship that JAR.
-M
+
+ dependency
groupIdorg.apache.myfaces.core/groupId
artifactIdmyfaces-api/artifactId
version${myfaces.version}/version
Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242r1=629241r2=629242view=diff
==
--- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
+++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
13:35:43 2008
@@ -206,6 +206,11 @@
/dependency
dependency
+ groupIdorg.apache.myfaces.portlet-bridge/groupId
+ artifactIdportlet-bridge-api/artifactId
+/dependency
+
+dependency
groupIdorg.apache.myfaces.trinidad/groupId
artifactIdtrinidad-build/artifactId
/dependency
Modified:
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242r1=629241r2=629242view=diff
==
---
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
(original)
+++
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Tue Feb 19 13:35:43 2008
@@ -51,6 +51,11 @@
import java.io.IOException;
+import javax.portlet.faces.annotation.PortletNamingContainer;
+import
javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
+
+import org.apache.myfaces.trinidad.util.ExternalContextUtils;
+
/**
* StateManager that handles a hybrid client/server strategy: a
* SerializedView is stored on the server, and only a small token
@@ -966,6 +971,17 @@
UIViewRoot newRoot = (UIViewRoot)
fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
+//This code handles automatic namespacing in a JSR-301
environment
+if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
+{
+ //To avoid introducing a runtime dependency on the bridge,
+ //this method should only be executed when we have a
portlet
+ //request. If we do have a portlet request then the bridge
+ //should be available anyway.
+ newRoot = _getPortletRoot(newRoot);
+}
+
+
// must call restoreState so that we setup attributes,
listeners,
// uniqueIds, etc ...
newRoot.restoreState(fc, viewRootState);
@@ -984,6 +1000,37 @@
return null;
}
+
+/**
+ * This should only be executed if we are currently in a
Portlet Request.
+ * If executed, this method introduces a dependency on the
JSR-301 bridge
+ * which is required for Trinidad to run in a portal
environment. If this
+ * method is not run, then the bridge api's remain optional at
runtime.
+ *
+ * This method checks the current UIViewRoot to see if it is a
+ * PortletNamingContainer. If it is, then this class simply
returns the
+ * UIViewRoot. If it does not then the current UIViewRoot is
used to create
+ * a new PortletNamingContainerUIViewRoot.
+ */
+private UIViewRoot _getPortletRoot(UIViewRoot root)
+{
+ Class? extends UIViewRoot rootClass = root.getClass();
+ //If the current root is not the real UIViewRoot object in
faces then
+ //is no need to escape it. It is assumed it handles
namespacing on its
+ //own. This is the same as the logic in the JSR-301 Bridge
spec.
+ if(rootClass == UIViewRoot.class)
+ {
+_LOG.fine(Creating PortletUIViewRoot for use with the
portal.);
+root
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Hello,
that's because there's a dependency to PortletNamingContainerUIViewRoot
even if you're using this StateManager in a Servlet environment (due to
the import). In order to overcome this issue Scott could introduce an
additional indirection so that the class Portlet..UIViewRoot will only
be loaded if Trinidad is running in the appropriate environment (for
example by introducing a Jsr301StateManagerImpl ;-)).
regards,
Bernhard
On 02/20/2008 +0100,
Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi Scott,
On Feb 20, 2008 5:26 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
The Apache MVN website says this about providing a compile only library:
The scope you should use for this is |provided|. This indicates to
Maven that the dependency will be provided at run time by its
container or the JDK, for example.
Dependencies with this scope will not be passed on transitively,
nor will they be bundled in an package such as a WAR, or included in
the runtime classpath.
This library is a runtime only library and is only needed when running
in the portlet environment. Currently Trinidad's demo's aren't portlet
compatible. Until I'm able to do some of this work, I would much rather
this API (and the subsequent impl) not be added to the demo.
I get a java.lang.NoClassDefFoundError:
javax/portlet/faces/component/PortletNamingContainerUIViewRoot when
running the demos...
(on 1.2.6.1 branch)
(trinidad-demos in jetty = mvn clean jetty:run -PjettyConfig)
when I change the dependency (as suggested) to compile, after building
Trinidad again, all works fine.
Also, the 301-fix is now here:
-1.0.x trunk
-1.2.6.1 branch
not in 1.2_x trunk
-Matthias
-Matthias
Scott
Matthias Wessendorf wrote:
also...
doesn't this belong to the 12x trunk ?
My understanding is that the JSR 301 is kind of depending on JSF 1.2
-M
On Feb 20, 2008 3:31 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
dependency
+groupIdorg.apache.myfaces.portlet-bridge/groupId
+artifactIdportlet-bridge-api/artifactId
+version1.0.0-alpha/version
+scopeprovided/scope
+ /dependency
I wonder fi is the right scope.
Pretty much all containers don't really ship that JAR.
-M
+
+ dependency
groupIdorg.apache.myfaces.core/groupId
artifactIdmyfaces-api/artifactId
version${myfaces.version}/version
Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242r1=629241r2=629242view=diff
==
--- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
+++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
@@ -206,6 +206,11 @@
/dependency
dependency
+ groupIdorg.apache.myfaces.portlet-bridge/groupId
+ artifactIdportlet-bridge-api/artifactId
+/dependency
+
+dependency
groupIdorg.apache.myfaces.trinidad/groupId
artifactIdtrinidad-build/artifactId
/dependency
Modified:
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242r1=629241r2=629242view=diff
==
---
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
(original)
+++
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Tue Feb 19 13:35:43 2008
@@ -51,6 +51,11 @@
import java.io.IOException;
+import javax.portlet.faces.annotation.PortletNamingContainer;
+import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
+
+import org.apache.myfaces.trinidad.util.ExternalContextUtils;
+
/**
* StateManager that handles a hybrid client/server strategy: a
* SerializedView is stored on the server, and only a small token
@@ -966,6 +971,17 @@
UIViewRoot newRoot = (UIViewRoot)
fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
+//This code handles automatic namespacing in a JSR-301 environment
+if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
+{
+ //To avoid introducing a runtime dependency on the bridge,
+ //this method should only be executed when we have a portlet
+ //request. If we do have a portlet request then the bridge
+ //should be available anyway.
+ newRoot = _getPortletRoot(newRoot);
+}
+
+
// must call restoreState so that we setup attributes, listeners,
// uniqueIds, etc ...
newRoot.restoreState(fc, viewRootState);
@@ -984,6 +1000,37 @@
return null;
}
+
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Hello,
it would be great if you could check whether the class actually exists.
I'm using the Apache Portals JSF Bridge with MyFaces 1.1.x.
regards,
Bernhard
On 02/20/2008 +0100,
Scott O'Bryan [EMAIL PROTECTED] wrote:
We can, but it's a lot of overkill. My concern going forward, however,
is that Trinidad is going to be expected to work with the standard as it
emerges and us trying to pay run with non-standard bridges will limit
our ability to support the standard ones.
That said, I suppose I can put some checking to make sure that this
class actually exists in the classpath before actually using it. The
POM dependency shouldn't make a difference if I did this though.
You mind me asking what Bridge you are using? Also, are you using JSF 1.2?
Scott
Bernhard Huemer wrote:
Hello,
actually, I'm using Trinidad with a non JSR-301 bridge (even though it
requires some workarounds ..). Isn't it possible to make this bugfix
optional, for example by introducing a Jsr301StateManagerImpl?
regards,
Bernhard
On 02/20/2008 +0100,
Scott O'Bryan [EMAIL PROTECTED] wrote:
There is no compatibility for Trinidad with non JSR-301 bridges.
Scott
Bernhard Huemer wrote:
Hello,
additionally I'm concerned whether this breaks compatibility with
current (non JSR-301) portlet bridges ..
regards,
Bernhard
On 02/20/2008 +0100,
Matthias Wessendorf [EMAIL PROTECTED] wrote:
also...
doesn't this belong to the 12x trunk ?
My understanding is that the JSR 301 is kind of depending on JSF 1.2
-M
On Feb 20, 2008 3:31 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
Hi,
dependency
+groupIdorg.apache.myfaces.portlet-bridge/groupId
+artifactIdportlet-bridge-api/artifactId
+version1.0.0-alpha/version
+scopeprovided/scope
+ /dependency
I wonder fi is the right scope.
Pretty much all containers don't really ship that JAR.
-M
+
+ dependency
groupIdorg.apache.myfaces.core/groupId
artifactIdmyfaces-api/artifactId
version${myfaces.version}/version
Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242r1=629241r2=629242view=diff
==
--- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
+++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
13:35:43 2008
@@ -206,6 +206,11 @@
/dependency
dependency
+ groupIdorg.apache.myfaces.portlet-bridge/groupId
+ artifactIdportlet-bridge-api/artifactId
+/dependency
+
+dependency
groupIdorg.apache.myfaces.trinidad/groupId
artifactIdtrinidad-build/artifactId
/dependency
Modified:
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242r1=629241r2=629242view=diff
==
---
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
(original)
+++
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Tue Feb 19 13:35:43 2008
@@ -51,6 +51,11 @@
import java.io.IOException;
+import javax.portlet.faces.annotation.PortletNamingContainer;
+import
javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
+
+import org.apache.myfaces.trinidad.util.ExternalContextUtils;
+
/**
* StateManager that handles a hybrid client/server strategy: a
* SerializedView is stored on the server, and only a small token
@@ -966,6 +971,17 @@
UIViewRoot newRoot = (UIViewRoot)
fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
+//This code handles automatic namespacing in a JSR-301
environment
+if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
+{
+ //To avoid introducing a runtime dependency on the
bridge,
+ //this method should only be executed when we have a
portlet
+ //request. If we do have a portlet request then the
bridge
+ //should be available anyway.
+ newRoot = _getPortletRoot(newRoot);
+}
+
+
// must call restoreState so that we setup attributes,
listeners,
// uniqueIds, etc ...
newRoot.restoreState(fc, viewRootState);
@@ -984,6 +1000,37 @@
return null;
}
+
+/**
+ * This should only be executed if we are currently in a
Portlet Request.
+ * If executed, this method introduces a dependency on the
JSR-301 bridge
+ * which is required for Trinidad to run in a portal
environment. If this
+ * method is not run, then the bridge api's remain optional
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Hello,
LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
99.9% of the code is shared and only a private inner class contains
the change. I'll figure something out.
actually, I was just kidding but nevertheless noone said that the
Jsr301StateManagerImpl isn't allowed to inherit from the plain
StateManagerImpl.
That said, I'm not sure it's the import necessarily. But I'll trace
though it to see what I've got. I know that the ExternalContextUtils
has the imports on the portlet classes and it loads fine in a servlet
only environment. I may have to get at the class using reflection or
something to prevent it from preloading.
Although I'm quite sure that the import statement causes this behaviour,
you're right, that it's not necessarily true. However, the class
definition somehow depends on PortletNamingUIViewRoot _directly_. As
I've already mentioned, you just have to introduce an additional
indirection to prevent preloading (for example by introducing a
Jsr301StateManagerUtils class - just don't use a nested class).
regards,
Bernhard
On 02/20/2008 +0100,
Scott O'Bryan [EMAIL PROTECTED] wrote:
LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
99.9% of the code is shared and only a private inner class contains
the change. I'll figure something out.
That said, I'm not sure it's the import necessarily. But I'll trace
though it to see what I've got. I know that the ExternalContextUtils
has the imports on the portlet classes and it loads fine in a servlet
only environment. I may have to get at the class using reflection or
something to prevent it from preloading.
Scott
Bernhard Huemer wrote:
Hello,
that's because there's a dependency to
PortletNamingContainerUIViewRoot even if you're using this
StateManager in a Servlet environment (due to the import). In order to
overcome this issue Scott could introduce an additional indirection so
that the class Portlet..UIViewRoot will only be loaded if Trinidad is
running in the appropriate environment (for example by introducing a
Jsr301StateManagerImpl ;-)).
regards,
Bernhard
On 02/20/2008 +0100,
Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi Scott,
On Feb 20, 2008 5:26 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
The Apache MVN website says this about providing a compile only
library:
The scope you should use for this is |provided|. This indicates to
Maven that the dependency will be provided at run time by its
container or the JDK, for example.
Dependencies with this scope will not be passed on transitively,
nor will they be bundled in an package such as a WAR, or
included in
the runtime classpath.
This library is a runtime only library and is only needed when running
in the portlet environment. Currently Trinidad's demo's aren't portlet
compatible. Until I'm able to do some of this work, I would much
rather
this API (and the subsequent impl) not be added to the demo.
I get a java.lang.NoClassDefFoundError:
javax/portlet/faces/component/PortletNamingContainerUIViewRoot when
running the demos...
(on 1.2.6.1 branch)
(trinidad-demos in jetty = mvn clean jetty:run -PjettyConfig)
when I change the dependency (as suggested) to compile, after building
Trinidad again, all works fine.
Also, the 301-fix is now here:
-1.0.x trunk
-1.2.6.1 branch
not in 1.2_x trunk
-Matthias
-Matthias
Scott
Matthias Wessendorf wrote:
also...
doesn't this belong to the 12x trunk ?
My understanding is that the JSR 301 is kind of depending on JSF 1.2
-M
On Feb 20, 2008 3:31 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
Hi,
dependency
+groupIdorg.apache.myfaces.portlet-bridge/groupId
+artifactIdportlet-bridge-api/artifactId
+version1.0.0-alpha/version
+scopeprovided/scope
+ /dependency
I wonder fi is the right scope.
Pretty much all containers don't really ship that JAR.
-M
+
+ dependency
groupIdorg.apache.myfaces.core/groupId
artifactIdmyfaces-api/artifactId
version${myfaces.version}/version
Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242r1=629241r2=629242view=diff
==
--- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
+++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19
13:35:43 2008
@@ -206,6 +206,11 @@
/dependency
dependency
+ groupIdorg.apache.myfaces.portlet-bridge/groupId
+ artifactIdportlet-bridge-api/artifactId
+/dependency
+
+dependency
groupIdorg.apache.myfaces.trinidad/groupId
artifactIdtrinidad-build/artifactId
/dependency
Modified:
myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad
Re: svn commit: r629242 - in /myfaces/trinidad/trunk: pom.xml trinidad-impl/pom.xml trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
Hello, I'm fine with this restriction as I'm using the Apache Portal JSF Bridge only in cases where I can't use the JSR 301 Bridge (due to the JSF 1.2 dependency). regards, Bernhard On 02/21/2008 +0100, Scott O'Bryan [EMAIL PROTECTED] wrote: Ok, I think I fixed it. Bernhard, you were right, it needed to be moved. ExternalContextUtils works because I use reflection to get the classes.. duh! Anyway I removed the checkin from trunk. Added the checking to trunk_1.2.x And modified the previous checkin to 1.2.6.1-branch I tested it with Jetty and everything works right. Insidently I had previously tested this in JDEV and it worked, Jetty failed. I can only assume it's because of differences with the class loader, so I'll make sure to add Jetty tests in the future. Bernhard, I'm assuming that this modification NOT being in trunk solves your needs as well, correct? Trinidad 1.1 portlets are not officially supported even though they should work with some hacks and workarounds. I'm thinking for 1.2, though, we really should enforce the standard bridge. Do you agree? Scott Bernhard Huemer wrote: Hello, LOL. Seriously the Jsr301StateManagerImpl is the wrong answer. 99.9% of the code is shared and only a private inner class contains the change. I'll figure something out. actually, I was just kidding but nevertheless noone said that the Jsr301StateManagerImpl isn't allowed to inherit from the plain StateManagerImpl. That said, I'm not sure it's the import necessarily. But I'll trace though it to see what I've got. I know that the ExternalContextUtils has the imports on the portlet classes and it loads fine in a servlet only environment. I may have to get at the class using reflection or something to prevent it from preloading. Although I'm quite sure that the import statement causes this behaviour, you're right, that it's not necessarily true. However, the class definition somehow depends on PortletNamingUIViewRoot _directly_. As I've already mentioned, you just have to introduce an additional indirection to prevent preloading (for example by introducing a Jsr301StateManagerUtils class - just don't use a nested class). regards, Bernhard On 02/20/2008 +0100, Scott O'Bryan [EMAIL PROTECTED] wrote: LOL. Seriously the Jsr301StateManagerImpl is the wrong answer. 99.9% of the code is shared and only a private inner class contains the change. I'll figure something out. That said, I'm not sure it's the import necessarily. But I'll trace though it to see what I've got. I know that the ExternalContextUtils has the imports on the portlet classes and it loads fine in a servlet only environment. I may have to get at the class using reflection or something to prevent it from preloading. Scott Bernhard Huemer wrote: Hello, that's because there's a dependency to PortletNamingContainerUIViewRoot even if you're using this StateManager in a Servlet environment (due to the import). In order to overcome this issue Scott could introduce an additional indirection so that the class Portlet..UIViewRoot will only be loaded if Trinidad is running in the appropriate environment (for example by introducing a Jsr301StateManagerImpl ;-)). regards, Bernhard On 02/20/2008 +0100, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Scott, On Feb 20, 2008 5:26 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: The Apache MVN website says this about providing a compile only library: The scope you should use for this is |provided|. This indicates to Maven that the dependency will be provided at run time by its container or the JDK, for example. Dependencies with this scope will not be passed on transitively, nor will they be bundled in an package such as a WAR, or included in the runtime classpath. This library is a runtime only library and is only needed when running in the portlet environment. Currently Trinidad's demo's aren't portlet compatible. Until I'm able to do some of this work, I would much rather this API (and the subsequent impl) not be added to the demo. I get a java.lang.NoClassDefFoundError: javax/portlet/faces/component/PortletNamingContainerUIViewRoot when running the demos... (on 1.2.6.1 branch) (trinidad-demos in jetty = mvn clean jetty:run -PjettyConfig) when I change the dependency (as suggested) to compile, after building Trinidad again, all works fine. Also, the 301-fix is now here: -1.0.x trunk -1.2.6.1 branch not in 1.2_x trunk -Matthias -Matthias Scott Matthias Wessendorf wrote: also... doesn't this belong to the 12x trunk ? My understanding is that the JSR 301 is kind of depending on JSF 1.2 -M On Feb 20, 2008 3:31 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, dependency +groupIdorg.apache.myfaces.portlet-bridge/groupId +artifactIdportlet-bridge-api/artifactId +version1.0.0-alpha/version +scopeprovided/scope + /dependency I wonder
Re: myfaces-faces-plugin - architecture
Hello, I'm just wondering what version of the maven-eclipse- or the maven-idea-plugin you're using because I've never had problems with the maven-faces-plugin generating source in the target tree. mvn eclipse:eclipse or mvn idea:idea configures the project properly at least for me as I don't have to add additional source folders. For example, I've attached the accoring part of the project configuration being generated by the maven-idea-plugin: /// content url=file://$MODULE_DIR$ sourceFolder url=file://$MODULE_DIR$/src/main/java isTestSource=false/ sourceFolder url=file://$MODULE_DIR$/target/ maven-faces-plugin/main/java isTestSource=false/ sourceFolder url=file://$MODULE_DIR$/src/test/java isTestSource=true/ sourceFolder url=file://$MODULE_DIR$/src/main/resources isTestSource=false/ sourceFolder url=file://$MODULE_DIR$/src/test/resources isTestSource=true/ excludeFolder url=file://$MODULE_DIR$/target/classes/ excludeFolder url=file://$MODULE_DIR$/target/test-classes/ /content \\\ I know that this works also if you're using the maven-eclipse-plugin. regards, Bernhard On 01/31/2008 +0100, Leonardo Uribe [EMAIL PROTECTED] wrote: Ok, I understand. * generating source into the src/main/java tree sucks, because it is hard to tell generated code apart from non-generated stuff. * generating source into the target tree sucks a bit, because you need to explicitly add it to an IDE So we agree that the option that sucks less is generating source into the target directory? regards Leonardo Uribe
Re: myfaces-faces-plugin - architecture
Hello, On 01/31/2008 +0100, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Bernhard, On Thu, Jan 31, 2008 at 12:54 AM, Bernhard Huemer [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, I'm just wondering what version of the maven-eclipse- or the maven-idea-plugin you're using because I've never had problems with the maven-faces-plugin generating source in the target tree. mvn eclipse:eclipse or mvn idea:idea configures the project properly at least for me as I don't have to add additional source folders. and what about the component-templates - can you debug the source for them like this? Why not? It's just another source folder. Usually IDEs don't mind whether a source folder is located in a directory called target. ;-) However, maybe I didn't get your question .. I know that this works also if you're using the maven-eclipse-plugin. so you say mvn eclipse:eclipse in the myfaces current directory, and you can start the sample app from within Eclipse - referring not to jars in your maven-repository, but only to other MyFaces modules in Eclipse? I highly doubt this... I don't know if that's true for the maven-eclipse-plugin, but I know that it is when using the maven-idea-plugin. Changes in one module are recognized immediately in all modules that depend on the one you've modofied. However, I'm not sure what you meen with start the sample app, but for example think of the project structure of MyFaces itself. In this case the myfaces-impl module doesn't refer to the myfaces-api jar in the maven repository but rather to the myfaces-api module in the current i.e in the same project. regards, Bernhard
[jira] Commented: (MYFACES-1802) FacesException and nested exceptions
[ https://issues.apache.org/jira/browse/MYFACES-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558381#action_12558381 ] Bernhard Huemer commented on MYFACES-1802: -- Introducing a new interface with two implementations ... it seems that I've overengineered the problem a little bit. As we only use reflection in an error case, I think it's fine if we keep status quo (i.e. the changes that Simon has commited). FacesException and nested exceptions Key: MYFACES-1802 URL: https://issues.apache.org/jira/browse/MYFACES-1802 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.5 Reporter: Bernhard Huemer Fix For: 1.1.6-SNAPSHOT Attachments: MyFaces-1802.patch The JSF 1.1 specification requires any implementation to support Java 1.3 and that's why the FacesException isn't allowed to utilize builtin exception chaining mechanisms (i.e. initCause(), etc..) as they have been introduced in Java 1.4. However, the FacesException retains it's cause by delegating to the parent's constructor (for example, super(cause); or super(message, cause);). Although this bug is rather easy to fix, I've assigned the priority level 'Major' as it breaks the specification. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1802) FacesException and nested exceptions
[ https://issues.apache.org/jira/browse/MYFACES-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558379#action_12558379 ] Bernhard Huemer commented on MYFACES-1802: -- The problem is that it seems that noone is using MyFaces 1.1.x in a Java 1.3 environment, but everyone suffers from the resulting performance impact. I wouldn't pay attention to every single case where we can improve MyFaces 1.1.x for users still working in a Java 1.3 environment (at least not if there's an impact for our actual userbase and keep in mind that obviously noone has been using MyFaces 1.1.x in a Java 1.3 environment!). Note that the Spring 2.5 developers have dropped Java 1.3 support .. Simon, I guess I have to admit that I can't find something regarding method linkage in the JLS either, but then we can still introduce an additional indirection, for example by using an interface ExceptionCauseRetriever with two implementations, one assuming that it is running a Java = 1.4 environment and the other one using reflection to support backward compatible exceptions too (just as Mario suggested). FacesException and nested exceptions Key: MYFACES-1802 URL: https://issues.apache.org/jira/browse/MYFACES-1802 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.5 Reporter: Bernhard Huemer Fix For: 1.1.6-SNAPSHOT Attachments: MyFaces-1802.patch The JSF 1.1 specification requires any implementation to support Java 1.3 and that's why the FacesException isn't allowed to utilize builtin exception chaining mechanisms (i.e. initCause(), etc..) as they have been introduced in Java 1.4. However, the FacesException retains it's cause by delegating to the parent's constructor (for example, super(cause); or super(message, cause);). Although this bug is rather easy to fix, I've assigned the priority level 'Major' as it breaks the specification. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1802) FacesException and nested exceptions
FacesException and nested exceptions Key: MYFACES-1802 URL: https://issues.apache.org/jira/browse/MYFACES-1802 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.5 Reporter: Bernhard Huemer The JSF 1.1 specification requires any implementation to support Java 1.3 and that's why the FacesException isn't allowed to utilize builtin exception chaining mechanisms (i.e. initCause(), etc..) as they have been introduced in Java 1.4. However, the FacesException retains it's cause by delegating to the parent's constructor (for example, super(cause); or super(message, cause);). Although this bug is rather easy to fix, I've assigned the priority level 'Major' as it breaks the specification. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-14) Setting the request character encoding during a RenderRequest
Setting the request character encoding during a RenderRequest
-
Key: PORTLETBRIDGE-14
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-14
Project: MyFaces Portlet Bridge
Issue Type: Bug
Affects Versions: 1.0.0-SNAPSHOT
Environment: Tomcat 5.5.20, Pluto 1.1.4, MyFaces 1.2.1-SNAPSHOT
(locally patched version)
Reporter: Bernhard Huemer
Priority: Critical
The JSF specification requires the ViewHandler to store the content-type in the
session at the end of the render-response phase (see 2.5.2.2 Determining the
Character Encoding). On subsequent render requests the view will be restored
(actually, a new one will be created but that doesn't matter) and during this
task the ViewHandler tries to set the request character encoding.
/// myfaces-api/src/main/java/javax/faces/application/ViewHandler.java
/**
* Method must be called by the JSF impl at the beginning of Phase iRestore
View/i of the JSF
* lifecycle.
*
* @since JSF 1.2
*/
public void initView(javax.faces.context.FacesContext context) throws
FacesException
{
String _encoding = this.calculateCharacterEncoding(context);
if(_encoding != null)
{
try
{
context.getExternalContext().setRequestCharacterEncoding(_encoding);
}
catch(UnsupportedEncodingException uee)
{
throw new FacesException(uee);
}
}
}
\\\
However, this attempt fails as the portlet bridge requires the request to be an
ActionRequest.
///
portlet-bridge-impl/src/main/java/org/apache/myfaces/portlet/faces/context/PortletExternalContextImpl
public void setRequestCharacterEncoding(String encoding) throws
UnsupportedEncodingException,
IllegalStateException
{
if (mPhase != Bridge.PortletPhase.ActionPhase)
{
throw new IllegalStateException(
PortletExternalContextImpl.setRequestCharacterEncoding(): Request must be an
ActionRequest);
}
((ActionRequest) mPortletRequest).setCharacterEncoding(encoding);
}
\\\
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PORTLETBRIDGE-12) PortletViewHandler - viewId handling
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543094
]
Bernhard Huemer commented on PORTLETBRIDGE-12:
--
Now it works like a charm (well, actually I had to apply further modifications
but that's another issue). I've also noticed that you've fixed a bug regarding
view id calculation by using the javax.servlet.include.servlet_path request
attribute. ;-)
PortletViewHandler - viewId handling
Key: PORTLETBRIDGE-12
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-12
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Environment: Tomcat 5.5.20, Pluto 1.1.4, MyFaces 1.2.1-SNAPSHOT
(locally patched version)
Reporter: Bernhard Huemer
Priority: Critical
Fix For: 1.0.0-SNAPSHOT
Attachments: Patch01.patch
While restoring a view JSF tries to determine the view ID by using some
request information (i.e. request path and path info). However, a JSF portlet
bridge has to use a different approach to save the view ID (because of the
portlet environment) and therefore the PortletViewHandler intercepts
getActionURL in order to save the view ID as url argument. During the next
request the PortletExternalContext simulates the appropriate request info
using this view ID (see PortletExternalContextImpl.mapPathsFromViewId). The
problem is that the PortletViewHandler doesn't save the correct version of
the view ID.
The following example shoud illustrate why the view ID is incorrect.
Default View ID: /index.jsf, Default Suffix: .xhtml
As I've already said, the PortletViewHandler saves the view ID as url
argument. Actually the PortletExternalContext is responsible for saving url
parameters, but the PortletViewHandler determines the view ID to save (see
PortletViewHandler.getActionURL). However, the PortletViewHandler saves the
given view ID (i.e. the given parameter - just remember the signature of
getActionURL) which results in the following url:
/context-name/index.jsf?_VIEW_ID=/index.xhtml
During the next request the PortletExternalContext tries to map the path
information by using this view ID (I know that I'm repeating myself ;-)). In
order to so, it iterates over all servlet mappings to determine the proper
request information. This attempt fails, however, as no Faces Servlet has
been mapped to *.xhtml. As a last resort the PortletExternalContext assumes
that the given view ID can be used as path info. The outcome of this is:
request path = null
path info = /index.xhtml
However, JSF would expect the following request information in order to
restore the appropriate view:
request path = /index.jsf
path info = null
I've resolved the bug by saving the external view ID (don't know if there's
any special name for it, for example /index.jsf instead of /index.xhtml), at
least it works here, but my patch is rather provisional as I've just done
the following:
Index:
impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
===
---
impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
Tue Nov 06 13:22:08 CET 2007
+++
impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
Tue Nov 06 13:22:08 CET 2007
@@ -127,7 +127,7 @@
// attribute
{
actionURL = URLUtils.appendURLArguments(actionURL, new String[] {
- PortletExternalContextImpl.VIEW_ID_QUERY_PARAMETER, viewId });
+ PortletExternalContextImpl.VIEW_ID_QUERY_PARAMETER,
viewId.replace(xhtml, jsf) });
}
return actionURL;
I'll create an appropriate version of this patch next week, if no one else
wants to take a look at it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: external api change OK for myfaces-impl 1.2.1?
Hello,
Actually, the problem is that you can't take part in the initialization
process, i.e. there is no way to add support for additional,
non-standard injection annotations. For example, I thought of rewriting
Dennis' Guice integration:
///
public class GuiceLifecycleProvider implements LifecycleProvider {
private LifecycleProvider delegate;
public GuiceLifecycleProvider(LifecycleProvider delegate) {
this.delegate = delegate;
}
public Object newInstance(String className) throws ... {
Object bean = delegate.newInstance(className);
injectGuiceDependencies(bean);
return bean;
}
public void postConstruct(Object bean) throws ... {
delegate.postConstruct(bean);
}
// ...
}
\\\
The same goes for Spring @Autowire support, additional WebBeans
integration, etc. That's why I think that my patch provides more
flexibility.
However, if you really can't live with the seperation of initialization
and postconstruction, what about introducing InjectionTasks? The
ManagedBeanBuilder, for example, could register an InjectionTask that
handles the injection of managed properties. In fact, I'm thinking of a
more general approach of your patch so that others can perform
additional injection too.
///
public interface InjectionTask {
public void inject(Object bean) throws ...;
}
\\\
Nevertheless, I still think that the seperation would be the ideal
solution as it doesn't additional complexity.
regards
Bernhard
On 11/13/2007 +0100,
Paul McMahan [EMAIL PROTECTED] wrote:
Bernd,
My understanding of the JSF 1.2 spec is that annotation processing for
managed beans pertains to the injection of JavaEE managed resources.
Now Bernhard raises a good point which is that for JSF developers a more
practical use of the term injection could also mean the initialization
of managed bean properties from their application config file, and they
would expect this initialization to also work in conjunction with the
@PostConstruct annotation. While that behavior is not prescribed by the
spec, I agree that MyFaces users would intuitively expect it to work
that way.
His patch enforces this functionality by factoring the implicit handling
of @PostConstruct annotations out of the newInstance() method and
placing MyFaces in explicit control over when that one particular type
of annotation should be processed. However, I think a goal of the
LifecycleProvider interface has been and should remain to be providing a
clean separation for delegating annotation processing to the container,
and that MyFaces should assist rather than orchestrate the overall
process of resource injection for this one special case. I think that
the advantages of this approach are that it keeps MyFaces more insulated
from future changes to the annotation processing specs and it makes
MyFaces more portable by giving more flexibility to the container. I
also believe that further advantages of this approach will become
apparent as standards such as web beans emerge, where the EJB and
ManagedBean component models are unified.
Best wishes,
Paul
On Nov 12, 2007, at 2:46 PM, Bernd Bohmann wrote:
Hello Paul,
what is wrong with Bernhards patch?
Instead of handling all of the annotation processing in
LifecycleProvider.newInstance(String className)
he suggest to add a method
LifecycleProvider.postConstruct(Object obj)
this method is called after the properties are injected by the
annotation provider and the managed bean properties from the jsf impl.
Why we should delegate the injection of the none annotation based
managed bean properties to the LifecycleProvider? This must be
implemented by Geronimo and the MyFaces Default LifecycleProvider.
I would prefer only one place for the old style managed bean properties
injection.
Regards
Bernd
Paul McMahan schrieb:
The LifecycleProvider interface was introduced in MyFaces core 1.2.0 as
an integration point that allows Java EE containers to handle annotation
processing for JSF managed beans. In order to help containers invoke
@PostConstruct methods more consistently with the Java EE RI (glassfish)
we are discussing changing this API in:
https://issues.apache.org/jira/browse/MYFACES-1761
I attached a patch (MYFACES-1761-01.diff) to that JIRA that would change
a method signature from :
LifecycleProvider.newInstance(String className)
to
LifecycleProvider.newInstance(ManagedBean beanConfig)
The only known implementer of the LifecycleProvider interface (outside
of MyFaces itself) is the Geronimo project, which is in favor of this
change. Are there any concerns with changing this external api in the
upcoming 1.2.1 maintenance release?
BTW, this patch also refactors ManagedBeanBuilder into
ManageBeanInitializer so that the existing code in that class can still
be used to initialize managed properties. Unless I am mistaken
ManagedBeanBuilder was not intended to be externally overridden
Re: external api change OK for myfaces-impl 1.2.1?
s/as it doesn't additional complexity/as it doesn't introduce additional
complexity
Usually, errors don't matter, but I think it's more difficult to
understand otherwise.
On 11/13/2007 +0100,
Bernhard Huemer [EMAIL PROTECTED] wrote:
Hello,
Actually, the problem is that you can't take part in the initialization
process, i.e. there is no way to add support for additional,
non-standard injection annotations. For example, I thought of rewriting
Dennis' Guice integration:
///
public class GuiceLifecycleProvider implements LifecycleProvider {
private LifecycleProvider delegate;
public GuiceLifecycleProvider(LifecycleProvider delegate) {
this.delegate = delegate;
}
public Object newInstance(String className) throws ... {
Object bean = delegate.newInstance(className);
injectGuiceDependencies(bean);
return bean;
}
public void postConstruct(Object bean) throws ... {
delegate.postConstruct(bean);
}
// ...
}
\\\
The same goes for Spring @Autowire support, additional WebBeans
integration, etc. That's why I think that my patch provides more
flexibility.
However, if you really can't live with the seperation of initialization
and postconstruction, what about introducing InjectionTasks? The
ManagedBeanBuilder, for example, could register an InjectionTask that
handles the injection of managed properties. In fact, I'm thinking of a
more general approach of your patch so that others can perform
additional injection too.
///
public interface InjectionTask {
public void inject(Object bean) throws ...;
}
\\\
Nevertheless, I still think that the seperation would be the ideal
solution as it doesn't additional complexity.
regards
Bernhard
On 11/13/2007 +0100,
Paul McMahan [EMAIL PROTECTED] wrote:
Bernd,
My understanding of the JSF 1.2 spec is that annotation processing for
managed beans pertains to the injection of JavaEE managed resources.
Now Bernhard raises a good point which is that for JSF developers a
more practical use of the term injection could also mean the
initialization of managed bean properties from their application
config file, and they would expect this initialization to also work in
conjunction with the @PostConstruct annotation. While that behavior
is not prescribed by the spec, I agree that MyFaces users would
intuitively expect it to work that way.
His patch enforces this functionality by factoring the implicit
handling of @PostConstruct annotations out of the newInstance() method
and placing MyFaces in explicit control over when that one particular
type of annotation should be processed. However, I think a goal of
the LifecycleProvider interface has been and should remain to be
providing a clean separation for delegating annotation processing to
the container, and that MyFaces should assist rather than orchestrate
the overall process of resource injection for this one special case.
I think that the advantages of this approach are that it keeps MyFaces
more insulated from future changes to the annotation processing specs
and it makes MyFaces more portable by giving more flexibility to the
container. I also believe that further advantages of this approach
will become apparent as standards such as web beans emerge, where the
EJB and ManagedBean component models are unified.
Best wishes,
Paul
On Nov 12, 2007, at 2:46 PM, Bernd Bohmann wrote:
Hello Paul,
what is wrong with Bernhards patch?
Instead of handling all of the annotation processing in
LifecycleProvider.newInstance(String className)
he suggest to add a method
LifecycleProvider.postConstruct(Object obj)
this method is called after the properties are injected by the
annotation provider and the managed bean properties from the jsf impl.
Why we should delegate the injection of the none annotation based
managed bean properties to the LifecycleProvider? This must be
implemented by Geronimo and the MyFaces Default LifecycleProvider.
I would prefer only one place for the old style managed bean properties
injection.
Regards
Bernd
Paul McMahan schrieb:
The LifecycleProvider interface was introduced in MyFaces core 1.2.0 as
an integration point that allows Java EE containers to handle
annotation
processing for JSF managed beans. In order to help containers invoke
@PostConstruct methods more consistently with the Java EE RI
(glassfish)
we are discussing changing this API in:
https://issues.apache.org/jira/browse/MYFACES-1761
I attached a patch (MYFACES-1761-01.diff) to that JIRA that would
change
a method signature from :
LifecycleProvider.newInstance(String className)
to
LifecycleProvider.newInstance(ManagedBean beanConfig)
The only known implementer of the LifecycleProvider interface (outside
of MyFaces itself) is the Geronimo project, which is in favor of this
change. Are there any concerns with changing this external api in the
upcoming 1.2.1 maintenance release?
BTW
Re: external api change OK for myfaces-impl 1.2.1?
Hello,
Ok, I'll do that on Thursday, if you don't mind.
regards,
Bernhard
On 11/13/2007 +0100,
Paul McMahan [EMAIL PROTECTED] wrote:
On Nov 13, 2007, at 3:03 PM, Bernhard Huemer wrote:
However, if you really can't live with the seperation of
initialization and postconstruction, what about introducing
InjectionTasks? The ManagedBeanBuilder, for example, could register
an InjectionTask that handles the injection of managed properties. In
fact, I'm thinking of a more general approach of your patch so that
others can perform additional injection too.
///
public interface InjectionTask {
public void inject(Object bean) throws ...;
}
Yes, if I understand this new interface correctly then I think it would
provide the best of both worlds. Bravo for an excellent idea!
I actually started this thread to make sure it's OK to change the
LifecycleProvider interface in the upcoming 1.2.1 maintenance release.
No concerns have been raised yet so I think that we can proceed in that
direction.
Would you mind updating the JIRA with this new idea since the rest of
our discussion is recorded there? And if you have a specific
implementation in mind then please feel free to modify my patch. I
really think we are on the right track here.
Best wishes,
Paul
[jira] Commented: (PORTLETBRIDGE-12) PortletViewHandler - viewId handling
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542014
]
Bernhard Huemer commented on PORTLETBRIDGE-12:
--
Of course not! The official patch will calculate the view id by using
additional information like the FacesServlet mapping, the DEFAULT_SUFFIX, etc.
I just wanted to give a clue.
PortletViewHandler - viewId handling
Key: PORTLETBRIDGE-12
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-12
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Environment: Tomcat 5.5.20, Pluto 1.1.4, MyFaces 1.2.1-SNAPSHOT
(locally patched version)
Reporter: Bernhard Huemer
Priority: Critical
While restoring a view JSF tries to determine the view ID by using some
request information (i.e. request path and path info). However, a JSF portlet
bridge has to use a different approach to save the view ID (because of the
portlet environment) and therefore the PortletViewHandler intercepts
getActionURL in order to save the view ID as url argument. During the next
request the PortletExternalContext simulates the appropriate request info
using this view ID (see PortletExternalContextImpl.mapPathsFromViewId). The
problem is that the PortletViewHandler doesn't save the correct version of
the view ID.
The following example shoud illustrate why the view ID is incorrect.
Default View ID: /index.jsf, Default Suffix: .xhtml
As I've already said, the PortletViewHandler saves the view ID as url
argument. Actually the PortletExternalContext is responsible for saving url
parameters, but the PortletViewHandler determines the view ID to save (see
PortletViewHandler.getActionURL). However, the PortletViewHandler saves the
given view ID (i.e. the given parameter - just remember the signature of
getActionURL) which results in the following url:
/context-name/index.jsf?_VIEW_ID=/index.xhtml
During the next request the PortletExternalContext tries to map the path
information by using this view ID (I know that I'm repeating myself ;-)). In
order to so, it iterates over all servlet mappings to determine the proper
request information. This attempt fails, however, as no Faces Servlet has
been mapped to *.xhtml. As a last resort the PortletExternalContext assumes
that the given view ID can be used as path info. The outcome of this is:
request path = null
path info = /index.xhtml
However, JSF would expect the following request information in order to
restore the appropriate view:
request path = /index.jsf
path info = null
I've resolved the bug by saving the external view ID (don't know if there's
any special name for it, for example /index.jsf instead of /index.xhtml), at
least it works here, but my patch is rather provisional as I've just done
the following:
Index:
impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
===
---
impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
Tue Nov 06 13:22:08 CET 2007
+++
impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
Tue Nov 06 13:22:08 CET 2007
@@ -127,7 +127,7 @@
// attribute
{
actionURL = URLUtils.appendURLArguments(actionURL, new String[] {
- PortletExternalContextImpl.VIEW_ID_QUERY_PARAMETER, viewId });
+ PortletExternalContextImpl.VIEW_ID_QUERY_PARAMETER,
viewId.replace(xhtml, jsf) });
}
return actionURL;
I'll create an appropriate version of this patch next week, if no one else
wants to take a look at it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-12) PortletViewHandler - viewId handling
PortletViewHandler - viewId handling
Key: PORTLETBRIDGE-12
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-12
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Environment: Tomcat 5.5.20, Pluto 1.1.4, MyFaces 1.2.1-SNAPSHOT
(locally patched version)
Reporter: Bernhard Huemer
Priority: Critical
While restoring a view JSF tries to determine the view ID using some request
information (i.e. request path and path info). However, a JSF portlet bridge
has to use a different approach to save the view ID (because of the portlet
environment) and therefore the PortletViewHandler intercepts getActionURL in
order to save the view ID as url argument. During the next request the
PortletExternalContext simulates the appropriate request info using this view
ID (see PortletExternalContextImpl.mapPathsFromViewId). The problem is that the
PortletViewHandler doesn't save the correct version of the view ID.
The following example shoud illustrate why the view ID is incorrect.
Default View ID: /index.jsf, Default Suffix: .xhtml
As I've already said, the PortletViewHandler saves the view ID as url argument.
Actually the PortletExternalContext is responsible for saving url parameters,
but the PortletViewHandler determines the view ID to save (see
PortletViewHandler.getActionURL). However, the PortletViewHandler saves the
given view ID (i.e. the given parameter - just remember the signature of
getActionURL) which results in the following url:
/context-name/index.jsf?_VIEW_ID=/index.xhtml
During the next request the PortletExternalContext tries to map the path
information using this view ID (I know that I'm repeating myself ;-)). In order
to so, it iterates over all servlet mappings to determine the proper request
information. This attempt fails, however, as no Faces Servlet has been mapped
to *.xhtml. As a last resort the PortletExternalContext assumes that the given
view ID can be used as path info. The outcome of this is:
request path = null
path info = /index.xhtml
However, JSF would expect the following request information in order to
restore the appropriate view:
request path = /index.jsf
path info = null
I've resolved the bug by saving the external view ID (don't know if there's
any special name for it, for example /index.jsf instead of /index.xhtml), at
least it works here, but my patch is rather provisional as I've just done the
following:
Index:
impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
===
---
impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
Tue Nov 06 13:22:08 CET 2007
+++
impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
Tue Nov 06 13:22:08 CET 2007
@@ -127,7 +127,7 @@
// attribute
{
actionURL = URLUtils.appendURLArguments(actionURL, new String[] {
- PortletExternalContextImpl.VIEW_ID_QUERY_PARAMETER, viewId });
+ PortletExternalContextImpl.VIEW_ID_QUERY_PARAMETER,
viewId.replace(xhtml, jsf) });
}
return actionURL;
I'll create an appropriate version of this patch next week, if no one else
wants to take a look at it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541363 ] Bernhard Huemer commented on MYFACES-1761: -- I guess I have to agree that the specification leaves room to interpretation and I understand your point of view, but I wouldn't go so far as you. In fact I didn't even thought of it as your intepretation seems rather farfetched to me (sorry ;-)), especially if I'm considering the specification issue discussion. Ed Burns proposed the following: 1. call any public no argument managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after *any* injection is performed, but before the bean is placed into the scope. Besides that, I don't understand why you're strongly objecting to changing the interface. LifecycleProvider.newInstance() remains to be a perfect integration point for injecting serveral JavaEE components. My proposed patch shows how easy it is to refactor a typical implementation (I know that it has not been a full-fledged JavaEE container, but I think it's actually the same - just a simple processAnnotations method call). Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541122 ] Bernhard Huemer commented on MYFACES-1761: -- In fact, I've even quoted the specification - Page 11, Spec Issue 119: Specified that implementations running in a JSR-250 compliant container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Specified that methods annotated with @PreDestroy be called when the scope for the bean is ending. Additionally, the InjectionProvider interface, the RI's counterpart to our LifecycleProvider, has always seperated injection and postconstruction. There is only one difference between those interfaces (of course, I'm referring to the patched version of the LifecycleProvider interface), the LifecycleProvider interface does support constructor injection whereas the InjectionProvider interface doesn't. I've also tested the postconstruct-demo using the RI and it behaves as I'd expect it - the method annotated with @PostConstruct is called after all properties (including JSF managed ones) have been injected. However, I don't think that it's possible to fix this bug without changing the LifecycleProvider interface. Of course, you could refactor some internal classes in order to involve the ManagedBeanBuilder in initializing the bean, but I wouldn't recommend it. The problem with this fix is that it wouldn't work with 3rd party implementations as you're required to refactor all implementations (i.e. you're introducing a breaking change even without changing the interface itself). Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1761) Handling PostConstruct annotations - wrong order
Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://mail-archives.apache.org/mod_mbox/myfaces-users/200711.mbox/[EMAIL PROTECTED]). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Huemer updated MYFACES-1761: - Status: Patch Available (was: Open) Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://mail-archives.apache.org/mod_mbox/myfaces-users/200711.mbox/[EMAIL PROTECTED]). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540625 ] Bernhard Huemer commented on MYFACES-1761: -- Well, I'm not talking about full-fledged dependency injection (i.e. processing @Resource or @EJB annotations, ..), but rather about managed property injection. A LifecycleProvider can't return beans ready for use as these dependencies are still missing. However, a LifecycleProvider can't inject them itself (or at least it shouldn't) as that's something that the ManagedBeanBuilder is responsible for. Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Facelets, MyFaces 1.2 Tomcat 5
Hello, I'm just wondering if anyone has tried out the JSP 2.0 integration that I've proposed several weeks ago [1]? Maybe it's just me, but I think that'd be a great addition for the next release. So far I've tested it using the following environments: - Tomcat 5.5.25 + Facelets 1.1.13 - Tomcat 5.5.20 + Pluto 1.1.4 (== pluto-current-bundle) + JSR-301 Bridge + Facelets 1.1.13 regards, Bernhard [1]: https://issues.apache.org/jira/browse/MYFACES-1693
Re: [jira] Commented: (MYFACES-1745) for-Attribute of UIMessage and HtmlOutputLabel does not work with an EL Expression
Hello,
that's what I've already detected.
That seems to be a trivial bug of the Maven Faces Plugin's
MyFacesComponentGenerator. In order to the generate the fancy getter,
it uses the name of the given parameter rather than the name of the
property.
regards,
Bernhard
On 10/17/2007 +0200,
Andrew Robinson [EMAIL PROTECTED] wrote:
I'm looking into this as a problem with the maven-faces-plugin source.
What is interesting is the trunk is pointing at an old version of the
plugin (1.2.1.1).
I'll try to see what is going on with the plugin and see if I can use
1.2.4-SNAPSHOT to debug the issue. It seems like the
MyFacesComponentGenerator is not using the correct variable to produce
the getter method body
-Andrew
On 10/17/07, Mike Kienenberger (JIRA) dev@myfaces.apache.org wrote:
[
https://issues.apache.org/jira/browse/MYFACES-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535594
]
Mike Kienenberger commented on MYFACES-1745:
At this point, you probably would be better off asking on the dev list on how
to configure the generation process.
I was only half-joking about the permissions, but it could be done on most operating systems. For
Windows, which is what it sounds like you're using, you can hit properties for a file (or folder),
then the security tab, then click Advanced and most likely the access control will be
Allow Everyone Full Control
You can edit that access control to disallow delete. Just remember to
change it back after you are done :-)
for-Attribute of UIMessage and HtmlOutputLabel does not work with an EL
Expression
--
Key: MYFACES-1745
URL: https://issues.apache.org/jira/browse/MYFACES-1745
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.1-SNAPSHOT
Environment: Tomcat 6.0.15 (snapshot), Facelets 1.1.14
Reporter: Jan Ziegler
Attachments: MyFaces-1745.patch
When using an EL-Expression in the 'for'-Attribute of a UIMessage or
HtmlOutputPanel, the EL is always resolved to null.
Here is an Example:
...
h:form
h:outputLabel for=#{testBean.test} /
h:inputText id=#{testBean.test} value= required=true /
h:message for=#{testBean.test} /
h:commandButton value=click /
/h:form
...
You see that the 'for'-Attributes of the message and label as well as the
'id'-Attribute of the inputText refer to the same value which returns some
valid string in my TestBean:
...
public String getTest()
{
return testID;
}
...
When rendering the page, a message will never be rendered (even no value is
given but the field is required) and the label cannot be linked to the input
field - there appears two error messages on the console:
Attribute 'for' of label component with id j_id1:j_id2 is not defined
Attribute 'for' of UIMessage must not be null
which means the value of the EL-Expression resolves to null I think. In other
cases, it is no problem to resolve the value, e.g. in an HtmlOutputText:
h:outputText value=#{testBean.test} /
Therefor I looked into the source code of UIMessage and HtmlOutputLabel. I
think I found the bug. Look at the 'getFor()'-function of UIMessage (also in
HtmlOutputLabel):
public String getFor()
{
if (_for != null)
{
return _for;
}
ValueExpression expression = getValueExpression(forParam);
if (expression != null)
{
return (String)expression.getValue(getFacesContext().getELContext());
}
return null;
}
I think 'forParam' is the wrong identifier for the ValueExpression ´cause in
the Tag-classes, a value expression of the 'for'-Attribute is set via
comp.setValueExpression(for, _for);
A fix should be to use 'forParam' as an identifier in the Tag classes or 'for'
as an identifier in the component-classes to use the same identifier for the
value expression in all participants
Am I right with that?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1745) for-Attribute of UIMessage and HtmlOutputLabel does not work with an EL Expression
[
https://issues.apache.org/jira/browse/MYFACES-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534956
]
Bernhard Huemer commented on MYFACES-1745:
--
That seems to be a trivial bug of the Maven Faces Plugin's
MyFacesComponentGenerator. In order to the generate the fancy getter, it uses
the name of the given parameter rather than the name of the property.
for-Attribute of UIMessage and HtmlOutputLabel does not work with an EL
Expression
--
Key: MYFACES-1745
URL: https://issues.apache.org/jira/browse/MYFACES-1745
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.1-SNAPSHOT
Environment: Tomcat 6.0.15 (snapshot), Facelets 1.1.14
Reporter: Jan Ziegler
Attachments: MyFaces-1745.patch
When using an EL-Expression in the 'for'-Attribute of a UIMessage or
HtmlOutputPanel, the EL is always resolved to null.
Here is an Example:
...
h:form
h:outputLabel for=#{testBean.test} /
h:inputText id=#{testBean.test} value= required=true /
h:message for=#{testBean.test} /
h:commandButton value=click /
/h:form
...
You see that the 'for'-Attributes of the message and label as well as the
'id'-Attribute of the inputText refer to the same value which returns some
valid string in my TestBean:
...
public String getTest()
{
return testID;
}
...
When rendering the page, a message will never be rendered (even no value is
given but the field is required) and the label cannot be linked to the input
field - there appears two error messages on the console:
Attribute 'for' of label component with id j_id1:j_id2 is not defined
Attribute 'for' of UIMessage must not be null
which means the value of the EL-Expression resolves to null I think. In other
cases, it is no problem to resolve the value, e.g. in an HtmlOutputText:
h:outputText value=#{testBean.test} /
Therefor I looked into the source code of UIMessage and HtmlOutputLabel. I
think I found the bug. Look at the 'getFor()'-function of UIMessage (also in
HtmlOutputLabel):
public String getFor()
{
if (_for != null)
{
return _for;
}
ValueExpression expression = getValueExpression(forParam);
if (expression != null)
{
return (String)expression.getValue(getFacesContext().getELContext());
}
return null;
}
I think 'forParam' is the wrong identifier for the ValueExpression ´cause in
the Tag-classes, a value expression of the 'for'-Attribute is set via
comp.setValueExpression(for, _for);
A fix should be to use 'forParam' as an identifier in the Tag classes or
'for' as an identifier in the component-classes to use the same identifier
for the value expression in all participants
Am I right with that?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1737) myfaces-impl jar does not include faces-config dtds and thus won't work if offline
[ https://issues.apache.org/jira/browse/MYFACES-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533456 ] Bernhard Huemer commented on MYFACES-1737: -- This bug seems to be a duplicate of https://issues.apache.org/jira/browse/MYFACES-1735, which has been fixed recently. myfaces-impl jar does not include faces-config dtds and thus won't work if offline -- Key: MYFACES-1737 URL: https://issues.apache.org/jira/browse/MYFACES-1737 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Environment: MyFaces 1.2 reading faces-config.xml with a doctype of JSF 1.0 or 1.1 Reporter: Karol Bucek Priority: Minor While initializing faces configuration and being offline (or behind a proxy), MyFaces won't start and ends with something like: DefaultFacesInitializer.initFaces(126) | Error initializing MyFaces: java.net.ConnectException: Connection timed out: connect The issue is caused by the parser trying to get the dtd for: http://java.sun.com/dtd/web-facesconfig_1_x.dtd when for some reason it cannot connect to the http url. The dtd is not being resolved from the jar as it is missing in 1.2.0, org.apache.myfaces.config.impl.FacesConfigEntityResolver will attempt to resolve the resource from org/apache/myfaces/resource, but version 1.2.0 of the myfaces-impl.jar is missing the 'older' dtds (it only contains org/apache/myfaces/resource/web-facesconfig_1_2.xsd). By copying the web-facesconfig_1_0.dtd and the web-facesconfig_1_1.dtd into the jar everything works as expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Maven Snapshot Build out of date?
Hello, I'm just wondering if there are other Maven Snapshot repositories beside http://people.apache.org/repo/m2-snapshot-repository/; as it seems that this repository is out of date. The myfaces-core artifacts haven't been modified since Sept 01, 2007 (for example see: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/core/myfaces-impl/1.2.1-SNAPSHOT/). regards, Bernhard
Re: [orchestra] Conversation Timeouts (was changed scope configuration)
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
Why did you remove the DTDs?
Hello, according to the SVN Commit History (see MYFACES-1639 [1]) you've knowingly removed the DTDs. As far as I know, that's the reason why MyFaces 1.2 requires a connection to the internet when deploying a JSF 1.0 or JSF 1.1 application (see MYFACES-1690 [2], even though the reporter assumes that MyFaces doesn't use the local XSD). Why didn't you use those hand typed versions? However, if it's really necessary to remove the DTDs, what's the point in keeping the FacesConfigEntityResolver [3]? Am I missing something? regards, Bernhard [1]: http://issues.apache.org/jira/browse/MYFACES-1639 [2]: http://issues.apache.org/jira/browse/MYFACES-1690 [3]: http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/config/impl/FacesConfigEntityResolver.java
[jira] Issue Comment Edited: (MYFACES-1693) Make JSP 2.1 optional
[ https://issues.apache.org/jira/browse/MYFACES-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520540 ] bhuemer edited comment on MYFACES-1693 at 8/20/07 6:44 AM: --- I'll attach a patch which enables you to run MyFaces in a J2EE 1.4 environment using facelets. There's only two things you have to do: Provide a context-param that specifies the ExpressionFactory implementation of your EL implementation (for example, com.sun.el.ExpressionFactoryImpl, if you're using the el-ri) and provide the EL implementation itself as it's not part of the container (for example, when using maven you have to declare an additional dependency). Actually, if you're using the Tomcat EL implementation or Sun's RI, you don't have to specify the ExpressionFactory implementation (i.e. there is no need for an additional context-param if you're using a common EL implementation). Additionally, I'll attach a small sample application (in fact it's quite inane) that demonstrates how to use MyFaces in a J2EE 1.4 environment. I've tested my patch using the facelets-demos (hangman and numberguess, see https://facelets.dev.java.net/). I'd appreciate if someone else tests my patch (other feedback is also welcome), but if you encounter problems, you'll have to be patient as I'm occupied for the next three days. was (Author: bhuemer): I'll attach a patch whitch enables you to run MyFaces in a J2EE 1.4 environment using facelets. There's only two things you have to do: Provide a context-param that specifies the ExpressionFactory implementation of your EL implementation (for example, com.sun.el.ExpressionFactoryImpl, if you're using the el-ri) and provide the EL implementation itself as it's not part of the container (for example, when using maven you have to declare an additional dependency). Actually, if you're using the Tomcat EL implementation or Sun's RI, you don't have to specify the ExpressionFactory implementation (i.e. there is no need for an additional context-param if you're using a common EL implementation). Additionally, I'll attach a small sample application (in fact it's quite inane) that demonstrates how to use MyFaces in a J2EE 1.4 environment. I've tested my patch using the facelets-demos (hangman and numberguess, see https://facelets.dev.java.net/). I'd appreciate if someone else tests my patch (other feedback is also welcome), but if you encounter problems, you'll have to be patient as I'm occupied for the next three days. Make JSP 2.1 optional -- Key: MYFACES-1693 URL: https://issues.apache.org/jira/browse/MYFACES-1693 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Affects Versions: 1.2.0 Reporter: Achim Hügen Attachments: facelets-jsf12-debug.zip, MYFACES-1693.patch Myfaces 1.2.0 requires JSP 2.1 to be present. Otherwise the StartupServletContextListener fails with this error: Exception sending context initialized event to listener instance of class org.apache.myfaces.webapp.StartupServletContextListener java.lang.NoSuchMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; at org.apache.myfaces.webapp.DefaultFacesInitializer.initFaces(DefaultFacesInitializer.java:102) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:57) JSP version 2.1 or better JSP in general should be an optional dependency, like discussed here and implemented in Sun RI too: http://www.nabble.com/Does-MyFaces-1.2-require-JSP-2.1--tf4112432.html#a11693501 Use cases: - Run Myfaces 1.2.0 in JEE 1.4 environment (Tomcat 5.x). - Easier setup and smaller distributions when running Myfaces in an embedded servlet container (jetty) with facelets. For example I'm using jetty for junit tests. I haven't found a working setup which solves the jsp problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1693) Make JSP 2.1 optional
[ https://issues.apache.org/jira/browse/MYFACES-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520540 ] Bernhard Huemer commented on MYFACES-1693: -- I'll attach a patch whitch enables you to run MyFaces in a J2EE 1.4 environment using facelets. There's only two things you have to do: Provide a context-param that specifies the ExpressionFactory implementation of your EL implementation (for example, com.sun.el.ExpressionFactoryImpl, if you're using the el-ri) and provide the EL implementation itself as it's not part of the container (for example, when using maven you have to declare an additional dependency). Actually, if you're using the Tomcat EL implementation or Sun's RI, you don't have to specify the ExpressionFactory implementation (i.e. there is no need for an additional context-param if you're using a common EL implementation). Additionally, I'll attach a small sample application (in fact it's quite inane) that demonstrates how to use MyFaces in a J2EE 1.4 environment. I've tested my patch using the facelets-demos (hangman and numberguess, see https://facelets.dev.java.net/). I'd appreciate if someone else tests my patch (other feedback is also welcome), but if you encounter problems, you'll have to be patient as I'm occupied for the next three days. Make JSP 2.1 optional -- Key: MYFACES-1693 URL: https://issues.apache.org/jira/browse/MYFACES-1693 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Affects Versions: 1.2.0 Reporter: Achim Hügen Myfaces 1.2.0 requires JSP 2.1 to be present. Otherwise the StartupServletContextListener fails with this error: Exception sending context initialized event to listener instance of class org.apache.myfaces.webapp.StartupServletContextListener java.lang.NoSuchMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; at org.apache.myfaces.webapp.DefaultFacesInitializer.initFaces(DefaultFacesInitializer.java:102) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:57) JSP version 2.1 or better JSP in general should be an optional dependency, like discussed here and implemented in Sun RI too: http://www.nabble.com/Does-MyFaces-1.2-require-JSP-2.1--tf4112432.html#a11693501 Use cases: - Run Myfaces 1.2.0 in JEE 1.4 environment (Tomcat 5.x). - Easier setup and smaller distributions when running Myfaces in an embedded servlet container (jetty) with facelets. For example I'm using jetty for junit tests. I haven't found a working setup which solves the jsp problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-1244) JSR-252 Issue #95: Allow multiple instances of FacesServlet in a single webapp, mapped with different URI mappings, to use different implementations of Life
[ https://issues.apache.org/jira/browse/MYFACES-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520111 ] bhuemer edited comment on MYFACES-1244 at 8/16/07 4:40 AM: --- It still seems that no one has commited this patch yet. Call me a nitpicker, but isn't this behaviour required by the JSF 1.2 specification (see section 10.2.6.2, paragraph 2)? Note that Christoph's patch is somewhat outdated by now but as it's just a single method it shouldn't be a problem. was (Author: bhuemer): It still seems that no one has commited this patch yet. Call me a nitpicker, but isn't this behaviour required by the JSF 1.2 specification (see section 10.2.6.2, paragraph 2)? Note that the patch is somewhat outdated by now but as it's just a single method it shouldn't be a problem. JSR-252 Issue #95: Allow multiple instances of FacesServlet in a single webapp, mapped with different URI mappings, to use different implementations of Lifecycle - Key: MYFACES-1244 URL: https://issues.apache.org/jira/browse/MYFACES-1244 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assignee: Christoph Ebner Fix For: 1.2.1-SNAPSHOT Attachments: FacesServlet.java, FacesServlet.patch Allow multiple instances of FacesServlet in a single webapp, mapped with different URI mappings, to use different implementations of Lifecycle by allowing the lifecycle-id to be specified as an init-param in addition to the existing way of specifying it as a context-param. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=95 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1244) JSR-252 Issue #95: Allow multiple instances of FacesServlet in a single webapp, mapped with different URI mappings, to use different implementations of Lifecycle
[ https://issues.apache.org/jira/browse/MYFACES-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520111 ] Bernhard Huemer commented on MYFACES-1244: -- It still seems that no one has commited this patch yet. Call me a nitpicker, but isn't this behaviour required by the JSF 1.2 specification (see section 10.2.6.2, paragraph 2)? Note that the patch is somewhat outdated by now but as it's just a single method it shouldn't be a problem. JSR-252 Issue #95: Allow multiple instances of FacesServlet in a single webapp, mapped with different URI mappings, to use different implementations of Lifecycle - Key: MYFACES-1244 URL: https://issues.apache.org/jira/browse/MYFACES-1244 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assignee: Christoph Ebner Attachments: FacesServlet.java, FacesServlet.patch Allow multiple instances of FacesServlet in a single webapp, mapped with different URI mappings, to use different implementations of Lifecycle by allowing the lifecycle-id to be specified as an init-param in addition to the existing way of specifying it as a context-param. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=95 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1709) faces-config.xml validation using an XML Schema
faces-config.xml validation using an XML Schema --- Key: MYFACES-1709 URL: https://issues.apache.org/jira/browse/MYFACES-1709 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer According to an inline comment (validation set to false during implementation of 1.2, DigesterFacesConfigUnmarshallerImpl) and my personal experience, configuration file validation hasn't been implemented so far. However, as far as I know the JSF specification says that JSF implementations that are part of a Java EE technology-compliant implementation are required to validate the application resource file against the XML schema (section 10.4.2). I'll attach a sample application reproducing the error (the fact that there is no error is incorrect this time) and the corresponding patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1695) f:setPropertyActionListener and h:commandButton leads to IllegalArgumentException
[
https://issues.apache.org/jira/browse/MYFACES-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519658
]
Bernhard Huemer commented on MYFACES-1695:
--
Well, in fact the Expression Language Specification states that it is legal to
assign a Long value to an int primitive (or an Integer respectively), see
section 1.18.3.
f:setPropertyActionListener and h:commandButton leads to
IllegalArgumentException
--
Key: MYFACES-1695
URL: https://issues.apache.org/jira/browse/MYFACES-1695
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.1-SNAPSHOT
Environment: Tomcat 6.0.13, Facelet 1.1.12 / Facelet 1.1.13 snapshot,
MyFaces 1.2.1snapshot
Reporter: Jan Ziegler
Im having a problem with f:setPropertyActionListener when binding the target
to an int-field. I never had this problem when using the latest MyFaces 1.1
and Facelets 1.1.12 which backported the
setPropertyActionListener-functionality to JSF 1.1 Environments.
Here´s an excerpt of the example xhtml-page:
h:commandButton value=click
f:setPropertyActionListener target=#{myBean.currentPage} value=1 /
/h:commandButton
and here the bean (int-approach):
public class MyBean
{
private int currentPage;
...
public int getCurrentPage()
{
return this.currentPage;
}
public int setCurrentPage(int page)
{
this.currentPage = page;
}
...
}
So when I click on the button to perform a submit I´m getting the following
Exception:
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.el.BeanELResolver.setValue(BeanELResolver.java:108)
at javax.el.CompositeELResolver.setValue(CompositeELResolver.java:68)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$501(FacesCompositeELResolver.java:46)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$6.invoke(FacesCompositeELResolver.java:132)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke(FacesCompositeELResolver.java:148)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setValue(FacesCompositeELResolver.java:128)
at org.apache.el.parser.AstValue.setValue(AstValue.java:114)
at
org.apache.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:249)
at
com.sun.facelets.el.TagValueExpression.setValue(TagValueExpression.java:93)
at
com.sun.facelets.tag.jsf.core.SetPropertyActionListenerHandler$SetPropertyListener.processAction(SetPropertyActionListenerHandler.java:113)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:48)
at
javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:487)
at javax.faces.component.UICommand.broadcast(UICommand.java:105)
at
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292)
at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209)
at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117)
at
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service
[jira] Commented: (MYFACES-1694) Myfaces 1.2 doesn't start without web.xml
[ https://issues.apache.org/jira/browse/MYFACES-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519535 ] Bernhard Huemer commented on MYFACES-1694: -- Currently MyFaces needs the mapping for the FacesServlet because of the url-pattern. MyFaces' ViewHandler calculates view IDs and action URLs based on this url-pattern, but I've attempted a different approach. The parts of the request URI (context path, servlet path and path info) provide more than enough information to calculate view IDs and action URLs. For example, if the path info is not null, the FacesServlet has been definitely mapped using prefix mapping and the servlet path indicates the url-pattern in this case. Additionally, thanks to refactoring of a small amount of code, you're now able to turn off validation. I'll attach a sample application that shows how to do that. Don't bother with the exceptions being thrown as that's just because I haven't written any JSPs. I'd appreciate if you could test my patch using your unit tests. (It seems that the Maven Exec Plug-In has a bug concerning the Maven build lifecycle. If you want to execute the sample, you have to run mvn compile exec:java. mvn exec:java leads to a NPE.) Myfaces 1.2 doesn't start without web.xml - Key: MYFACES-1694 URL: https://issues.apache.org/jira/browse/MYFACES-1694 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Affects Versions: 1.2.0 Reporter: Achim Hügen Priority: Minor Attachments: jetty-embedded.zip, MYFACES-1694.patch Myfaces 1.2 fails with one of these messages if no web.xml can be found or no mapping for the FacesServlet is defined: Couldn't find web.xml. Abort initializing MyFaces. No mappings of FacesServlet found. Abort initializing MyFaces. That's a quite strict interpretation of the spec which says 'Implementations may check for the presence of a servlet-class definition of class javax.faces.webapp.FacesServlet in the web application deployment descriptor as a means to abort the configuration process and reduce startup time for applications that do not use JavaServer Faces Technology.' It would be helpful for unit tests if the web.xml and a servlet-mapping is not mandatory (maybe configurable?). In my unit tests I start an embedded jetty server whose configuration is build programmatically: Server jettyServer = new Server(); Context webappContext = new Context(jettyServer, contextPath, Context.SESSIONS); webappContext.addEventListener(new StartupServletContextListener()); ServletHolder facesServletHolder = new ServletHolder(new FacesServlet()); webappContext.addServlet(facesServletHolder, *.faces); webappContext.getServer().start(); That code is working fine with Myfaces 1.1 but broken with 1.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-1694) Myfaces 1.2 doesn't start without web.xml
[ https://issues.apache.org/jira/browse/MYFACES-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519535 ] bhuemer edited comment on MYFACES-1694 at 8/13/07 2:47 PM: --- Currently MyFaces needs the mapping for the FacesServlet because of the url-pattern. MyFaces' ViewHandler calculates view IDs and action URLs based on this url-pattern, but I've attempted a different approach. The parts of the request URI (context path, servlet path and path info) provide more than enough information to calculate view IDs and action URLs. For example, if the path info is not null, the FacesServlet has been definitely mapped using prefix mapping and the servlet path indicates the url-pattern in this case. Additionally, thanks to refactoring of a small amount of code, you're now able to turn off validation. I'll attach a sample application that shows how to do that. Don't bother with the exceptions being thrown as that's just because I haven't written any JSPs. I'd appreciate if you could test my patch using your unit tests. I've already tested my patch using the MyFaces Tomahawk examples. (It seems that the Maven Exec Plug-In has a bug concerning the Maven build lifecycle. If you want to execute the sample, you have to run mvn compile exec:java. mvn exec:java leads to a NPE.) was (Author: bhuemer): Currently MyFaces needs the mapping for the FacesServlet because of the url-pattern. MyFaces' ViewHandler calculates view IDs and action URLs based on this url-pattern, but I've attempted a different approach. The parts of the request URI (context path, servlet path and path info) provide more than enough information to calculate view IDs and action URLs. For example, if the path info is not null, the FacesServlet has been definitely mapped using prefix mapping and the servlet path indicates the url-pattern in this case. Additionally, thanks to refactoring of a small amount of code, you're now able to turn off validation. I'll attach a sample application that shows how to do that. Don't bother with the exceptions being thrown as that's just because I haven't written any JSPs. I'd appreciate if you could test my patch using your unit tests. (It seems that the Maven Exec Plug-In has a bug concerning the Maven build lifecycle. If you want to execute the sample, you have to run mvn compile exec:java. mvn exec:java leads to a NPE.) Myfaces 1.2 doesn't start without web.xml - Key: MYFACES-1694 URL: https://issues.apache.org/jira/browse/MYFACES-1694 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Affects Versions: 1.2.0 Reporter: Achim Hügen Priority: Minor Attachments: jetty-embedded.zip, MYFACES-1694.patch Myfaces 1.2 fails with one of these messages if no web.xml can be found or no mapping for the FacesServlet is defined: Couldn't find web.xml. Abort initializing MyFaces. No mappings of FacesServlet found. Abort initializing MyFaces. That's a quite strict interpretation of the spec which says 'Implementations may check for the presence of a servlet-class definition of class javax.faces.webapp.FacesServlet in the web application deployment descriptor as a means to abort the configuration process and reduce startup time for applications that do not use JavaServer Faces Technology.' It would be helpful for unit tests if the web.xml and a servlet-mapping is not mandatory (maybe configurable?). In my unit tests I start an embedded jetty server whose configuration is build programmatically: Server jettyServer = new Server(); Context webappContext = new Context(jettyServer, contextPath, Context.SESSIONS); webappContext.addEventListener(new StartupServletContextListener()); ServletHolder facesServletHolder = new ServletHolder(new FacesServlet()); webappContext.addServlet(facesServletHolder, *.faces); webappContext.getServer().start(); That code is working fine with Myfaces 1.1 but broken with 1.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1702) Error Handling FileNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519308 ] Bernhard Huemer commented on MYFACES-1702: -- I'm afraid that it doesn't work as it seems that you've mixed up underscore and hyphen. Error Handling FileNotFoundException -- Key: MYFACES-1702 URL: https://issues.apache.org/jira/browse/MYFACES-1702 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Assignee: Martin Marinschek Fix For: 1.2.1-SNAPSHOT Attachments: error-handling-demo.zip This Facelets-Error-Handler works fine when using MyFaces 1.1.6, but a I guess a bug has been introduced while porting this code to MyFaces 1.2.1. Currently, while setting up the HTML code to display the exception a FileNotFoundException will be thrown because of a missing resource: META-INF/rsc/facelet-dev-error.xml. This behaviour is quite reasonable as the directory structure somehow has changed. There is no directory called META-INF (http://svn.apache.org/repos/asf/myfaces/core/branches/1_2_1/api/src/main/resources/). Therefore this bug is quite easy to fix as you just have to fix the directory structure. I'll attach a sample web application reproducing this error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1702) Error Handling FileNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519319 ] Bernhard Huemer commented on MYFACES-1702: -- Now it works like a charm. :-) Error Handling FileNotFoundException -- Key: MYFACES-1702 URL: https://issues.apache.org/jira/browse/MYFACES-1702 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Assignee: Martin Marinschek Fix For: 1.2.1-SNAPSHOT Attachments: error-handling-demo.zip This Facelets-Error-Handler works fine when using MyFaces 1.1.6, but a I guess a bug has been introduced while porting this code to MyFaces 1.2.1. Currently, while setting up the HTML code to display the exception a FileNotFoundException will be thrown because of a missing resource: META-INF/rsc/facelet-dev-error.xml. This behaviour is quite reasonable as the directory structure somehow has changed. There is no directory called META-INF (http://svn.apache.org/repos/asf/myfaces/core/branches/1_2_1/api/src/main/resources/). Therefore this bug is quite easy to fix as you just have to fix the directory structure. I'll attach a sample web application reproducing this error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1703) f:setPropertyActionListener causes wrongful AbortProcessingException
f:setPropertyActionListener causes wrongful AbortProcessingException Key: MYFACES-1703 URL: https://issues.apache.org/jira/browse/MYFACES-1703 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Priority: Critical During the Invoke Application phase, a SetPropertyActionListener always throws an AbortProcessingException claiming that the target has not been set, but that's just because the methode restoreState is incorrectly implemented. It creates a new array rather than cast the given state. I'll attach a sample web application reproducing this error and the corresponding patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1703) f:setPropertyActionListener causes wrongful AbortProcessingException
[ https://issues.apache.org/jira/browse/MYFACES-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Huemer updated MYFACES-1703: - Status: Patch Available (was: Open) f:setPropertyActionListener causes wrongful AbortProcessingException Key: MYFACES-1703 URL: https://issues.apache.org/jira/browse/MYFACES-1703 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Priority: Critical Attachments: demo.zip, MYFACES-1703.patch During the Invoke Application phase a SetPropertyActionListener always throws an AbortProcessingException claiming that the target has not been set, but that's just because the methode restoreState is incorrectly implemented. It creates a new array rather than cast the given state. I'll attach a sample web application reproducing this error and the corresponding patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1702) Error Handling FileNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Huemer updated MYFACES-1702: - Status: Patch Available (was: Open) Error Handling FileNotFoundException -- Key: MYFACES-1702 URL: https://issues.apache.org/jira/browse/MYFACES-1702 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Attachments: error-handling-demo.zip This Facelets-Error-Handler works fine when using MyFaces 1.1.6, but a I guess a bug has been introduced while porting this code to MyFaces 1.2.1. Currently, while setting up the HTML code to display the exception a FileNotFoundException will be thrown because of a missing resource: META-INF/rsc/facelet-dev-error.xml. This behaviour is quite reasonable as the directory structure somehow has changed. There is no directory called META-INF (http://svn.apache.org/repos/asf/myfaces/core/branches/1_2_1/api/src/main/resources/). Therefore this bug is quite easy to fix as you just have to fix the directory structure. I'll attach a sample web application reproducing this error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1702) Error Handling FileNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Huemer updated MYFACES-1702: - Status: Open (was: Patch Available) Error Handling FileNotFoundException -- Key: MYFACES-1702 URL: https://issues.apache.org/jira/browse/MYFACES-1702 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Attachments: error-handling-demo.zip This Facelets-Error-Handler works fine when using MyFaces 1.1.6, but a I guess a bug has been introduced while porting this code to MyFaces 1.2.1. Currently, while setting up the HTML code to display the exception a FileNotFoundException will be thrown because of a missing resource: META-INF/rsc/facelet-dev-error.xml. This behaviour is quite reasonable as the directory structure somehow has changed. There is no directory called META-INF (http://svn.apache.org/repos/asf/myfaces/core/branches/1_2_1/api/src/main/resources/). Therefore this bug is quite easy to fix as you just have to fix the directory structure. I'll attach a sample web application reproducing this error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1702) Error Handling FileNotFoundException
Error Handling FileNotFoundException -- Key: MYFACES-1702 URL: https://issues.apache.org/jira/browse/MYFACES-1702 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.1-SNAPSHOT Reporter: Bernhard Huemer This Facelets-Error-Handler works fine when using MyFaces 1.1.6, but a I guess a bug has been introduced while porting this code to MyFaces 1.2.1. Currently, while setting up the HTML code to display the exception a FileNotFoundException will be thrown because of a missing resource: META-INF/rsc/facelet-dev-error.xml. This behaviour is quite reasonable as the directory structure somehow has changed. There is no directory called META-INF (http://svn.apache.org/repos/asf/myfaces/core/branches/1_2_1/api/src/main/resources/). Therefore this bug is quite easy to fix as you just have to fix the directory structure. I'll attach a sample web application reproducing this error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1670) A dollar-type, 2 level EL expression evaluates to null
[
https://issues.apache.org/jira/browse/MYFACES-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519142
]
Bernhard Huemer commented on MYFACES-1670:
--
The problem is a legacy PropertyResolver being required by the JSF 1.2
specification (org.apache.myfaces.el.DefaultPropertyResolver). This
PropertyResolver just has to call
FacesContext.getCurrentInstance().getELContext().setPropertyResolved(false);
(see JSF 1.2 specification, 5.8.2). However, if the container is evaluating an
expression, it uses its own ELContext implementation (e.g.
org.apache.jasper.el.ELContextImpl).
At the beginning I've said that the problem is the legacy PropertyResolver, but
that's not really the case as its expected behaviour is described in the
specification. Actually, the adapter class making it possible to use
PropertyResolvers in the ELResolver chain is incorrect. Before delegating the
request to the PropertyResolver it assumes that the property will be resolved
and therefore calls context.setPropertyResolved(true);. This behaviour is
also according the specification if I haven't got it wrong (5.6.1.6). If the
PropertyResolver is not able to fulfill the task it just has to call
context.setPropertyResolved(false);, but remember that a PropertyResolver
just knows how to access the FacesELContext.
Therefore the adapter class has to inform its given context whether the
property has been resolved or not according to the FacesELContext. I'll attach
a patch.
A dollar-type, 2 level EL expression evaluates to null
--
Key: MYFACES-1670
URL: https://issues.apache.org/jira/browse/MYFACES-1670
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.1-SNAPSHOT
Environment: geronimo-2.0-M6-rc1
Reporter: Alexander Zynevich
Fix For: 1.2.0-SNAPSHOT
Attachments: Customer.java, CustomerDetailsBean.java, eltest.war,
faces-config.xml, print.jsp, web.xml
I have a simple code where dollar-type expression (like ${}) works
differently than shrap-type expression (like #{}),
I put into the http session a managed bean aggregating another bean.
${parent} is calculated, while ${parent.child} is always null (it is printed
as an empty string and equals to null in when tag).
For example the following snip of JSP code:
f:view
h:form id=myform
bUsing sharp-el/b: br/
*h:outputText id=cll1 value=#{customerDetailsBean} /*br/
*h:outputText id=cll2 value=#{customerDetailsBean.customer} /*br/
bUsing dollar-el/b: br/
*${customerDetailsBean}*br/
*${customerDetailsBean.customer}*br/
bClassical servlet style/b: br/
*% if (session.getAttribute(customerDetailsBean) != null) {%%=
session.getAttribute(customerDetailsBean) %% } %*br/
*% if (session.getAttribute(customerDetailsBean) != null) {%%=
((eltest.CustomerDetailsBean)session.getAttribute(customerDetailsBean)).getCustomer()
%% } %*br/
/h:form
/f:view
-- PRODUCES --:
Using sharp-el:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
*Customer {frstName: Alex , lastName: Zynevich, id: 1979}*
Using dollar-el:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
**
Classical servlet style:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
*Customer {frstName: Alex , lastName: Zynevich, id: 1979}*
while I would expect:
Using sharp-el:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
*Customer {frstName: Alex , lastName: Zynevich, id: 1979}*
Using dollar-el:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
*Customer {frstName: Alex , lastName: Zynevich, id: 1979}*
Classical servlet style:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
*Customer {frstName: Alex , lastName: Zynevich, id: 1979}*
you may find the maven project at
https://issues.apache.org/jira/browse/GERONIMO-3253, war is attached
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1670) A dollar-type, 2 level EL expression evaluates to null
[
https://issues.apache.org/jira/browse/MYFACES-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated MYFACES-1670:
-
Status: Patch Available (was: Open)
A dollar-type, 2 level EL expression evaluates to null
--
Key: MYFACES-1670
URL: https://issues.apache.org/jira/browse/MYFACES-1670
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.1-SNAPSHOT
Environment: geronimo-2.0-M6-rc1
Reporter: Alexander Zynevich
Fix For: 1.2.0-SNAPSHOT
Attachments: Customer.java, CustomerDetailsBean.java, eltest.war,
faces-config.xml, MYFACES-1670.patch, print.jsp, web.xml
I have a simple code where dollar-type expression (like ${}) works
differently than shrap-type expression (like #{}),
I put into the http session a managed bean aggregating another bean.
${parent} is calculated, while ${parent.child} is always null (it is printed
as an empty string and equals to null in when tag).
For example the following snip of JSP code:
f:view
h:form id=myform
bUsing sharp-el/b: br/
*h:outputText id=cll1 value=#{customerDetailsBean} /*br/
*h:outputText id=cll2 value=#{customerDetailsBean.customer} /*br/
bUsing dollar-el/b: br/
*${customerDetailsBean}*br/
*${customerDetailsBean.customer}*br/
bClassical servlet style/b: br/
*% if (session.getAttribute(customerDetailsBean) != null) {%%=
session.getAttribute(customerDetailsBean) %% } %*br/
*% if (session.getAttribute(customerDetailsBean) != null) {%%=
((eltest.CustomerDetailsBean)session.getAttribute(customerDetailsBean)).getCustomer()
%% } %*br/
/h:form
/f:view
-- PRODUCES --:
Using sharp-el:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
*Customer {frstName: Alex , lastName: Zynevich, id: 1979}*
Using dollar-el:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
**
Classical servlet style:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
*Customer {frstName: Alex , lastName: Zynevich, id: 1979}*
while I would expect:
Using sharp-el:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
*Customer {frstName: Alex , lastName: Zynevich, id: 1979}*
Using dollar-el:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
*Customer {frstName: Alex , lastName: Zynevich, id: 1979}*
Classical servlet style:
*CustomerDetailsBean: { customer: Customer {frstName: Alex , lastName:
Zynevich, id: 1979}}*
*Customer {frstName: Alex , lastName: Zynevich, id: 1979}*
you may find the maven project at
https://issues.apache.org/jira/browse/GERONIMO-3253, war is attached
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1697) Immediate EL expressions not resolved correctly
[
https://issues.apache.org/jira/browse/MYFACES-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519154
]
Bernhard Huemer commented on MYFACES-1697:
--
If I only had taken a look at this issue a few hours earlier, resolving this
issue would have been a lot easier. However, this bug seems to be a duplicate
of https://issues.apache.org/jira/browse/MYFACES-1670.
Immediate EL expressions not resolved correctly
---
Key: MYFACES-1697
URL: https://issues.apache.org/jira/browse/MYFACES-1697
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0
Environment: This is happening to me on a project that uses MyFaces
1.2.0, Servlets API 2.5, Tiles 2.0.4, Hibernate 3.2.0, Tomcat 6. I have only
recently upgraded to MyFaces 1.2.0 and the new Servlep API. OS is Windows.
Reporter: Paul Dermody
Recently I tried to start using immediate JSP EL expressions but I am getting
an odd behaviour which I would like to know if anyone else has seen.
In my mfaces-config.xml I have the following Managed bean defined:
managed-bean
managed-bean-namemyDate/managed-bean-name
managed-bean-classjava.util.Date/managed-bean-class
managed-bean-scopesession/managed-bean-scope
/managed-bean
I have a JSP that contains the following:
f:view
h:panelGrid columns=1
h:outputText value=myDate=#{myDate} /
h:outputText value=myDate.time=#{myDate.time} /
f:verbatim
myDate = ${myDate}br
myDate.time = ${myDate.time}
/f:verbatim
/h:panelGrid
/f:view
The output I am getting for this code is as follows:
myDate=Fri Aug 03 11:52:31 CST 2007
myDate.time=1186163551316
myDate = Fri Aug 03 11:52:31 CST 2007
myDate.time =
This behaviour is clearly wrong. For some reason the immediate EL expression
is not resolving the time property correctly.
I debugged this in Eclipse and I found that the time segment of the EL
expression is being resolved to 'null' via a sequence of calls that
eventually leads to the following stack trace:
date.jsp line: 10
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(String,
Class, javax.servlet.jsp.PageContext,
org.apache.jasper.runtime.ProtectedFunctionMapper, boolean) line: 923
org.apache.el.ValueExpressionImpl.getValue(javax.el.ELContext) line: 186
org.apache.el.parser.AstValue.getValue(org.apache.el.lang.EvaluationContext)
line: 97
javax.el.CompositeELResolver.getValue( javax.el.ELContext, Object,
Object) line: 53
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(javax.el.ELContext,
Object, Object) line: 104
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke
(org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.ResolverInvokerT)
line: 148
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$4.invoke()
line: 108
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$301
(org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver,
javax.el.ELContext, Object, Object) line: 46
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver(javax.el.CompositeELResolver).getValue(
javax.el.ELContext, Object, Object) line: 53
org.apache.myfaces.el.convert.PropertyResolverToELResolver.getValue(javax.el.ELContext,
Object, Object) line: 106
org.apache.myfaces.el.convert.PropertyResolverToELResolver.invoke
(javax.el.ELContext, Object, Object,
org.apache.myfaces.el.convert.PropertyResolverToELResolver.ResolverInvokerT)
line: 193
org.apache.myfaces.el.convert.PropertyResolverToELResolver$3.invoke(Object,
Object) line: 115
org.apache.myfaces.el.DefaultPropertyResolver.getValue(Object, Object)
line: 64
The source of the deepest function is as follows:
public Object getValue(Object base, Object property) throws
EvaluationException, PropertyNotFoundException
{
updatePropertyResolved();
return null;
}
The updatePropertyResolved() function looks like this:
private void updatePropertyResolved()
{
FacesContext.getCurrentInstance().getELContext().setPropertyResolved(false);
}
This function is setting the propertyResolved flag to false in the current
ELContext. This is necessary since the propertyResolved flag is set to true
before every call to each resolver. The current ELContext is of type
org.apache.myfaces.el.unified.FacesELContext and eclipse says it's id is 313.
However, when I look further up the stack it turns out that the
FacesCompositeELResolver checks to see if the time
[jira] Created: (MYFACES-1701) The state gets reconstructed twice.
The state gets reconstructed twice.
---
Key: MYFACES-1701
URL: https://issues.apache.org/jira/browse/MYFACES-1701
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.1-SNAPSHOT
Reporter: Bernhard Huemer
As the topic suggests, the state gets reconstructed twice during the Restore
View phase. State reconstruction consists of decoding, decrypting and
decompressing (assuming that MyFaces has been configured to do so) the given
state (i.e. the javax.faces.ViewState request parameter) so it shouldn't be
done more often than necessary. For a better understanding of this issue, I'll
describe the call hierarchy (simplified):
///
//
myfaces/core/branches/1_2_1/impl/org/apache/myfaces/application/jsp/JspStateManagerImpl.java
public UIViewRoot restoreView(FacesContext context, String viewId, String
renderKitId) {
...
if (isSavingStateInClient(context)) {
...
state = responseStateManager.getState(context, viewId);
}
...
}
// myfaces/core/branches/1_2_1/api/javax/faces/render/ResponseStateManager.java
public Object getState(FacesContext context, String viewId) {
Object[] structureAndState = new Object[2];
structureAndState[0] = getTreeStructureToRestore(context, viewId);
structureAndState[1] = getComponentStateToRestore(context);
return structureAndState;
}
//
myfaces/core/branches/1_2_1/impl/org/apache/myfaces/renderkit/html/HtmlResponseStateManager.java
public Object getTreeStructureToRestore(FacesContext facesContext, String
viewId) {
...
Object encodedState = requestParameterMap.get(javax.faces.ViewState);
Object[] savedState = (Object[]) StateUtils.reconstruct((String)
encodedState, ...);
...
return savedState[TREE_PARAM];
}
public Object getComponentStateToRestore(FacesContext facesContext) {
...
Object encodedState = requestParameterMap.get(javax.faces.ViewState);
Object[] savedState = (Object[]) StateUtils.reconstruct((String)
encodedState, ...);
...
return savedState[STATE_PARAM];
}
\\\
One possible solution (without breaking backward compatibility) is to override
javax.faces.render.ResponseStateManager#getState(FacesContext, String) and
that's exactly what I've done. I've tested my patch with the MyFaces Tomahawk
examples on my notebook (Ubuntu 7.04, AMD Turion 1.80 GHz, 1.5 GB DDR).
Additionally, I'll attach a Apache JMeter test configuration and results of
this test using a local Jetty server. I'd appreciate someone backing up my test
results.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1701) The state gets reconstructed twice.
[
https://issues.apache.org/jira/browse/MYFACES-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated MYFACES-1701:
-
Status: Patch Available (was: Open)
The state gets reconstructed twice.
---
Key: MYFACES-1701
URL: https://issues.apache.org/jira/browse/MYFACES-1701
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.1-SNAPSHOT
Reporter: Bernhard Huemer
Attachments: MYFACES-1701.patch
As the topic suggests, the state gets reconstructed twice during the Restore
View phase. State reconstruction consists of decoding, decrypting and
decompressing (assuming that MyFaces has been configured to do so) the given
state (i.e. the javax.faces.ViewState request parameter) so it shouldn't be
done more often than necessary. For a better understanding of this issue,
I'll describe the call hierarchy (simplified):
///
//
myfaces/core/branches/1_2_1/impl/org/apache/myfaces/application/jsp/JspStateManagerImpl.java
public UIViewRoot restoreView(FacesContext context, String viewId, String
renderKitId) {
...
if (isSavingStateInClient(context)) {
...
state = responseStateManager.getState(context, viewId);
}
...
}
//
myfaces/core/branches/1_2_1/api/javax/faces/render/ResponseStateManager.java
public Object getState(FacesContext context, String viewId) {
Object[] structureAndState = new Object[2];
structureAndState[0] = getTreeStructureToRestore(context, viewId);
structureAndState[1] = getComponentStateToRestore(context);
return structureAndState;
}
//
myfaces/core/branches/1_2_1/impl/org/apache/myfaces/renderkit/html/HtmlResponseStateManager.java
public Object getTreeStructureToRestore(FacesContext facesContext, String
viewId) {
...
Object encodedState = requestParameterMap.get(javax.faces.ViewState);
Object[] savedState = (Object[]) StateUtils.reconstruct((String)
encodedState, ...);
...
return savedState[TREE_PARAM];
}
public Object getComponentStateToRestore(FacesContext facesContext) {
...
Object encodedState = requestParameterMap.get(javax.faces.ViewState);
Object[] savedState = (Object[]) StateUtils.reconstruct((String)
encodedState, ...);
...
return savedState[STATE_PARAM];
}
\\\
One possible solution (without breaking backward compatibility) is to
override javax.faces.render.ResponseStateManager#getState(FacesContext,
String) and that's exactly what I've done. I've tested my patch with the
MyFaces Tomahawk examples on my notebook (Ubuntu 7.04, AMD Turion 1.80 GHz,
1.5 GB DDR). Additionally, I'll attach a Apache JMeter test configuration and
results of this test using a local Jetty server. I'd appreciate someone
backing up my test results.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Testing JSF Application performance with JMeter
Hello,
I would recommend you to use JMeter's proxy [1] to record your test
cases. In doing so, JMeter can record your actions while you browse your
web application with your normal browser [2].
Additionally, if you're using client-side state-saving you have to
configure an XPath Extractor with the following query:
//[EMAIL PROTECTED]'javax.faces.ViewState']/@value
(Moreover I had to use tidy).
Choose a reference name (e.g. state) and ensure that the following
HTTP Request sends this parameter. That is, go through your recorded
test cases and send a javax.faces.ViewState parameter with the value
${state}. The expression depends on the reference name you've chosen.
Furthermore, go through your recorded test cases and ensure that JMeter
encodes the javax.faces.ViewState parameter. It is just a little
checkbox, but I spent a couple of hours finding this. Otherwise MyFaces
can't restore the state because of a javax.crypto.BadPaddingException or
a java.io.StreamCorruptedException.
greets,
Bernhard Huemer
[1]:
http://jakarta.apache.org/jmeter/usermanual/jmeter_proxy_step_by_step.pdf
[2]:
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#HTTP_Proxy_Server
Am Dienstag, den 24.07.2007, 15:03 -0300 schrieb Alixandre Santana:
Hi guys,
Could someone show me how configure a test plan in JMeter in order to
test a JSF
application ?
Actually, which parameters do I have to put in the request in order to
execute a particular method of a JSF bean ?
I want to simulate such execution and just to call the page.jsf with
the request parameters is not enough.
Thanks in advance
Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)
Hello, as far as I know there is no JCP specification using 3 numbers for versioning. Therefore I would assume it's perfectly valid to reserve only the first two numbers for the specification version being implemented. That said, though, decoupling the version number of MyFaces from the version number of the specification seems rather reasonable to me. greetings, Bernhard Huemer On 05/22/07, Paul Spencer [EMAIL PROTECTED] wrote: I am also in agreement with Manfred's opinion. If we tie the MyFaces version number to the spec, what do we do in the following cases: 1) A fix to the spec is release, i.e. 1.2.1? It is very likely that MyFaces releases will be more frequent then spec releases, thus we can be faces with something like MyFaces 1.2.7 implementing spec version 1.2.1. 2) We want top to a major refactoring of MyFaces, similar to Tomcat 5.0 and 5.5? Paul Spencer Martin Marinschek wrote: I've always been of Manfred's opinion - it would be better to decouple spec version numbers from implementation version numbers, so I'm... +1 for MyFaces-Impl 2.0 if we don't do that, we force ourselves into an artifical corset in which we cannot move - we can only increment minor version numbers, and that means that almost no changes have been committed (users would expect only bug-fixes), whereas the implementation could grow in functionality significantly independent from the spec. MyFaces API can stay with a version number of 1.2, though regards, Martin On 5/21/07, Zubin Wadia [EMAIL PROTECTED] wrote: It is a discussion about the core - I am only trying to establish WHY there are two schools of thought on this - refer to Manfred's post to this thread on May 18th. Cheers, Z. On 5/21/07, Mike Kienenberger [EMAIL PROTECTED] wrote: I thought we were simply discussing MyFaces Core. Let me clarify my vote: +1 1.2 MyFaces Core for JSF 1.2. -1 2.0 MyFaces Core for JSF 1.2. Don't care for Tomahawk/Trinidad/Tobago. These are no longer tightly-coupled to a specific MyFaces core release, and should use whatever versions make the most sense. This is already true for shared, Trinidad, and Tobago. It's going to happen anyway for Tomahawk once Myfaces 1.2 becomes trunk since Myfaces 1.1 releases are going to be few and far between once the majority of committers have switched to 1.2. While there have been matching releases for Tomahawk and Core up to this point, this has been due to the elimination of the previous coupling between Core and Tomahawk (a process that was more involved and took longer than anyone expected). For tomahawk, my don't care suggestion for versioning would be to use the same version as shared as long as that makes sense. On 5/21/07, Zubin Wadia [EMAIL PROTECTED] wrote: There will always be an impedence mismatch here because MyFaces no longer represents the Spec but also various component projects. So I see Manfred/Matze's point. This is why I have always advocated letting the Component initiatives reign alone in terms of their version order, release frequency and alignment with MyFaces and/or the Sun RI. And to think that we have the same exposure as the Tomcat community is pushing it. We are nowhere near as big as them - yet. So while they can start naming their releases after varieties of Hibiscus flowers in the future - we can't. I'm still +1 on 1.2. Cheers, Zubin. On 5/21/07, Bruno Aranda [EMAIL PROTECTED] wrote: +1 for 1.2 -1 for 2.0 I do agree that using 2.0 may cause confusion, as unlike what happens with tomcat, there will be a future version 2.0 of the spec when myfaces 2.0 is there already. People, unaware of the versioning procedure of the myfaces project, will go and fetch this version thinking that it is the implementation of jsf 2.0. Cheers, Bruno On 21/05/07, Mike Kienenberger [EMAIL PROTECTED] wrote: +1 for 1.2. -1 for 2.0. I see no advantage to using major version numbers which differ from the spec. I see the disadvantage of confusion. Also, Manfred, you can have a -1 vote on this issue, but not a veto. Vetos only apply to code changes; they do not apply to procedural issues such as software releases. http://www.apache.org/foundation/glossary.html See also http://mail-archives.apache.org/mod_mbox/incubator-general/200606.mbox/[EMAIL PROTECTED] On 5/18/07, Manfred Geiler [EMAIL PROTECTED] wrote: Hi folks, Like Paul Spencer I'm also still +1 for MyFaces 1.x.y -- JSF 1.1 MyFaces 2.x.y -- JSF 1.2 MyFaces 3.x.y -- JSF 2.0 MyFaces 4.x.y -- JSF
[jira] Created: (MYFACES-1618) Redundant method call to String.intern
Redundant method call to String.intern -- Key: MYFACES-1618 URL: https://issues.apache.org/jira/browse/MYFACES-1618 Project: MyFaces Core Issue Type: Improvement Affects Versions: 1.2.0-SNAPSHOT Reporter: Bernhard Huemer Priority: Trivial Each implicit object defines its name by using a interned string literal, such as for example the class ApplicationImplicitObject [1] does. The JLS declares that literals are interned anyway (String objects have a constant value. String literals-or, more generally, strings that are the values of constant expressions (§15.28)-are interned so as to share unique instances, using the method String.intern.) [2] so I think the additional call to intern() is redundant. [1]: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/implicitobject/ApplicationImplicitObject.java?revision=518967view=markup [2]: http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.5 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1619) Abstract away the difference between field- and property-based injection
Abstract away the difference between field- and property-based injection Key: MYFACES-1619 URL: https://issues.apache.org/jira/browse/MYFACES-1619 Project: MyFaces Core Issue Type: Improvement Affects Versions: 1.2.0-SNAPSHOT Reporter: Bernhard Huemer Priority: Trivial Currently the implementation differs between field- and property-based injection both in processing annotations and in invoking the appropriate method to set the value being looked up. Needless to say, this approach causes great redundancy affecting even the latest revision [1]. Both methods should do similar annotation processing but the first one checks for the @Resource annotation twice (due to the delegation to the super class). Therefore I think you should abstract away the difference between field- and property-based injection. [1]: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/config/annotation/AllAnnotationLifecycleProvider.java?revision=518967view=markup -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
