tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pid *" <...@pidster.com>
Subject Re: Standard Jar Scanner Conflict with TLD Config
Date Fri, 25 Nov 2011 08:40:42 GMT
On 25 Nov 2011, at 03:07, Chatree Srichart <chatree.srichart@gmail.com> wrote:

> On Fri, Nov 25, 2011 at 4:48 AM, Rainer Jung <rainer.jung@kippdata.de>wrote:
>
>> On 23.11.2011 22:59, Mark Thomas wrote:
>>
>>> On 23/11/2011 09:52, Chatree Srichart wrote:
>>>
>>>> Hi community.
>>>>
>>>> I got a problem when I start my own embedded Tomcat server with a lot of
>>>> JAR files in classpath.
>>>>
>>>
>> Really in classpath used by the system loader? Or do you simply mean using
>> many JAR files (in WEB-INF/lib)?
>>
> I means classpath outside WEB-INF/lib directory.
>
>>
>> Do you have multiple webapps deployed in the same Tomcat instance? Does
>> the problem also happen when only one webapp is deployed?
>>
> Yes, I do. I have multiple webapps deployed in the same Tomcat instance.
>
>>
>> Finally: which version of Tomcat do you use?
>
> I use 7.0.22 vesion but the problem rise with the trunk version as well.
>
> Actually I am upgrading Apache OFBiz http://ofbiz.apache.org/ . I saw it is
> not a Tomcat problem but it is a tread problem in Apache OFBiz. I have
> already created an Jira issue for OFBiz
> https://issues.apache.org/jira/browse/OFBIZ-4591 .
> First I create a list of Callable object which it will create an start an
> instance of StandardContext:
>
> new Callable<Context>() {
>        public Context call() throws ContainerException, LifecycleException
> {
>            StandardContext context = configureContext(engine, host,
> appInfo);
>            context.setParent(host);
>            context.start();
>            return context;
>        }
> };
>
> and use an instance of ScheduledExecutorService submit a particular
> callable instance. For example:
>
> for (Callable callable : callables) {
>    executor.submit(callable);
> }
>
> The problem is:
>
> Context(1)
> Context(2)
> Context(3)
>
> A particular context will read all JAR files from CLASSPATH. The problem
> is, for example, the Context(2) will start to read all JAR files even
> though the Context(1) does not finish its task yet. So the Context (2) will
> not be able to read some JAR file that the Context(1) is reading and causes
> the error.
>
> I was wondering could you please suggest me a solution how to execute the
> contexts respectively.

Do you need to add all of the classes to the parent classloader, or
can you get Tomcat to load them?

I think Tomcat 7.0 will have concurrent Context deployment in the next release.

I'm not sure how that works with respect to the embedded method of
starting Tomcat though.


p



>
>
> Regards,
>
> Chatree Srichart
>
>>
>>
>> I got this error message for some jar files:
>>>>
>>>> java.lang.**IllegalStateException: zip file closed
>>>>    at java.util.zip.ZipFile.**ensureOpen(ZipFile.java:403)
>>>>    at java.util.zip.ZipFile.access$**100(ZipFile.java:29)
>>>>    at java.util.zip.ZipFile$2.**hasMoreElements(ZipFile.java:**303)
>>>>    at java.util.jar.JarFile$1.**hasMoreElements(JarFile.java:**220)
>>>>    at org.apache.tomcat.util.scan.**FileUrlJar.nextEntry(**
>>>> FileUrlJar.java:75)
>>>>    at org.apache.catalina.startup.**TldConfig.tldScanJar(**
>>>> TldConfig.java:482)
>>>>    at org.apache.catalina.startup.**TldConfig.access$100(**
>>>> TldConfig.java:58)
>>>>    at
>>>> org.apache.catalina.startup.**TldConfig$**TldJarScannerCallback.scan(**
>>>> TldConfig.java:276)
>>>>    at
>>>> org.apache.tomcat.util.scan.**StandardJarScanner.process(**
>>>> StandardJarScanner.java:241)
>>>>    at
>>>> org.apache.tomcat.util.scan.**StandardJarScanner.scan(**
>>>> StandardJarScanner.java:204)
>>>>    at org.apache.catalina.startup.**TldConfig.execute(TldConfig.**
>>>> java:250)
>>>>    at
>>>> org.apache.catalina.startup.**TldConfig.lifecycleEvent(**
>>>> TldConfig.java:540)
>>>>    at
>>>> org.apache.catalina.util.**LifecycleSupport.**fireLifecycleEvent(**
>>>> LifecycleSupport.java:119)
>>>>    at
>>>> org.apache.catalina.util.**LifecycleBase.**fireLifecycleEvent(**
>>>> LifecycleBase.java:90)
>>>>    at
>>>> org.apache.catalina.core.**StandardContext.startInternal(**
>>>> StandardContext.java:5041)
>>>>    at org.apache.catalina.util.**LifecycleBase.start(**
>>>> LifecycleBase.java:150)
>>>>    at
>>>> org.apache.catalina.core.**ContainerBase.**addChildInternal(**
>>>> ContainerBase.java:844)
>>>>    at
>>>> org.apache.catalina.core.**ContainerBase.addChild(**
>>>> ContainerBase.java:820)
>>>>    at org.apache.catalina.core.**StandardHost.addChild(**
>>>> StandardHost.java:644)
>>>>
>>>>
>>>> I see a conflict in the trunk version (Revision: 1205335) when
>>>> FileUrlJar#nextEntry() method try to call this statement:
>>>>
>>>> FileUrlJar.java:75
>>>> =================
>>>> entries.hasMoreElements()
>>>>
>>>> after TldConfig#tldScanJar() method has been called and the jar has been
>>>> closed:
>>>>
>>>> TldConfig.java:489
>>>> =================
>>>> jar.close();
>>>>
>>>> Let's say the system is trying to use closed JAR file.
>>>> Could you please tell me how to solve or ignore the problem?
>>>>
>>>
>>> That shouldn't happen. The Jar should be opened, scanned and then
>>> closed. If you have a reproducible test case for this issue (which
>>> should be as small and as simple as possible) then please create a
>>> Bugzilla entry for the bug and add the test case.
>>>
>>> Mark
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**org<dev-unsubscribe@tomcat.apache.org>
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message