You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2011/11/01 14:30:57 UTC
Tagging 7.0.23
It is that time again. I plan to tag 7.0.23 later today once I have run
the unit tests and the TCKs to check all is well.
If you have anything you want to get into this release, now is the time
to commit it.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by ma...@apache.org.
Konstantin Kolinko <kn...@gmail.com> wrote:
>2011/11/2 Mark Thomas <ma...@apache.org>:
>> On 01/11/2011 22:39, Mark Thomas wrote:
>> My first stab at a patch for this is at [1]. Comments welcome.
>>http://people.apache.org/~markt/patches/2011-11-01-redeploy-trunk-v1.patch
>Quick review - several typos:
>
>mbeans-descriptors.xml:
>- typo "findRedployResources"
>- "Path to the resource, relative to docBase" - It is "either absolute
>or relative to docBase".
>
>docs: s/if is is updated/if it is updated/
I'll get those fixed for the next iteration.
>At first view I was hesitant wrt to new syntax in conf/context.xml
>(s/<WatchedResource>/<ReloadResource>/ but I am starting to like it.
>
>Need to apply and play with it a while.
Fair enough
>I do not see though how it is related to another/main topic of
>http://markmail.org/message/5k4urwimvvmeqees
>that is: if context.xml startup fails somehow the webapp continues
>with the deploying the expanded dir.
>
>I observed it during startup time, not during redeployment:
>
>To reproduce, create conf/Catalina/localhost/host-manager.xml:
Ah. I think I misunderstood what you meant by this in the original message. I can see how this happens. Not sure on how to fix it yet.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/11/2 Mark Thomas <ma...@apache.org>:
> On 01/11/2011 22:39, Mark Thomas wrote:
>> Changes to any context.xml have to trigger a redeploy else they won't
>> take effect as no new Context object will be created.
>
> My first stab at a patch for this is at [1]. Comments welcome.
>
> The one thing I don't like is that a change to conf/context.xml that
> breaks the file effectively kills the instance until the problem is
> fixed and the instance re-started.
>
> Mark
>
> http://people.apache.org/~markt/patches/2011-11-01-redeploy-trunk-v1.patch
>
Quick review - several typos:
mbeans-descriptors.xml:
- typo "findRedployResources"
- "Path to the resource, relative to docBase" - It is "either absolute
or relative to docBase".
docs: s/if is is updated/if it is updated/
At first view I was hesitant wrt to new syntax in conf/context.xml
(s/<WatchedResource>/<ReloadResource>/ but I am starting to like it.
Need to apply and play with it a while.
I do not see though how it is related to another/main topic of
http://markmail.org/message/5k4urwimvvmeqees
that is: if context.xml startup fails somehow the webapp continues
with the deploying the expanded dir.
I observed it during startup time, not during redeployment:
To reproduce, create conf/Catalina/localhost/host-manager.xml:
[[[
<?xml version="1.0" encoding="UTF-8"?>
<Context antiResourceLocking="false" privileged="true" >
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="(" />
</Context>
]]]
The logs below are from several days ago, before the multithreaded
deployment patch was applied. Note that "host-manager" is being
deployed twice.
(There seems to be NamingContextListener throwing exception from the
second deploy, but the app started successfully).
[[[ (...)
27.10.2011 16:29:04 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1977 ms
27.10.2011 16:29:05 org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
27.10.2011 16:29:05 org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/8.0.0-dev
27.10.2011 16:29:05 org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor
(...)\build\conf\Catalina\localhost\host-manager.xml
27.10.2011 16:29:05 org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Context/Valve} Setting property 'allow'
to '(' did not find a matching property.
27.10.2011 16:29:05 org.apache.catalina.core.ContainerBase addChildInternal
SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/host-manager]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:152)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:766)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:638)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:608)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:533)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:446)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1303)
(...)
27.10.2011 16:29:07 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory (...)\build\webapps\host-manager
27.10.2011 16:29:07 org.apache.catalina.core.NamingContextListener
lifecycleEvent
SEVERE: Creation of the naming context failed:
javax.naming.NamingException: Context is read only
27.10.2011 16:29:07 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory (...)\build\webapps\manager
27.10.2011 16:29:07 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory (...)\build\webapps\ROOT
27.10.2011 16:29:07 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-8080"]
27.10.2011 16:29:07 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["ajp-bio-8009"]
27.10.2011 16:29:07 org.apache.catalina.startup.Catalina start
INFO: Server startup in 2962 ms
]]]
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by Mark Thomas <ma...@apache.org>.
On 01/11/2011 22:39, Mark Thomas wrote:
> Changes to any context.xml have to trigger a redeploy else they won't
> take effect as no new Context object will be created.
My first stab at a patch for this is at [1]. Comments welcome.
The one thing I don't like is that a change to conf/context.xml that
breaks the file effectively kills the instance until the problem is
fixed and the instance re-started.
Mark
http://people.apache.org/~markt/patches/2011-11-01-redeploy-trunk-v1.patch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by Mark Thomas <ma...@apache.org>.
On 01/11/2011 22:31, Konstantin Kolinko wrote:
> 2011/11/2 Mark Thomas <ma...@apache.org>:
>> On 01/11/2011 22:01, Konstantin Kolinko wrote:
>>> 2011/11/2 Konstantin Kolinko <kn...@gmail.com>:
>>>> 2011/11/1 Mark Thomas <ma...@apache.org>:
>>>>> My current thinking is to add redeployResoucre and reloadResource to
>>>>> Context and deprecate watchedResource, making it a synonym for
>>>>> reloadResource. Thoughts? (I haven't tested this yet.)
>>>>>
>>>>
>>>> Are you talking about API or about Configuration?
>>>>
>>>> <WatchedResource> in conf/context.xml defaults to WEB-INF/web.xml. It
>>>> is a news for me that it covers context.xml as well.
>>>>
>>>> I think web.xml triggers reload, context.xml triggers redeploy.
>>
>> That is what I expected too but it isn't what happens. See line ~575 in
>> ContextConfig. I've checked the history and it has been that way all the
>> way back to 2004.
>
> Oh, I see. Looking at 5.5
> // Add as watched resource so that cascade reload
> occurs if a default
> // config file is modified/added/removed
>
> I think it talks about the "default" context file that is
> $catalina.base/conf/context.xml. That explains why it says about
> "cascade".
>
> I am OK with that triggering a reload, but as you noted that seems to
> not work as Context is not recreated.
>
> I think webapp's own Context file should be a different beast.
Changes to any context.xml have to trigger a redeploy else they won't
take effect as no new Context object will be created.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/11/2 Mark Thomas <ma...@apache.org>:
> On 01/11/2011 22:01, Konstantin Kolinko wrote:
>> 2011/11/2 Konstantin Kolinko <kn...@gmail.com>:
>>> 2011/11/1 Mark Thomas <ma...@apache.org>:
>>>> My current thinking is to add redeployResoucre and reloadResource to
>>>> Context and deprecate watchedResource, making it a synonym for
>>>> reloadResource. Thoughts? (I haven't tested this yet.)
>>>>
>>>
>>> Are you talking about API or about Configuration?
>>>
>>> <WatchedResource> in conf/context.xml defaults to WEB-INF/web.xml. It
>>> is a news for me that it covers context.xml as well.
>>>
>>> I think web.xml triggers reload, context.xml triggers redeploy.
>
> That is what I expected too but it isn't what happens. See line ~575 in
> ContextConfig. I've checked the history and it has been that way all the
> way back to 2004.
Oh, I see. Looking at 5.5
// Add as watched resource so that cascade reload
occurs if a default
// config file is modified/added/removed
I think it talks about the "default" context file that is
$catalina.base/conf/context.xml. That explains why it says about
"cascade".
I am OK with that triggering a reload, but as you noted that seems to
not work as Context is not recreated.
I think webapp's own Context file should be a different beast.
>
>> Touching webapps/myapp.war also triggers a redeploy and not a reload.
>
> I'm fine with that. An updated WAR may include a new context.xml file.
>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by Mark Thomas <ma...@apache.org>.
On 01/11/2011 22:01, Konstantin Kolinko wrote:
> 2011/11/2 Konstantin Kolinko <kn...@gmail.com>:
>> 2011/11/1 Mark Thomas <ma...@apache.org>:
>>> My current thinking is to add redeployResoucre and reloadResource to
>>> Context and deprecate watchedResource, making it a synonym for
>>> reloadResource. Thoughts? (I haven't tested this yet.)
>>>
>>
>> Are you talking about API or about Configuration?
>>
>> <WatchedResource> in conf/context.xml defaults to WEB-INF/web.xml. It
>> is a news for me that it covers context.xml as well.
>>
>> I think web.xml triggers reload, context.xml triggers redeploy.
That is what I expected too but it isn't what happens. See line ~575 in
ContextConfig. I've checked the history and it has been that way all the
way back to 2004.
> Touching webapps/myapp.war also triggers a redeploy and not a reload.
I'm fine with that. An updated WAR may include a new context.xml file.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/11/2 Konstantin Kolinko <kn...@gmail.com>:
> 2011/11/1 Mark Thomas <ma...@apache.org>:
>> On 01/11/2011 14:16, Konstantin Kolinko wrote:
>>>
>>> 1) Re: http://svn.apache.org/viewvc?view=revision&revision=1195965
>>
>>> Is it possible to throw a runtime exception from parseParameters()
>>> when the limit is reached instead of dropping the parameters, or you
>>> think the API does not allow it?
>>
>> I don't think the API allows it. At least it may give users a nasty
>> surprise.
>>
>
> Well, both surprises (either dropping or throwing) can be nasty. So,
> what to choose...
>
> Reviewing the API I see that getParts()/getPart() is consistent that
> it rethrows the same exception if parsing failed once.
>
> The getParameter()/getParameterValues()/getParameterNames() API does
> not say about throwing an exception, and it raises a question whether
> it shall be thrown the first time only or rethrown consistently.
> Let's go on with dropping.
>
> I think there might be an option, e.g. on a Context to rethrow
> exception, or set a request attribute, if parameters parsing failed.
> That can be deemed a different feature / itch. It may be extended to
> cover some other cases, e.g. '&&' invalid chunk error, or parameters
> dropped during urldecode.
>
> 2011/11/2 Mark Thomas <ma...@apache.org>:
>> On 01/11/2011 19:42, Mark Thomas wrote:
>>> On 01/11/2011 14:16, Konstantin Kolinko wrote:
>>>> 2) http://markmail.org/message/5k4urwimvvmeqees
>>>
>>> I'll see if I can get that fixed too.
>>
>> Hmm. The problem here is that the context.xml files are registered as
>> resources that trigger reload rather than redeploy. As such, any changes
>> to the context.xml files trigger a reload but do not have any affect
>> since the Context object is not re-created.
>>
>> My current thinking is to add redeployResoucre and reloadResource to
>> Context and deprecate watchedResource, making it a synonym for
>> reloadResource. Thoughts? (I haven't tested this yet.)
>>
>
> Are you talking about API or about Configuration?
>
> <WatchedResource> in conf/context.xml defaults to WEB-INF/web.xml. It
> is a news for me that it covers context.xml as well.
>
> I think web.xml triggers reload, context.xml triggers redeploy.
Touching webapps/myapp.war also triggers a redeploy and not a reload.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/11/1 Mark Thomas <ma...@apache.org>:
> On 01/11/2011 14:16, Konstantin Kolinko wrote:
>>
>> 1) Re: http://svn.apache.org/viewvc?view=revision&revision=1195965
>
>> Is it possible to throw a runtime exception from parseParameters()
>> when the limit is reached instead of dropping the parameters, or you
>> think the API does not allow it?
>
> I don't think the API allows it. At least it may give users a nasty
> surprise.
>
Well, both surprises (either dropping or throwing) can be nasty. So,
what to choose...
Reviewing the API I see that getParts()/getPart() is consistent that
it rethrows the same exception if parsing failed once.
The getParameter()/getParameterValues()/getParameterNames() API does
not say about throwing an exception, and it raises a question whether
it shall be thrown the first time only or rethrown consistently.
Let's go on with dropping.
I think there might be an option, e.g. on a Context to rethrow
exception, or set a request attribute, if parameters parsing failed.
That can be deemed a different feature / itch. It may be extended to
cover some other cases, e.g. '&&' invalid chunk error, or parameters
dropped during urldecode.
2011/11/2 Mark Thomas <ma...@apache.org>:
> On 01/11/2011 19:42, Mark Thomas wrote:
>> On 01/11/2011 14:16, Konstantin Kolinko wrote:
>>> 2) http://markmail.org/message/5k4urwimvvmeqees
>>
>> I'll see if I can get that fixed too.
>
> Hmm. The problem here is that the context.xml files are registered as
> resources that trigger reload rather than redeploy. As such, any changes
> to the context.xml files trigger a reload but do not have any affect
> since the Context object is not re-created.
>
> My current thinking is to add redeployResoucre and reloadResource to
> Context and deprecate watchedResource, making it a synonym for
> reloadResource. Thoughts? (I haven't tested this yet.)
>
Are you talking about API or about Configuration?
<WatchedResource> in conf/context.xml defaults to WEB-INF/web.xml. It
is a news for me that it covers context.xml as well.
I think web.xml triggers reload, context.xml triggers redeploy.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by Mark Thomas <ma...@apache.org>.
On 01/11/2011 19:42, Mark Thomas wrote:
> On 01/11/2011 14:16, Konstantin Kolinko wrote:
>> 2) http://markmail.org/message/5k4urwimvvmeqees
>
> I'll see if I can get that fixed too.
Hmm. The problem here is that the context.xml files are registered as
resources that trigger reload rather than redeploy. As such, any changes
to the context.xml files trigger a reload but do not have any affect
since the Context object is not re-created.
My current thinking is to add redeployResoucre and reloadResource to
Context and deprecate watchedResource, making it a synonym for
reloadResource. Thoughts? (I haven't tested this yet.)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by Mark Thomas <ma...@apache.org>.
On 01/11/2011 14:16, Konstantin Kolinko wrote:
> 2011/11/1 Mark Thomas <ma...@apache.org>:
>> It is that time again. I plan to tag 7.0.23 later today once I have run
>> the unit tests and the TCKs to check all is well.
>>
>> If you have anything you want to get into this release, now is the time
>> to commit it.
>
> 1) Re: http://svn.apache.org/viewvc?view=revision&revision=1195965
>
> Applies to AJP as well.
I'll get that fixed before I tag.
> Is it possible to throw a runtime exception from parseParameters()
> when the limit is reached instead of dropping the parameters, or you
> think the API does not allow it?
I don't think the API allows it. At least it may give users a nasty
surprise.
> 2) http://markmail.org/message/5k4urwimvvmeqees
I'll see if I can get that fixed too.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging 7.0.23
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/11/1 Mark Thomas <ma...@apache.org>:
> It is that time again. I plan to tag 7.0.23 later today once I have run
> the unit tests and the TCKs to check all is well.
>
> If you have anything you want to get into this release, now is the time
> to commit it.
1) Re: http://svn.apache.org/viewvc?view=revision&revision=1195965
Applies to AJP as well.
Is it possible to throw a runtime exception from parseParameters()
when the limit is reached instead of dropping the parameters, or you
think the API does not allow it?
2) http://markmail.org/message/5k4urwimvvmeqees
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org