Re: Admin application creates duplicate secure attribute in server.xml
Peter, Many thanks for finding and fixing the bug, however we are currently running 5.0.28, and not likely to upgrade until summer. Can you describe enough about the problem that I could track it down and create a local fix / work around until then? Peter Rossbach wrote: Yes the wrong saving SSL Connector is a bug and I fix it for Tomcat 5.5.x. The old StandardServer saving code was strange. The new StoreConfig module has a flexible customizable API to store server.xml and context.xml. You can activate the new saving module with Server ... Listener className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/ /Server This listener register a new MBean with more options to save the tomcat configurations. Give 5.5.9 a try ... :-) Peter Jeffrey Barnett schrieb: Mike, unfortunately I'm only gotten better at restoring server.xml after it has been corrupted. You are the first person from the tomcat-user list to even confirm that the problem exits on other sites.. One consultant I consulted said that they had never heard of the problem, but that we were also the first site he had worked with that actually used the admin function actively, By the way, just for the record, not only the secure attribute, but also the protocol attribute is duplicated, right? And only on the SSL connector. Mike Dippold wrote: I just wanted to check to see if you have figured anything out with the tomcat admin ssl duplicate problem. I have tried it on 5.0.28 and also 5.5.7 and every time I change a datasource or anything else, it corrupts the xml. Thanks, Mike Dippold - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Admin application creates duplicate secure attribute in server.xml
Hello Jeffrey,
I have no time to made a storeconfig backport to the Tomcat 5.0 tree.
Sorry, the 5.0.x is in some places very
unfriendly. When you want a local workaround look inside
StandardServer#storeConnector.
The probleme is the storeAttributes method calls for real Connector and
also for ProtocolHandler
L_1107
---
writer.print(Connector);
storeAttributes(writer, connector);
if (connector instanceof CoyoteConnector) {
ProtocolHandler protocolHandler =
((CoyoteConnector)connector).getProtocolHandler();
storeAttributes(writer, protocolHandler);
}
writer.println();
-
What you need is a frontup merge, defaulthandling and renaming of some
attributes (protocol at ProtocolHandler means sslProtocol at Connector
Element) ?Arggh, ... very bad, but the 5.5.x Connector is complete
rewritten and has a nice storeconfig module to handle some bad cases :-)
Implement a better Connector attribute saving algo, send me the code for
testing
Why you want to wait, Tomat 5.5.9 is really stabler as 5.0.28.
Peter
Jeffrey Barnett schrieb:
Peter,
Many thanks for finding and fixing the bug, however we are currently
running 5.0.28, and not likely to upgrade until summer. Can you
describe enough about the problem that I could track it down and
create a local fix / work around until then?
Peter Rossbach wrote:
Yes the wrong saving SSL Connector is a bug and I fix it for Tomcat
5.5.x.
The old StandardServer saving code was strange. The new StoreConfig
module has
a flexible customizable API to store server.xml and context.xml.
You can activate the new saving module with
Server ...
Listener
className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/
/Server
This listener register a new MBean with more options to save the
tomcat configurations.
Give 5.5.9 a try ... :-)
Peter
Jeffrey Barnett schrieb:
Mike, unfortunately I'm only gotten better at restoring server.xml
after it has been corrupted. You are the first person from the
tomcat-user list to even confirm that the problem exits on other
sites.. One consultant I consulted said that they had never heard of
the problem, but that we were also the first site he had worked with
that actually used the admin function actively, By the way, just
for the record, not only the secure attribute, but also the protocol
attribute is duplicated, right? And only on the SSL connector.
Mike Dippold wrote:
I just wanted to check to see if you have figured anything out with
the tomcat admin ssl duplicate problem. I have tried it on 5.0.28
and also 5.5.7 and every time I change a datasource or anything
else, it corrupts the xml.
Thanks,
Mike Dippold
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Admin application creates duplicate secure attribute in server.xml
Mike, unfortunately I'm only gotten better at restoring server.xml after it has been corrupted. You are the first person from the tomcat-user list to even confirm that the problem exits on other sites.. One consultant I consulted said that they had never heard of the problem, but that we were also the first site he had worked with that actually used the admin function actively, By the way, just for the record, not only the secure attribute, but also the protocol attribute is duplicated, right? And only on the SSL connector. Mike Dippold wrote: I just wanted to check to see if you have figured anything out with the tomcat admin ssl duplicate problem. I have tried it on 5.0.28 and also 5.5.7 and every time I change a datasource or anything else, it corrupts the xml. Thanks, Mike Dippold - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AutoReply: Re: Admin application creates duplicate secure attribute in server.xml
Hello tomcat-user@jakarta.apache.org, This refers to your mail with subject as Re: Admin application creates duplicate secure attribute in server.xml. Thank you for sending your CV and registering with A.S. Consultancy Services. Our team will review your CV and match it against current requirements. If your profile matches with any ongoing opening, we will contact you by telephone / email. We recommend that you update your profile and send us an updated CV whenever your contact details or your career path changes, so that your record is up-to-date with us. Please be assured that your CV will remain confidential with us and we will submit your profile to our clients only after due consultation with you. In case you require any further information please do contact us. with warm regards, Staffing Team A.S. Consultancy Services #1205, 2nd Main, 2nd Cross, Vijayanagar, Bangalore - 560040, India Tele - 91 80 2310 9012, Telefax - 91 80 2330 5364, Email - [EMAIL PROTECTED] URL: www.asconsultancy.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Admin application creates duplicate secure attribute in server.xml
Yes the wrong saving SSL Connector is a bug and I fix it for Tomcat 5.5.x. The old StandardServer saving code was strange. The new StoreConfig module has a flexible customizable API to store server.xml and context.xml. You can activate the new saving module with Server ... Listener className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/ /Server This listener register a new MBean with more options to save the tomcat configurations. Give 5.5.9 a try ... :-) Peter Jeffrey Barnett schrieb: Mike, unfortunately I'm only gotten better at restoring server.xml after it has been corrupted. You are the first person from the tomcat-user list to even confirm that the problem exits on other sites.. One consultant I consulted said that they had never heard of the problem, but that we were also the first site he had worked with that actually used the admin function actively, By the way, just for the record, not only the secure attribute, but also the protocol attribute is duplicated, right? And only on the SSL connector. Mike Dippold wrote: I just wanted to check to see if you have figured anything out with the tomcat admin ssl duplicate problem. I have tried it on 5.0.28 and also 5.5.7 and every time I change a datasource or anything else, it corrupts the xml. Thanks, Mike Dippold - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Admin application creates duplicate secure attribute in server.xml
More info: Apparently the manual change didn't fix things after all. The server starts, and some webapps run, but those using ssl get the following error message: Connection refused when attempting to contact myhost:8443 The full service definition follows: Service name=Catalina Connector acceptCount=100 connectionTimeout=2 disableUploadTimeout=true port=8085 redirectPort=8443 maxSpareThreads=75 maxThreads=150 minSpareThreads=25 /Connector Connector acceptCount=100 disableUploadTimeout=true port=8443 scheme=https secure=true sslProtocol=TLS clientauth=false maxSpareThreads=75 maxThreads=150 minSpareThreads=25 protocol=TLS /Connector Connector port=8009 protocol=AJP/1.3 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler redirectPort=8443 /Connector Engine defaultHost=localhost name=Catalina Host appBase=webapps name=localhost xmlValidation=true Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_log. suffix=.txt timestamp=true/ /Host Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Realm className=org.apache.catalina.realm.UserDatabaseRealm/ /Engine /Service Jeffrey Barnett wrote: We have recently upgraded from Tomcat 4 to Tomcat 5.0.27. Now whenever we use the Admin application to alter webapp context parameters the new server.xml that gets written out contains an extra 'secure=true' attribute at the end of the ssl Connector, which causes the server to fail with a SEVERE: Parse Fatal Error on restart. Removing the extra attribute manually allows the server to be started, but is operationally unacceptable. Where is the extra attribute coming from (is there a template somewhere)? How can we stop this from happening? Why is a new server.xml created at all? (Nothing is changed but the addition of the incorrect attribute) Here is the exception: Jan 29, 2005 7:30:54 AM org.apache.commons.digester.Digester fatalError SEVERE: Parse Fatal Error at line 22 column 221: Attribute secure was already specified for element Connector. org.xml.sax.SAXParseException: Attribute secure was already specified for element Connector. And here is the offending element (second attribute highlighted): Connector acceptCount=100 disableUploadTimeout=true port=8443 scheme=https secure=true sslProtocol=TLS clientauth=false maxSpareThreads=75 maxThreads=150 minSpareThreads=25 protocol=TLS *secure=true* /Connector - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Use of Admin application creates duplicate secure attribute in server.xml
We have recently upgraded from Tomcat 4 to Tomcat 5.0.27. Now whenever we use the Admin application to alter webapp context parameters the new server.xml that gets written out contains an extra 'secure=true' attribute at the end of the ssl Connector, which causes the server to fail with a SEVERE: Parse Fatal Error on restart. Removing the extra attribute manually allows the server to be started, but is operationally unacceptable. Where is the extra attribute coming from (is there a template somewhere)? How can we stop this from happening? Why is a new server.xml created at all? (Nothing is changed but the addition of the incorrect attribute) Here is the exception: Jan 29, 2005 7:30:54 AM org.apache.commons.digester.Digester fatalError SEVERE: Parse Fatal Error at line 22 column 221: Attribute secure was already specified for element Connector. org.xml.sax.SAXParseException: Attribute secure was already specified for element Connector. And here is the offending element (second attribute highlighted): Connector acceptCount=100 disableUploadTimeout=true port=8443 scheme=https secure=true sslProtocol=TLS clientauth=false maxSpareThreads=75 maxThreads=150 minSpareThreads=25 protocol=TLS *secure=true* /Connector - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
