Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
2012/1/10 Konstantin Kolinko : > 2012/1/9 Konstantin Kolinko : 2012/1/7 Rainer Jung : > > Maybe enable the accesslog during testing with test.accesslog=true, so one > can check after the next failure whether the contents agree with your > assumption. Not sure, whether Gump offers access to the access log for > checking. >> >> I updated Gump configuration for tc7 and trunk enabling the access >> log. We will see how it goes with next run. >> > > So Gump runs with access logs. Look for "access_log.-mm-dd" in the > list of files. > > (...) Last run of tomcat-tc7.0.x-test failed with org.apache.catalina.mbeans.TestRegistration.BIO.txt: [[[ Testcase: testMBeanDeregistration took 1.756 sec FAILED Remaining: [Tomcat:type=RequestProcessor,worker="http-bio-127.0.0.1-auto-1",name=HttpRequest1] expected:<0> but was:<1> junit.framework.AssertionFailedError: Remaining: [Tomcat:type=RequestProcessor,worker="http-bio-127.0.0.1-auto-1",name=HttpRequest1] expected:<0> but was:<1> at org.apache.catalina.mbeans.TestRegistration.testMBeanDeregistration(TestRegistration.java:209) ]]] The TestRegistration.BIO test did run from Jan 10, 2012 3:16:55 AM till Jan 10, 2012 3:16:56 AM. There is noting wrong showing in access log: [[[ 127.0.0.1 - - [10/Jan/2012:03:16:50 +] "GET /test/annotatedServlet HTTP/1.1" 200 42 http-bio-127.0.0.1-auto-2-exec-2 2 127.0.0.1 - - [10/Jan/2012:03:16:55 +] "GET / HTTP/1.1" 200 - http-bio-127.0.0.1-auto-1-exec-1 83 127.0.0.1 - - [10/Jan/2012:03:17:02 +] "GET /examples/WEB-INF/doesntexistanywhere HTTP/1.1" 404 960 http-bio-127.0.0.1-auto-1-exec-2 8 ]]] The test that run before it, TestWebappClassLoaderMemoryLeak.BIO is here: [1] http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_file/TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.BIO.txt.html What is suspicious in [1] is this message: [[[ Jan 10, 2012 3:16:56 AM org.apache.catalina.util.LifecycleBase stop INFO: The stop() method was called on component [StandardEngine[Tomcat].StandardHost[localhost].StandardContext[]] after stop() had already been called. The second call will be ignored. ]]] but NIO run of TestWebappClassLoaderMemoryLeak has that message as well, but there were no problems in TestRegistration. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-tc7.0.x-test (in module tomcat-7.0.x) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-tc7.0.x-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property tomcat-dbcp-src.jar. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property tomcat-dbcp.home. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-7.0.x/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 mins 36 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-10012012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-10012012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-10012012-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps -Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-10012012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/ srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-10012012.jar test [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-7.0.x/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/outp ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-util.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-7. 0.x/tomcat-deps/tomcat-dbcp-10012012.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-10012012.jar:
DO NOT REPLY [Bug 52445] New: Methodexpression with arguments fails on nested properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=52445
Bug #: 52445
Summary: Methodexpression with arguments fails on nested
properties
Product: Tomcat 7
Version: 7.0.23
Platform: PC
Status: NEW
Severity: normal
Priority: P2
Component: Servlet & JSP API
AssignedTo: dev@tomcat.apache.org
ReportedBy: bal...@gmail.com
Classification: Unclassified
This is basically an improvement of issue 50449
https://issues.apache.org/bugzilla/show_bug.cgi?id=50449
Invoking a method expression with arguments fails on nested properties. I.e.
#{bean.submit('foo')} works, but #{bean.nested.submit('foo')} does not work.
com.example.Bean:
---
package com.example;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.RequestScoped;
@ManagedBean
@RequestScoped
public class Bean {
public void submit1() {
System.out.println("Submit1 without argument");
}
public void submit1(String argument) {
System.out.println("Submit1 with argument " + argument);
}
public void submit2(String argument) {
System.out.println("Submit2 with argument " + argument);
}
public Bean getNested() {
return new Bean();
}
}
---
test.xhtml
---
http://www.w3.org/1999/xhtml";
xmlns:h="http://java.sun.com/jsf/html";>
Tomcat nested methodexpression test
---
Open the page and invoke the 6 buttons in sequence from top to bottom. The
result is:
---
Submit1 without argument
Submit1 with argument foo
Submit2 with argument bar
Submit1 without argument
Submit1 without argument
Jan 09, 2012 11:21:45 PM com.sun.faces.lifecycle.InvokeApplicationPhase execute
WARNING: #{bean.nested.submit2('bar')}: javax.el.MethodNotFoundException:
/test.xhtml @27,50 action="#{bean.nested.submit2('bar')}": Method not found:
com.example.Bean@4f88bc88.submit2()
javax.faces.FacesException: #{bean.nested.submit2('bar')}:
javax.el.MethodNotFoundException: /test.xhtml @27,50
action="#{bean.nested.submit2('bar')}": Method not found:
com.example.Bean@4f88bc88.submit2()
at
com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:110)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at
com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.faces.el.MethodNotFoundException:
javax.el.MethodNotFoundException: /test.xhtml @27,50
action="#{bean.nested.submit2('bar')}": Method not found:
com.example.Bean@4f88bc88.submit2()
at
javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:92)
at
com.sun.faces.application.ActionListenerImpl.processAction(Ac
Re: problem using default Realm in new unit tests
Konstantin, Thank you for your prompt and helpful response... at least I know I haven't overlooked something simple. With your encouragement, I'm happy to keep "fighting the alligators until I can get back to draining the swamp"! On 10/01/12 02:56, Konstantin Kolinko wrote: 2012/1/9 Brian Burch: On 06/01/12 11:47, Konstantin Kolinko wrote: 2012/1/6 Brian Burch: I am developing some new unit tests to validate SingleSignOn and Authenticator logic. I have used this existing test class as my template: org.apache.catalina.authenticator.TestDigestAuthenticator .. which extends org.apache.catalina.startup.TomcatBaseTest. I noticed that TestDigestAuthenticator sets up its own MapRealm and assigns it to its single Context. I thought this logic was unnecessary, and so my own initial test logic simply used the default RealmBase provided by the underlying Tomcat instance. I add my test user and role to that. It worked fine with my simple cases, however... To test SSO, I need to set up two Contexts under the same Realm. I see the following message in the output log: INFO: The start() method was called on component [Realm[Simple]] after start() had already been called. The second call will be ignored. I know it is an INFO message. I know the second start (and its associated stop) are ignored and therefore are harmless. However, I am reluctant to simply shrug and ignore it. My instincts tell me something isn't right. I have done quite a lot of investigating, but the underlying logic is very hard for me to follow. Here is what I am sure about: 1. The message is ONLY emitted in tests that create two Contexts and each have the same Realm assigned with setRealm. 2. The message is NOT emitted at the time the Contexts are created and defined (servlets, security constraints, etc). 3. The message IS emitted after the Tomcat.start method is called. 4. The message is emitted by one of the two threads which are started on behalf of my two contexts. The messages are issued by the start and stop methods in the abstract class org.apache.catalina.util.LifecycleBase. 5. org.apache.catalina.realm.RealmBase extends org.apache.catalina.util.LifecycleMBeanBase which extends LifecycleBase. My currently unanswered questions are: 1. Is this message normal? (I don't see it when I start multiple contexts under a real tomcat server, but perhaps the logging properties are different). 2. Why isn't the redundant startup of the Realm detected earlier and simply avoided (maybe the Threads are intended to race to be first with startup - but then I think the message should be debug level and not sound so scary). Please don't waste your time investigating this for me. I am only asking the question because I don't want too get side-tracked if one of you already knows the answers to my questions. I'd like to settle the matter quickly and get back to my original task! Thanks for listening, The message is expected. I would say that the configuration is wrong, or at least unusual. If you look at the default server.xml file you will note that the element there belongs to Engine. That is why it is started once. I agree, and this is what the TomcatBaseTest expects. If you "tickle" tomcat with TomcatBaseTest.getTomcatInstance() and then with Tomcat.getDefaultRealm(), a new default RealBase (memory) instance is definitely created. When Contexts are created and their context.xml files are parsed, the Contexts always get distinct new Realm instances. Instead of assigning the same Realm instance to both Contexts you should assign it to an upper container (I have not looked at the API though). Or maybe you can have different Realm instances, but which connect to the same backing storage? When the StandardEngine (extending ContainerBase) thread starts, I would expect percolating getRealm calls (from Context to Host to Engine) to eventually arrive at the already-defined Tomcat default Realm. HOWEVER, StandardEngine overrides the ContainerBase.getRealm method and ensures that an unconfigured JAAS Realm is instantiated as the default for the Context, because it cannot locate its parent (the field is certainly null, not tomcat), so it decides to use this JAAS as the backstop. This looks to me as if some refactoring between tomcat 5 and 6 left the Tomcat default memory realm orphaned from the StandardEngine, which now operates independently and establishes a completely different default realm. Perhaps the right hand no longer knows what the left hand is doing Funny thing is that I googled this: http://tomcat.10.n6.nabble.com/default-realm-set-to-JAASRealm-in-StandardEngine-td2005479.html ... and your name (Konstantin) is all over it! Can you cast you mind back 4 months and try to give me a clue about the history of this change to the logic? My feeling is that we need to stop StandardEngine from unilaterally creating an unconfigured JAAS default Realm... and help the poor thing find its true parent, i.e. tomcat, whic
Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
2012/1/9 Konstantin Kolinko : >>> 2012/1/7 Rainer Jung : Maybe enable the accesslog during testing with test.accesslog=true, so one can check after the next failure whether the contents agree with your assumption. Not sure, whether Gump offers access to the access log for checking. >>> > > I updated Gump configuration for tc7 and trunk enabling the access > log. We will see how it goes with next run. > So Gump runs with access logs. Look for "access_log.-mm-dd" in the list of files. There were no problems in last runs of tomcat-trunk-test and tomcat-tc7.0.x-test. All requests came from 127.0.0.1, except these two ones: [[[ 10.0.0.1 - - [09/Jan/2012:15:34:49 +] "GET / http" 200 44 ajp-bio-127.0.0.1-auto-1-exec-1 76 10.0.0.1 - - [09/Jan/2012:15:34:51 +] "GET / http" 200 44 ajp-bio-127.0.0.1-auto-1-exec-1 0 ]]] They are expected. They come from our org.apache.coyote.ajp.TestAbstractAjpProcessor test. The "10.0.0.1" address in them is fake (it comes from data in AjpMessage). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: unit test debugging under Netbeans
2012/1/5 Konstantin Kolinko :
> 2011/12/30 Brian Burch :
>>>
>>> Formatter is configurable since 7.0.24.
>>
>>
>> Silly me! A ${test.formatter} property is defined immediately after
>> ${test.name}!
The test.formatter configures logging library (or specifically
org.apache.juli.logging.DirectJDKLog) when no logging.properties
configuration is available. That is a different beast.
I was referring to "junit.formatter.type" property.
>> However, the runtests macro assumes I want usefile="true", but
>> that prevents netbeans from intercepting the results.
>
> You can convert usefile flag into a property as well,
>
>
I added the above "junit.formatter.usefile" property in trunk and 7.0.x,
so you may experiment with it.
(Our own advantage from this is that we maybe can configure buildbot
to use this property - If it cannot be configured to publish proper
JUnit reports).
>>
>> I will think about whether I really want both formatters active on the same
>> netbeans test run (as in my current version). If not, I need to work out how
>> to inject a value without the user having to change it in build.properties,
>> where it would affect non-netbeans test runs.
>>
>
> You may look here for an inspiration:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52237
>
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52237] build.xml file improvement to allow not just plaintext junit logs.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52237 --- Comment #3 from Konstantin Kolinko 2012-01-09 19:25:11 UTC --- With r1229314 I added one more configurable property to this: junit.formatter.usefile It will be in 7.0.24 as well. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1229314 - in /tomcat/tc7.0.x/trunk: ./ build.xml webapps/docs/changelog.xml
Author: kkolinko Date: Mon Jan 9 19:22:06 2012 New Revision: 1229314 URL: http://svn.apache.org/viewvc?rev=1229314&view=rev Log: Merged revision 1229307 from tomcat/trunk: Further improve Fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=52237 Make "usefile" flag of junit formatter configurable as well. The default value is "true". Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/build.xml tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Mon Jan 9 19:22:06 2012 @@ -1 +1 @@ -/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096 ,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,1174239,1174322,1174325,1174329-1174330,1174337-1174339,1174343,1174353,1174799,1174882,1174884,1174975,1174983,1175155,1175158,1175167,1175182,1175190,1175201,1175272,1175275,1175283,1175582,1175589-1175590,1175594,1175602,1175613,1175633,1175690,1175713,1175798,1175889,1175896,1175907,1176584,1176590,1176799,1177050,1177060,1177125,1177152,1177160,1177245,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187 381,1187753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1 201931,1202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121,1220293,1220295,1221038,1221842,1222189,101,176,1222300,1222690,1222850,1222852,1222855,1224607,1224617,1224648-1224652,1224657,1224662-1224663,1224682,1224801,1224910,1225000,1225219,1225343,1225465,1225627,1225629,1225634,1226069,1226158-1226159,1226177,1226196,1226214-1226215,1226385,1226394,1226500,1226537-1226538,1226546,1226551,1226975,1228196,1228360,1228376,1228724,1228908,1228918,1228920,1228922,1228929,1228969 +/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,11
svn commit: r1229307 - /tomcat/trunk/build.xml
Author: kkolinko Date: Mon Jan 9 19:17:34 2012 New Revision: 1229307 URL: http://svn.apache.org/viewvc?rev=1229307&view=rev Log: Further improve Fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=52237 Make "usefile" flag of junit formatter configurable as well. The default value is "true". Modified: tomcat/trunk/build.xml Modified: tomcat/trunk/build.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1229307&r1=1229306&r2=1229307&view=diff == --- tomcat/trunk/build.xml (original) +++ tomcat/trunk/build.xml Mon Jan 9 19:17:34 2012 @@ -1067,9 +1067,10 @@ - - - + + + + @@ -1126,7 +1127,9 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: ant build failing: could not find file modules/jdbc-pool/doc/jdbc-pool.xml to copy
Agreed. The file was building.txt not readme sorry, thanks for the tips. So any help on importing the project into eclipse? On Sun, Jan 8, 2012 at 11:09 PM, Konstantin Kolinko wrote: > 2012/1/9 S Ahmed : > > Well the readme said it may fail on mac osx because it tries to write to > > /usr/share/java to store the libraries etc. > > Eh, which readme? > It is a bad idea to let them been written to /usr/share/java. That is > just a default value. > > You should really reconfigure it to use some other place (as > documented in BUILDING.txt). > > You should not run any random things with "sudo", unless you > understand the consequences. > > > > > When I ran ant, the build didn't work, running sudo allowed it continue > > (but from now on running just ant w/o sudo is fine, I guess it was just > > initially to write to that folder). > > > > Anyhow, I'll try the svn then thanks. > > > > On Sun, Jan 8, 2012 at 5:52 PM, Konstantin Kolinko > > wrote: > > > >> 2012/1/9 S Ahmed : > >> > 2. sudo ant > >> > >> Just curious regarding the above command: you do not need root rights > >> to build Tomcat! > >> > >> Actually you should never be using root rights when building, testing > >> and using Tomcat. > >> > >> (The only exception is running it with jsvc service wrapper). > >> > >> http://xkcd.com/149/ > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
DO NOT REPLY [Bug 52444] Classloading-based ServletContainerInitializer @HandlesTypes processing can result in long startup times
https://issues.apache.org/bugzilla/show_bug.cgi?id=52444 Mark Thomas changed: What|Removed |Added Severity|major |enhancement --- Comment #1 from Mark Thomas 2012-01-09 19:01:55 UTC --- No functional bug here, moving to enhancement. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52440] Wrong getValueReference behaviour with Facelets parameter expressions
https://issues.apache.org/bugzilla/show_bug.cgi?id=52440 Konstantin Kolinko changed: What|Removed |Added OS/Version||All --- Comment #1 from Konstantin Kolinko 2012-01-09 18:09:03 UTC --- Can you provide small simple web application that demonstrates the problem? That SimpleNode that you operate on - what is its exact className? (Which one of subclasses of SimpleNode that is?) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: VERIFIED status in Bugzilla (was: [Bug 41697]...)
2012/1/8 : > https://issues.apache.org/bugzilla/show_bug.cgi?id=41697 > > Mark Thomas changed: > > What |Removed |Added > > Status|VERIFIED |CLOSED > > --- Comment #5 from Mark Thomas 2012-01-08 12:55:56 UTC --- > Marked as closed rather than verified since verified indicates an open, > confirmed bug. This will remove this issue from the weekly bug reports. > I think the above quoted comment was just a typo, but it might be better to clarify: VERIFIED means that the *resolution* has been confirmed by OP or by QA person. A "confirmed bug" term just sounds like a synonym for "confirmed problem". It is not what should be meant here. Here are docs: https://issues.apache.org/bugzilla/page.cgi?id=fields.html#status I think there is no much sense in having VERIFIED bugs in our weekly reports, but it is just a reminder that they have to be promoted to CLOSED, like Mark did. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52326] Lower log level for failed class loading
https://issues.apache.org/bugzilla/show_bug.cgi?id=52326 --- Comment #7 from Chris Beams 2012-01-09 17:13:57 UTC --- I just created bug 52444 to capture the request to move away from classloading when processing @HandlesTypes. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52444] New: Classloading-based ServletContainerInitializer @HandlesTypes processing can result in long startup times
https://issues.apache.org/bugzilla/show_bug.cgi?id=52444 Bug #: 52444 Summary: Classloading-based ServletContainerInitializer @HandlesTypes processing can result in long startup times Product: Tomcat 7 Version: unspecified Platform: PC OS/Version: Mac OS X 10.4 Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: cbe...@gmail.com Classification: Unclassified See 52326 for background, noting particularly the following: "As long as SCI processing involves expensive classloading, larger applications will suffer from long startup times and thus be encouraged to "shut off" this functionality via metadata-complete='true'." This issue, then, is intended to address classloading-based approach to @HandlesTypes processing by replacing it with something faster and generally less problematic. ASM would be one way to get it done. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: problem using default Realm in new unit tests
2012/1/9 Brian Burch : > On 06/01/12 11:47, Konstantin Kolinko wrote: >> >> 2012/1/6 Brian Burch: >>> >>> I am developing some new unit tests to validate SingleSignOn and >>> Authenticator logic. I have used this existing test class as my template: >>> >>> org.apache.catalina.authenticator.TestDigestAuthenticator >>> >>> .. which extends org.apache.catalina.startup.TomcatBaseTest. >>> >>> I noticed that TestDigestAuthenticator sets up its own MapRealm and >>> assigns >>> it to its single Context. I thought this logic was unnecessary, and so my >>> own initial test logic simply used the default RealmBase provided by the >>> underlying Tomcat instance. I add my test user and role to that. It >>> worked >>> fine with my simple cases, however... >>> >>> To test SSO, I need to set up two Contexts under the same Realm. I see >>> the >>> following message in the output log: >>> >>> INFO: The start() method was called on component [Realm[Simple]] after >>> start() had already been called. The second call will be ignored. >>> >>> I know it is an INFO message. I know the second start (and its associated >>> stop) are ignored and therefore are harmless. However, I am reluctant to >>> simply shrug and ignore it. My instincts tell me something isn't right. >>> >>> I have done quite a lot of investigating, but the underlying logic is >>> very >>> hard for me to follow. Here is what I am sure about: >>> >>> 1. The message is ONLY emitted in tests that create two Contexts and each >>> have the same Realm assigned with setRealm. >>> >>> 2. The message is NOT emitted at the time the Contexts are created and >>> defined (servlets, security constraints, etc). >>> >>> 3. The message IS emitted after the Tomcat.start method is called. >>> >>> 4. The message is emitted by one of the two threads which are started on >>> behalf of my two contexts. The messages are issued by the start and stop >>> methods in the abstract class org.apache.catalina.util.LifecycleBase. >>> >>> 5. org.apache.catalina.realm.RealmBase extends >>> org.apache.catalina.util.LifecycleMBeanBase which extends LifecycleBase. >>> >>> My currently unanswered questions are: >>> >>> 1. Is this message normal? (I don't see it when I start multiple contexts >>> under a real tomcat server, but perhaps the logging properties are >>> different). >>> >>> 2. Why isn't the redundant startup of the Realm detected earlier and >>> simply >>> avoided (maybe the Threads are intended to race to be first with startup >>> - >>> but then I think the message should be debug level and not sound so >>> scary). >>> >>> >>> Please don't waste your time investigating this for me. I am only asking >>> the >>> question because I don't want too get side-tracked if one of you already >>> knows the answers to my questions. I'd like to settle the matter quickly >>> and >>> get back to my original task! >>> >>> Thanks for listening, >>> >> >> The message is expected. I would say that the configuration is wrong, >> or at least unusual. >> >> If you look at the default server.xml file you will note that the >> element there belongs to Engine. That is why it is started >> once. > > > I agree, and this is what the TomcatBaseTest expects. If you "tickle" tomcat > with TomcatBaseTest.getTomcatInstance() and then with > Tomcat.getDefaultRealm(), a new default RealBase (memory) instance is > definitely created. > > >> When Contexts are created and their context.xml files are parsed, the >> Contexts always get distinct new Realm instances. >> >> Instead of assigning the same Realm instance to both Contexts you >> should assign it to an upper container (I have not looked at the API >> though). Or maybe you can have different Realm instances, but which >> connect to the same backing storage? > > > When the StandardEngine (extending ContainerBase) thread starts, I would > expect percolating getRealm calls (from Context to Host to Engine) to > eventually arrive at the already-defined Tomcat default Realm. HOWEVER, > StandardEngine overrides the ContainerBase.getRealm method and ensures that > an unconfigured JAAS Realm is instantiated as the default for the Context, > because it cannot locate its parent (the field is certainly null, not > tomcat), so it decides to use this JAAS as the backstop. > > This looks to me as if some refactoring between tomcat 5 and 6 left the > Tomcat default memory realm orphaned from the StandardEngine, which now > operates independently and establishes a completely different default realm. > Perhaps the right hand no longer knows what the left hand is doing > > Funny thing is that I googled this: > > http://tomcat.10.n6.nabble.com/default-realm-set-to-JAASRealm-in-StandardEngine-td2005479.html > > ... and your name (Konstantin) is all over it! Can you cast you mind back 4 > months and try to give me a clue about the history of this change to the > logic? > > My feeling is that we need to stop StandardEngine from unilaterally creating > an unconfigured JAAS default Realm.
DO NOT REPLY [Bug 52443] Tomcat#defaultRealm shares Realm instance between web applications, resulting in INFO log message from lifecycle
https://issues.apache.org/bugzilla/show_bug.cgi?id=52443 --- Comment #1 from Konstantin Kolinko 2012-01-09 16:48:29 UTC --- One more: Assigning explicit defaultRealm in Tomcat.addWebapp() prevents us from assign a realm to Engine. Because of the Realm created in addWebapp() the realm in Engine is never used in the new web application. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52443] New: Tomcat#defaultRealm shares Realm instance between web applications, resulting in INFO log message from lifecycle
https://issues.apache.org/bugzilla/show_bug.cgi?id=52443 Bug #: 52443 Summary: Tomcat#defaultRealm shares Realm instance between web applications, resulting in INFO log message from lifecycle Product: Tomcat 7 Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: minor Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: knst.koli...@gmail.com Classification: Unclassified Created attachment 28129 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28129 2012-01-09_trunk_TestTomcat_twoapps.patch Inspired by this thread on dev@: http://tomcat.markmail.org/thread/5qxa7gjsaav4ytcd "problem using default Realm in new unit tests" The problem is the following: 1. Tomcat.getDefaultRealm() is effectively a factory method for some Realm instance. It creates this Realm once and caches it as Tomcat#defaultRealm 2. Tomcat.addWebapp() method calls ctx.setRealm(defaultRealm); for every Context that it creates. Thus the Realm instance is shared between web applications. 3. When Context starts it calls start() method on the realm. When the above method was used to create several web applications then during the start of the second and later ones the following message is logged: 09.01.2012 19:19:29 org.apache.catalina.util.LifecycleBase start INFO: The start() method was called on component [Realm[Simple]] after start() had already been called. The second call will be ignored. To reproduce: 1) Apply attached patch to org.apache.catalina.startup.TestTomcat of trunk. 2) Run the test. 3) See the above "The start() method was called" message in the logs. I think there are several ways to resolve this: a) Do not call start() on the Realm if it is already started, as indicated by Lifecycle.getState() b) Change Tomcat class to do not share the Realm instance between Contexts. b.1) assign it to the Engine, or b.2) create a new instance every time. The a) way may lead to problems when the Context is stopped. It is not clear whether the Realm shall be stopped or not. It it is stopped it will affect another webapp. It may also cause problems with asynchronous start of contexts implemented in 7.0.23+. The b) way is consistent with what happens when server.xml is parsed. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: problem using default Realm in new unit tests
On 06/01/12 11:47, Konstantin Kolinko wrote: 2012/1/6 Brian Burch: I am developing some new unit tests to validate SingleSignOn and Authenticator logic. I have used this existing test class as my template: org.apache.catalina.authenticator.TestDigestAuthenticator .. which extends org.apache.catalina.startup.TomcatBaseTest. I noticed that TestDigestAuthenticator sets up its own MapRealm and assigns it to its single Context. I thought this logic was unnecessary, and so my own initial test logic simply used the default RealmBase provided by the underlying Tomcat instance. I add my test user and role to that. It worked fine with my simple cases, however... To test SSO, I need to set up two Contexts under the same Realm. I see the following message in the output log: INFO: The start() method was called on component [Realm[Simple]] after start() had already been called. The second call will be ignored. I know it is an INFO message. I know the second start (and its associated stop) are ignored and therefore are harmless. However, I am reluctant to simply shrug and ignore it. My instincts tell me something isn't right. I have done quite a lot of investigating, but the underlying logic is very hard for me to follow. Here is what I am sure about: 1. The message is ONLY emitted in tests that create two Contexts and each have the same Realm assigned with setRealm. 2. The message is NOT emitted at the time the Contexts are created and defined (servlets, security constraints, etc). 3. The message IS emitted after the Tomcat.start method is called. 4. The message is emitted by one of the two threads which are started on behalf of my two contexts. The messages are issued by the start and stop methods in the abstract class org.apache.catalina.util.LifecycleBase. 5. org.apache.catalina.realm.RealmBase extends org.apache.catalina.util.LifecycleMBeanBase which extends LifecycleBase. My currently unanswered questions are: 1. Is this message normal? (I don't see it when I start multiple contexts under a real tomcat server, but perhaps the logging properties are different). 2. Why isn't the redundant startup of the Realm detected earlier and simply avoided (maybe the Threads are intended to race to be first with startup - but then I think the message should be debug level and not sound so scary). Please don't waste your time investigating this for me. I am only asking the question because I don't want too get side-tracked if one of you already knows the answers to my questions. I'd like to settle the matter quickly and get back to my original task! Thanks for listening, The message is expected. I would say that the configuration is wrong, or at least unusual. If you look at the default server.xml file you will note that the element there belongs to Engine. That is why it is started once. I agree, and this is what the TomcatBaseTest expects. If you "tickle" tomcat with TomcatBaseTest.getTomcatInstance() and then with Tomcat.getDefaultRealm(), a new default RealBase (memory) instance is definitely created. When Contexts are created and their context.xml files are parsed, the Contexts always get distinct new Realm instances. Instead of assigning the same Realm instance to both Contexts you should assign it to an upper container (I have not looked at the API though). Or maybe you can have different Realm instances, but which connect to the same backing storage? When the StandardEngine (extending ContainerBase) thread starts, I would expect percolating getRealm calls (from Context to Host to Engine) to eventually arrive at the already-defined Tomcat default Realm. HOWEVER, StandardEngine overrides the ContainerBase.getRealm method and ensures that an unconfigured JAAS Realm is instantiated as the default for the Context, because it cannot locate its parent (the field is certainly null, not tomcat), so it decides to use this JAAS as the backstop. This looks to me as if some refactoring between tomcat 5 and 6 left the Tomcat default memory realm orphaned from the StandardEngine, which now operates independently and establishes a completely different default realm. Perhaps the right hand no longer knows what the left hand is doing Funny thing is that I googled this: http://tomcat.10.n6.nabble.com/default-realm-set-to-JAASRealm-in-StandardEngine-td2005479.html ... and your name (Konstantin) is all over it! Can you cast you mind back 4 months and try to give me a clue about the history of this change to the logic? My feeling is that we need to stop StandardEngine from unilaterally creating an unconfigured JAAS default Realm... and help the poor thing find its true parent, i.e. tomcat, which has a perfectly serviceable default memory realm just waiting to be used! (apologies for the mild sarcasm - I can see you are very busy on other issues), Brian - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apac
Re: [VOTE] Release Tomcat 5.5.35 Build
Now finally my vote :) On 06.01.2012 21:19, Jim Jagielski wrote: The builds for Tomcat 5.5.35 are ready for testing and approval. The candidates binaries are available here: http://people.apache.org/~jim/tomcat-5.5/ According to the release process, the 5.5.35 build corresponding to the tag TOMCAT_5_5_35 [1] is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable +++ 1. http://svn.apache.org/viewvc/tomcat/tc5.5.x/tags/TOMCAT_5_5_35/ - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src mostly consistent with svn tag - builds fine - build result looks consistent with binaries - JMX MBeans only expected change is the new maxParameterCount with value 1, so looks OK Build was done using Java 1.4.2_19, OS was Solaris 10 Sparc. - Minor things: - STATUS.txt in svn, but not in src tar and zip (I guess that's expected) - 4 errors in run-tester, same as for 5.5.32-34 (details see below) - Some additional javadoc warnings (same as 5.5.32-34 plus 6 new) but TC 5.5 was never 100% clean for javadoc (details see below) Details for run-tester: [tester] FAIL [GET /tester/ErrorPage08?type=Arithmetic HTTP/1.0] Expected data 'ErrorPage06 PASSED - SERVLET', got data 'ErrorPage06 FAILED - message is not correct' [tester] FAIL [GET /tester/WrappedErrorPage08?type=Arithmetic HTTP/1.0] Expected data 'ErrorPage06 PASSED - SERVLET', got data 'ErrorPage06 FAILED - message is not correct' [tester] FAIL [GET /tester/ErrorPage08?type=Array HTTP/1.0] Expected data 'ErrorPage06 PASSED - JSP', got data 'ErrorPage06 FAILED - message is not correct' [tester] FAIL [GET /tester/WrappedErrorPage08?type=Array HTTP/1.0] Expected data 'ErrorPage06 PASSED - JSP', got data 'ErrorPage06 FAILED - message is not correct' Details for Javadoc: 6 new warnings: .../container/catalina/src/share/org/apache/catalina/connector/Request.java:941: warning - Tag @link: reference not found: Globals.DISPATCHER_TYPE_ATTR .../container/catalina/src/share/org/apache/catalina/connector/Request.java:941: warning - Tag @link: reference not found: Globals.DISPATCHER_REQUEST_PATH_ATTR .../container/catalina/src/share/org/apache/catalina/connector/Request.java:941: warning - Tag @link: reference not found: Globals.CERTIFICATES_ATTR .../container/catalina/src/share/org/apache/catalina/connector/Request.java:941: warning - Tag @link: reference not found: Globals.CIPHER_SUITE_ATTR .../container/catalina/src/share/org/apache/catalina/connector/Request.java:941: warning - Tag @link: reference not found: Globals.KEY_SIZE_ATTR .../container/catalina/src/share/org/apache/catalina/connector/Request.java:941: warning - Tag @link: reference not found: Globals.SSL_SESSION_ID_ATTR 4 old warnings: .../connectors/util/java/org/apache/tomcat/util/http/Cookies.java:566: warning - Tag @link: can't find getTokenEndPosition(byte[], int, int, boolean) in org.apache.tomcat.util.http.Cookies .../container/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java:315: warning - End Delimiter } missing for possible See Tag in comment string: "If the forward to the login page fails and the call .../container/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java:344: warning - End Delimiter } missing for possible See Tag in comment string: "If the forward to the error page fails and the call .../container/catalina/src/share/org/apache/catalina/connector/Request.java:2239: warning - @param argument "session" is not a parameter name. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52440] New: Wrong getValueReference behaviour with Facelets parameter expressions
https://issues.apache.org/bugzilla/show_bug.cgi?id=52440
Bug #: 52440
Summary: Wrong getValueReference behaviour with Facelets
parameter expressions
Product: Tomcat 7
Version: 7.0.22
Platform: PC
Status: NEW
Severity: normal
Priority: P2
Component: Servlet & JSP API
AssignedTo: dev@tomcat.apache.org
ReportedBy: justas.ratkevic...@gmail.com
Classification: Unclassified
ValueExpression method getValueReference should return base object and
property. But it returns null if ValueExpression is Facelets parameter.
Example:
someVar = #{concreteObject.property}
ValueExpression for #{someVar} return null from method getValueReference (guess
because it is simple expression #{someVar}), but logicaly it should return
parent expressions ValueReference (need hierachical ValueReference lookup).
I made workaround with Java Reflect API in my code and it illustrates problem:
ELContext elContext = FacesContext.getCurrentInstance().getELContext();
ValueReference reference = exp.getValueReference(elContext);
if (reference == null && exp instanceof TagValueExpressionUEL) {
ValueExpressionImpl origExp = (ValueExpressionImpl)
((TagValueExpressionUEL) exp).getWrapped();
// TODO: JR: find better way to get base and property. ! Code is not
portable because uses Tomcat EL implementation details. !
Field field = ReflectionUtils.findField(origExp.getClass(),
EL_IMPL_VAR_PROPERTY);
field.setAccessible(true);
VariableMapper varMapper = (VariableMapper) ReflectionUtils.getField(field,
origExp);
field = ReflectionUtils.findField(origExp.getClass(),
EL_IMPL_NODE_PROPERTY);
field.setAccessible(true);
SimpleNode node = (SimpleNode) ReflectionUtils.getField(field, origExp);
if (varMapper != null && node != null) {
ValueExpression parentExp = varMapper.resolveVariable(node.getImage());
if (parentExp != null) {
try {
reference = parentExp.getValueReference(elContext);
if (reference == null) {
reference = getValueReference(parentExp);
}
} catch (PropertyNotFoundException e) {
LOG.warn("Property not found: " + e.getMessage());
}
}
}
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Tomcat 5.5.35 Build
On 01/06/2012 09:19 PM, Jim Jagielski wrote: [X] Stable My tests are passing. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
