RE: c:set and runtime expressions
Thanks Kris. Very valuable information indeed. I like the filter idea, or as one of the links you listed suggests, a context listener would also do the trick. Personally, I have nothing against reflection, in fact, I think it's one of the greatest features ever, but when it comes to constants, reflection should NOT be needed. So, it's just like doing something extra for no reason. -Original Message- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 04, 2006 4:51 PM To: Tag Libraries Users List Subject: Re: c:set and runtime expressions Tarek Nabil wrote: Thanks a lot Kris for the explanation. Actually, I'm starting to feel that moving to JSTL 1.0 was not such a wise move. There are a lot of things that I used to be able to do with the Struts tag libraries that I can not do with JSTL. One of them is the example I mentioned. Currently, the only work around for me is to do this % Config config = Config.getIntance(); % And then use config in later EL expressions. This is exactly what I don't want to do, but unfortunately, it seems there's no other way around it. If that Config instance is likely to be required for most requests, perhaps you can use a Filter to set the instance as a request attribute. Or, if you're using Struts, have an Action do something similar before forwarding. I'm starting to feel that JSTL has some severe limitations. Even with 1.1, I ran before into the problem of not being able to use constants. Someone on this list kindly suggested the non standard tag library, but the way it works (I guess) is that it uses reflection to expose those static fields as properties, which is a very artificial solution. I mean, why isn't this supported by default? I believe this is a question for the JSR experts to answer. Not sure why you'd characterize reflection that way, it's certainly a naturally occurring part of JavaBeans (not to mention Struts and BeanUtils). In fact, reflection was my approach to this very issue a few years back when using Struts: http://marc.theaimsgroup.com/?l=struts-userm=103790677413408 Similar thread from this group: http://marc.theaimsgroup.com/?l=taglibs-userm=105889207116316 Lots of other ways to approach the problem, but it is recognized as an issue: access to constants http://jsp-spec-public.dev.java.net/issues/show_bug.cgi?id=145 -Original Message- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 5:57 PM To: Tag Libraries Users List Subject: Re: c:set and runtime expressions Tarek Nabil wrote: So that means if I use the RT-based version, then I won't be able to use EL? That's quite strange, because 1.1 could handle both, so it has to be doable. In fact, that's exactly what it means. It's only as of JSP 2.0 that EL evaluation is done by the container. This means that both EL expressions and JSP expressions can be used as RT attribute values. So, JSTL 1.1 isn't really handling anything, it's the JSP 2.0 container. Since JSP 1.2 doesn't do EL evaluation, it's up to a taglib (JSTL 1.0, for example) to do it. That's why the versions of the JSTL 1.0 taglibs that support EL evaluation have attributes with rtexprvalue = false. -Original Message- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 6:26 AM To: Tag Libraries Users List Subject: Re: c:set and runtime expressions If you need to run JSTL 1.0 and want to use JSP expressions as attribute values, you need to use the RT-based versions. For JSTL, there are basically two distinct versions of each taglib: %@ taglib prefix=curi=http://java.sun.com/jstl/core; % %@ taglib prefix=c_rt uri=http://java.sun.com/jstl/core_rt; % If you look at the TLD files for JSTL 1.0, you'll see: c.tld: -- tag nameset/name ... attribute namevalue/name requiredfalse/required rtexprvaluefalse/rtexprvalue /attribute ... /tag c-rt.tld: - tag nameset/name ... attribute namevalue/name requiredfalse/required rtexprvaluetrue/rtexprvalue /attribute ... /tag JSTL 1.0 has to handle EL evaluation on its own (it's integrated into JSP 2.0 so JSTL 1.1 doesn't need to do the evaluation), so you're forced to make a choice between different taglibs that use EL expressions or JSP expressions. Tarek Nabil wrote: Hi everyone, I was using JSTL 1.1 in my application, and then unfortunately, I had to downgrade to 1.0. Now, my IDE is complaining about this line in my JSP c:set var=config value=%= Config.getInstance() %/ It says Attribute value does not accept runtime expressions. This used to work perfectly when I was using 1.1. I tried to look at the changes between 1.1 and 1.0 but I can not see anything related to this issue. Is this really a difference between 1.0 and 1.1 or am I doing something wrong? Thanks in advance
RE: c:set and runtime expressions
Thanks a lot Luca for pointing this out. I must say it's completely new information to me. I wonder if it's really accurate and relevant to all containers. For example, in Oracle Containers for Java (OC4J), when you redeploy an application, the OC4J instance is restarted. You can reload an application without restarting the OC4J instance. Do you think that would make it immune against this kind of problem? I'm also going to the Oracle forums with that question. -Original Message- From: Luca Passani [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 04, 2006 4:57 PM To: Tag Libraries Users List Subject: Re: c:set and runtime expressions only marginally relevant to this thread, I recently read arguments against using Singletons in web apps: http://wiki.apache.org/tomcat/OutOfMemory Luca Tarek Nabil wrote: Thanks a lot Kris for the explanation. Actually, I'm starting to feel that moving to JSTL 1.0 was not such a wise move. There are a lot of things that I used to be able to do with the Struts tag libraries that I can not do with JSTL. One of them is the example I mentioned. Currently, the only work around for me is to do this % Config config = Config.getIntance(); % And then use config in later EL expressions. This is exactly what I don't want to do, but unfortunately, it seems there's no other way around it. I'm starting to feel that JSTL has some severe limitations. Even with 1.1, I ran before into the problem of not being able to use constants. Someone on this list kindly suggested the non standard tag library, but the way it works (I guess) is that it uses reflection to expose those static fields as properties, which is a very artificial solution. I mean, why isn't this supported by default? I believe this is a question for the JSR experts to answer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] DISCLAIMER This email and any files transmitted with it are confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us of the receipt thereof. If you have received this message in error, please notify the sender immediately, and delete this email from your system. Please note that e-mails are susceptible to change.The sender shall not be liable for the improper or incomplete transmission of the information contained in this communication,nor for any delay in its receipt or damage to your system.The sender does not guarantee that this material is free from viruses or any other defects although due care has been taken to minimise the risk. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:set and runtime expressions
Tarek Nabil wrote: Thanks a lot Luca for pointing this out. I must say it's completely new information to me. I wonder if it's really accurate and relevant to all containers. For example, in Oracle Containers for Java (OC4J), when you redeploy an application, the OC4J instance is restarted. You can reload an application without restarting the OC4J instance. Do you think that would make it immune against this kind of problem? I'm also going to the Oracle forums with that question. can you post (or send me off-line) a pointer to your post on the Oracle forum? I am interested in this for a bit of open source that I have released and where I have used a Singleton. If I restart the application, it takes increasingly more time for the app-server to recover each time the Singleton is rebuilt. This is a problem I want to fix for the first release. Luca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:set and runtime expressions
The implication that the example singleton class causes a memory leak just because ...it creates a hard reference to a class instance into the class itself is hard to believe. There are plenty of other ways to pin classes loaded by the web app's class loader, but the singleton pattern isn't one of them. One common way to pin classes is through the JavaBeans Introspector. Since the Introspector caches information about the classes it processes, those references will keep the web app's class loader from becoming eligible for collection. If you're using a container that doesn't take this into account, the common solution is to create a ServletContextListener that calls Introspector.flushCaches in its contextDestroyed method. If your singleton is really causing a performance issue, there's probably something else going on. If it's released open source, you might want to post a link to the code so someone can take a look at it. Luca Passani wrote: Tarek Nabil wrote: Thanks a lot Luca for pointing this out. I must say it's completely new information to me. I wonder if it's really accurate and relevant to all containers. For example, in Oracle Containers for Java (OC4J), when you redeploy an application, the OC4J instance is restarted. You can reload an application without restarting the OC4J instance. Do you think that would make it immune against this kind of problem? I'm also going to the Oracle forums with that question. can you post (or send me off-line) a pointer to your post on the Oracle forum? I am interested in this for a bit of open source that I have released and where I have used a Singleton. If I restart the application, it takes increasingly more time for the app-server to recover each time the Singleton is rebuilt. This is a problem I want to fix for the first release. Luca -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
