It happens during init?  Is there any chance you could show me the
relevant stack trace?  That would really help me understand this.

On Mon, Jun 21, 2010 at 7:21 AM, Jason Tesser <jasontes...@gmail.com> wrote:
> OK so a few clarifications
>
> 1. We do init in our own init servlet.  this happens before any web request
> private synchronized static void init(){
>        if(ve != null)
>            return;
>        ve = new VelocityEngine();
>        try{
>            ve.init(SystemProperties.getProperties());
>            dotResourceLoaderClassName =
> SystemProperties.get(SystemProperties.get("resource.loader") +
> ".resource.loader.class");
>            Logger.info(VelocityUtil.class,
> SystemProperties.getProperties().toString());
>        }catch (Exception e) {
>            Logger.error(VelocityUtil.class,e.getMessage(),e);
>        }
>    }
>
> 2. The actual issue is that the init within velocity runtimeservers is
> messed up.  The init method is being run because initialize is set to true
> in that class. It gets a null pointer.  Basically we catch it and make the
> init run again by setting initialized and initializing to false and making
> it run again.
>
> This happens on one server always but our fix makes the server work.  We
> were unable to reproduce this in any other environment.
>
> The environoment is Linux
> /opt/java-dotcms/bin/java -version
> java version "1.5.0_18"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_18-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_18-b02, mixed mode)
>
> We did have another scenario with the issue we reproduced locally but that
> one we fixed by extending rendertool and set the engine.
>
> Thanks,
> Jason Tesser
> dotCMS Lead Development Manager
> 1-305-858-1422
>
>
> On Mon, Jun 21, 2010 at 10:04 AM, Nathan Bubna <nbu...@gmail.com> wrote:
>
>> Hmm.  All you did was add an additional check of a particular
>> subsystem using double-checked locking, and try/catch logging errors.
>> Not an ideal fix.  I would love to know a little more about what
>> exactly you are doing when you get the NPE.  Can i see the relevant
>> portions of the stack trace?
>>
>> Also, barring a fix on our end, my recommended fix would be to just
>> manually call init().  The auto-init feature was only meant as a
>> convenience feature and was never really recommended for advanced
>> users, particularly in single-threaded situations.  For multi-threaded
>> things like webapps, i would always recommend you do your init at app
>> startup (servlet/filter init), and not let it wait until runtime.
>>
>> PS diffs are easier to read when there aren't dozens of useless style
>> tweaks included
>>
>> On Mon, Jun 21, 2010 at 6:50 AM, Jason Tesser <jasontes...@gmail.com>
>> wrote:
>> > Here is the DIFF
>> >
>> > http://pastebin.com/jh13sXgt
>> >
>> > Java 1.5 and 1.6 experienced on Linux server and Local OSX
>> >
>> > It automatically inits I believe.
>> >
>> > Thanks,
>> > Jason Tesser
>> > dotCMS Lead Development Manager
>> > 1-305-858-1422
>> >
>> >
>> > On Mon, Jun 21, 2010 at 9:46 AM, Nathan Bubna <nbu...@gmail.com> wrote:
>> >
>> >> I think the mailing list stripped the diff off.   So, what Java
>> >> version are you using?  Are you manually calling init() or letting
>> >> your Engine instance automatically call it when needed?
>> >>
>> >> On Mon, Jun 21, 2010 at 6:43 AM, Jason Tesser <jasontes...@gmail.com>
>> >> wrote:
>> >> > OK I know 1.6.4 was released but I didn't see anything in it that
>> would
>> >> fix
>> >> > this.
>> >> >
>> >> > We were getting initialized = true in the runtimeservices but the
>> >> parserpool
>> >> > would be null
>> >> >
>> >> > Attached is the diff we used to prevent the issue.  What do you guys
>> >> think?
>> >> >
>> >> > The whole thing seems weird to me as the init is synced.
>> >> >
>> >> > Thanks,
>> >> > Jason Tesser
>> >> > dotCMS Lead Development Manager
>> >> > 1-305-858-1422
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>> >> > For additional commands, e-mail: user-h...@velocity.apache.org
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>> >> For additional commands, e-mail: user-h...@velocity.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: user-h...@velocity.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Reply via email to