On 3/30/2018 11:38 AM, Christopher Schultz wrote: > No. In Java, the "class" is defined by the ClassLoader (which loaded > it) plus the fully-qualified class name. It's entirely possible in
The subtleties of classloader-related problems make my head hurt. :) > If objects a and b were instantiated using different ClassLoaders > (which independently loaded the class). This would only happen if you > did this: > > 1. Copy tomcat-dbcp.jar into your app's WEB-INF/lib directory > 2. Let Tomcat create the DataSource (loaded from its ClassLoader) > 3. Instantiated a new DataSource yourself (loaded from your webapp's > ClassLoader) > > You'd have to take care to build against Tomcat, but deploy without > adding Tomcat JARs to your application. I don't know how much I can influence the deployment process, but if I see any issues, I will discuss it with development. Issues will probably be apparent pretty quickly, though. I am generally aware that it's a bad idea to have the same jar (especially if they're different versions) loaded more than once. Would I be right in thinking that subtle problems will either cause compile errors or throw ClassCastException, with the latter being much more likely? > I would just search Google for "how to use java executor services" or > something similar. Thanks for the tip. > It's more fleshed-out, but I still think it's more code than > necessary. You also have the problem that if you want to shut-down > your application, Tomcat will claim you have a memory leak because > that thread will continue to run during the 5-minute delay. I thought I had ensured that if the runflag goes false, the thread should only run for a maximum of one second before it exits. So I looked over the code again. The runflag is checked on every loop of the 'wait' code, which only sleeps one second. The time required for program flow (if, while, try/catch, calculations, etc) should be too small to worry about. The runflag is also checked on the outer loop. Because I placed the wait at the beginning of the outer loop, the thread will output logs just before it quits. That's easy enough to fix. > The point is, yes: you can do all of this and it will work. But if you > use existing code, you can rely on code that is probably > better-written and maintained (no offense intended) and focus your OWN > code on what you NEED to get done, instead of mixing it all up with > the plumbing of waiting, launching threads, checking for the "done" > flag, etc. If I were doing a complex multi-thread highly concurrent task, I would probably be a lot more concerned about the plumbing I'm using, and looking to let other libraries handle almost everything. This idea's simple. One thread that spits a few log lines every five minutes. I'm occasionally guilty of premature optimization when I come up with a code design... spending hours or days thinking about how to best write some bit of code that makes the whole idea tick. But I *TRY* not to engage in that activity. Sometimes a paper plane can do the job wonderfully, and the super spy jet that's invisible to radar and breaks the sound barrier will take too much time and effort. If you're an aerospace engineer, you might have a different opinion. :) I almost used a ten millisecond value for the Thread.sleep call in the thread's inner loop. But then I thought about the fact that it would run that loop one hundred times more frequently, and decided that a longer sleep value was probably a lot more efficient. Nobody's going to care if they have to wait a few hundred more milliseconds before they get another series of logs. Is that a case of premature optimization? :) I do tend to agree that letting somebody else bash their head against the difficult problems and come up with optimized solutions is a great idea. No reason to re-invent every wheel you need -- third-party dependencies and well-written features built into the language or the core libraries are a lifesaver. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
