FWD » Core Development » Base Language

I think all of the issues have the same cause. Reproduction:
1. Log into admin client.
2. MAJIC -> Printer Maintenance
3. Select a printer and press "Edit Printer".
4. Press "Save".

From server log:

java.lang.NullPointerException
        at com.goldencode.p2j.util.ProcedureManager$ProcedureData.access$400(ProcedureManager.java:2556)
        at com.goldencode.p2j.util.ProcedureManager.thisProcedure(ProcedureManager.java:198)
        at com.goldencode.p2j.persist.BufferManager.scopeFinished(BufferManager.java:693)
        at com.goldencode.p2j.util.TransactionManager.processScopeNotifications(TransactionManager.java:5091)
        at com.goldencode.p2j.util.TransactionManager.popScope(TransactionManager.java:2248)
        at com.goldencode.p2j.main.StandardServer.invoke(StandardServer.java:1396)
        at aero.timco.majic.admin.server.MajicAccounts.printerDbHelper(MajicAccounts.java:2247)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at com.goldencode.p2j.util.MethodInvoker.invoke(MethodInvoker.java:76)
        at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:693)
        at com.goldencode.p2j.net.Conversation.block(Conversation.java:319)
        at com.goldencode.p2j.net.Conversation.run(Conversation.java:163)
        at java.lang.Thread.run(Thread.java:744)

The problem is at ProcedureManager:2177. _thisProcedure() and ProcedureData are null.

ProcedureData pdata = locateProcedure(_thisProcedure());

So we probably need to extend the list of blocks that can be referenced as THIS-PROCEDURE (and create proper CalleeInfo). Or we should skip this kind of processing in admin client. Or create some extra block. Here is the current code that processes THIS-PROCEDURE handle:

public void scopeStart()
{
   BlockType bt = TransactionManager.getBlockType();

   if (bt.equals(BlockType.EXTERNAL_PROC) ||
       bt.equals(BlockType.INTERNAL_PROC) ||
       bt.equals(BlockType.FUNCTION)      ||
       bt.equals(BlockType.TRIGGER))
   {
       // push always before pushing new THIS-PROCEDURE
       CalleeInfoImpl info = calleeInfo.peek();
       info.push();

Top scope for admin client is defined at StandardServer:1253 (standard clients use the same entry point):

// add the topmost scope to the TransactionManager
TransactionManager.pushScope("startup",
                             TransactionManager.NO_TRANSACTION,
                             true,
                             true,
                             false,
                             false);

Stanislav,

Your stacktrace is hiding another NPE, when the scope is initially pushed:

java.lang.NullPointerException
    at com.goldencode.p2j.util.ProcedureManager$ProcedureData.access$900(ProcedureManager.java:2556)
    at com.goldencode.p2j.util.ProcedureManager$WorkArea.scopeStart(ProcedureManager.java:2189)
    at com.goldencode.p2j.util.TransactionManager.processScopeNotifications(TransactionManager.java:5077)
    at com.goldencode.p2j.util.TransactionManager.pushScope(TransactionManager.java:2115)
    at com.goldencode.p2j.util.BlockManager.coreLoop(BlockManager.java:8252)
    at com.goldencode.p2j.util.BlockManager.repeatWorker(BlockManager.java:8183)
    at com.goldencode.p2j.util.BlockManager.repeat(BlockManager.java:1445)
    at aero.timco.majic.admin.server.MajicAccounts.printerDbHelperWorker(MajicAccounts.java:2311)
    at aero.timco.majic.admin.server.MajicAccounts.access$200(MajicAccounts.java:127)
    at aero.timco.majic.admin.server.MajicAccounts$5.execute(MajicAccounts.java:2250)
    at com.goldencode.p2j.main.StandardServer.invoke(StandardServer.java:1272)
    at aero.timco.majic.admin.server.MajicAccounts.printerDbHelper(MajicAccounts.java:2246)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.goldencode.p2j.util.MethodInvoker.invoke(MethodInvoker.java:76)
    at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:693)
    at com.goldencode.p2j.net.Conversation.block(Conversation.java:319)
    at com.goldencode.p2j.net.Conversation.run(Conversation.java:163)
    at java.lang.Thread.run(Thread.java:744)

Try enclosing the body for printerDbHelperWorker (and all other cases, if this works) in a BlockManager.externalProcedure call - this should ensure all the state is pushed properly.

I think all the cases which have this problem are:

checkXtNotes(integer, character, boolean, boolean)
printerDbHelperWorker(TaggedName, int)
functionDbHelperWorker(TaggedName, int)
menuDbHelperWorker(MenuDef, int, String[])

Greg, can we assume that if we are in headless mode (TransactionManager.isHeadless() returns true), we are under linux? This should be OK, as JRE internally uses linux-style paths, and in headless mode there already is no physical terminal, so the OS can't be accessed.

Yes, I think that is fine. We just need to put some clear comments into there to explain why this is being done.

Code Review svl_upd20150114a.zip

I'm fine with this.

Code Review svl_upd20150114b.zip

I'm fine with the external procedure wrapping parts of this.

Eric: please review the query changes.

The query changes are the same that were sent to Scott.

Heh, there is a problem with TransactionManager.isHeadless: normal clients do not start.

java.lang.NullPointerException: Could not resolve the configuration def for 1: class com.goldencode.p2j.ui.WindowConfig
    at com.goldencode.p2j.ui.ConfigManager.duplicate(ConfigManager.java:682)
    at com.goldencode.p2j.ui.ConfigManager.addWidgetConfig(ConfigManager.java:436)
    at com.goldencode.p2j.ui.ConfigManager.addWidgetConfig(ConfigManager.java:406)
    at com.goldencode.p2j.ui.LogicalTerminal.init(LogicalTerminal.java:876)
    at com.goldencode.p2j.security.ContextLocal.initializeValue(ContextLocal.java:551)
    at com.goldencode.p2j.security.ContextLocal.get(ContextLocal.java:394)
    at com.goldencode.p2j.security.ContextLocal.get(ContextLocal.java:352)
    at com.goldencode.p2j.ui.LogicalTerminal.locate(LogicalTerminal.java:8728)
    at com.goldencode.p2j.ui.LogicalTerminal.access$100(LogicalTerminal.java:645)
    at com.goldencode.p2j.ui.LogicalTerminal$3.createScopeable(LogicalTerminal.java:9486)
    at com.goldencode.p2j.util.TransactionManager$ContextContainer.obtain(TransactionManager.java:5753)
    at com.goldencode.p2j.util.TransactionManager.isHeadless(TransactionManager.java:3557)
    at com.goldencode.p2j.util.EnvironmentOps.getOperatingSystem(EnvironmentOps.java:336)
    at com.goldencode.p2j.util.EnvironmentOps.isUnderWindowsFamily(EnvironmentOps.java:403)
    at com.goldencode.p2j.util.ServerPropertiesDaemon.isUnderWindowsFamily(ServerPropertiesDaemon.java:64)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.goldencode.p2j.util.MethodInvoker.invoke(MethodInvoker.java:76)
    at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:693)
    at com.goldencode.p2j.net.Conversation.block(Conversation.java:319)
    at com.goldencode.p2j.net.Conversation.run(Conversation.java:163)
    at java.lang.Thread.run(Thread.java:744)

Looks like with this call is disturbing natural order of loading TransactionManager and LogicalTerminal. Any ideas?

Stanislav Lomany wrote:

Looks like with this call is disturbing natural order of loading TransactionManager and LogicalTerminal. Any ideas?

At the point when the client-side interrogates the server-side via the ServerPropertiesDaemon.isUnderWindowsFamily API call, is too early to initiate the scopeables (TM, LT, etc). Try extracting the code from TM$ContextContainer.obtain which determines the headless state into a worker (TM._isHeadless, package-private) and invoke this from the EnvironmentOps.getOperatingSystem. Idea is, avoid the context-local access.

The TM$ContextContainer.obtain will just call the TM._isHeadless to set the WorkArea.headless field.

Stanislav Lomany wrote:

Fixed getting "headless" attribute.

If this solves the admin client problem without regressions, I'm OK with the changes.

So, should I distribute the P2J update without regression testing and check in MAJIC part into staging branch on devsrv01?

Stanislav Lomany wrote:

So, should I distribute the P2J update without regression testing

Run only the CTRL-C part, to be on the safe-side.

and check in MAJIC part into staging branch on devsrv01?

Yes, these need to be checked into the staging branch on devsrv01.

svl_upd20150115a.zip was committed into bzr rev 10710.
svl_upd20150114b.zip was committed to staging on devsrv01.

MAJIC converted OK. Please review the update so I can distribute it.

Stanislav Lomany wrote:

MAJIC converted OK. Please review the update so I can distribute it.

I'm OK with the change, but you need to add a history entry.