Pojo bean deployment lifecycle is not behaving properly

[saltnlight5]

Hi there,

I tried the POJO bean sample from https://github.com/danbev/migrate/tree/master/mcbeans with "test-jboss-beans.xml" as follow:

<deployment xmlns="urn:jboss:pojo:7.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="urn:jboss:pojo:7.0 jboss-pojo_7_0.xsd">
  <bean name="testBean" class="se.rl.mcbeans.TestBean">
    <install method="start"/>
    <uninstall method="stop"/>
  </bean>
</deployment>

I will paste the bean class for convenient here:

package se.rl.mcbeans;

import org.apache.log4j.Logger;

public class TestBean {

    private Logger log = Logger.getLogger(TestBean.class);

    public TestBean() {
        System.out.println("created TestBean");
    }

    public void start() {
        log.info("start ");
    }

    public void stop() {
        log.info("stop ");
    }
}

When I deploy mcbeans.jar in JBossAS7, it deployed successfully, however, it called the "start" method twice! Is there reason for this behavior? See my log here:

10:25:18,600 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-3) JBAS018567: Deployment "deployment.mcbeans.jar" is using a private module ("org.apache.log4j:main") which may be changed or removed in future versions without notice.
10:25:18,646 INFO  [stdout] (MSC service thread 1-6) created TestBean
10:25:18,662 INFO  [se.rl.mcbeans.TestBean] (MSC service thread 1-6) start
10:25:18,662 INFO  [se.rl.mcbeans.TestBean] (MSC service thread 1-2) start
10:25:18,662 INFO  [org.jboss.as] (MSC service thread 1-7) JBAS015951: Admin console listening on http://127.0.0.1:9990
10:25:18,678 INFO  [org.jboss.as] (MSC service thread 1-7) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 3015ms - Started 153 of 231 services (77 services are passive or on-demand)
10:25:18,787 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "mcbeans.jar"

Also, second problem is that "stop" method seems to only called when I redeploy the "mcbeans.jar" while server is still running ("stop" also got called twice during redeploy btw). However, when I shutdown the server, the "mcbeans.jar" is undeployed, but the "stop" did not get called! See my log here:

10:25:24,802 INFO  [org.jboss.as.osgi] (MSC service thread 1-5) JBAS011942: Stopping OSGi Framework
10:25:24,818 INFO  [org.jboss.as.logging] JBAS011503: Restored bootstrap log handlers
10:25:24,818 INFO  [org.apache.catalina.core.StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
10:25:24,834 INFO  [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying TransactionManagerService
10:25:24,834 INFO  [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping transaction recovery manager
10:25:24,865 INFO  [org.jboss.as.server.deployment] JBAS015877: Stopped deployment mcbeans.jar in 75ms
10:25:24,865 INFO  [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final "Brontes" stopped in 73ms

These behavior is NOT what i am expecting. Has anyone encountered them?

Thanks,

Zemian Deng

Message was edited by: jaikiran pai - Fixed formatting

[alesj]

Hmm, let me see if I can reproduce this ...

[jaikiran]

Just curious, what happens if you remove the explicit mention of "start" as an install method in the .xml? Does start method get called only once?

[saltnlight5]

@Jaikiran,

Hi. Yes, comment out the "install/unistall" methods in xml actuall works as expected, even when I shutdown the server, the stop method gets called once! Which is good.

If start/stop of any beans are default to be invoked by pojo server, then perhaps we should error if user add it explicitly, or at least don't invoke it twice right? So is that still consider a bug or no?

BTW, I much prefer these start/stop methods are explicitly configured than implicitly called automatically.

Thanks,

Zemian Deng

[alesj]

Yes, comment out the "install/unistall" methods in xml actuall works as expected, even when I shutdown the server, the stop method gets called once! Which is good.

OK, as I would be surprised to see start being called, but not stop.

As that is purely MSC behavior, which is heavily tested with all the services we already have.

If start/stop of any beans are default to be invoked by pojo server, then perhaps we should error if user add it explicitly, or at least don't invoke it twice right? So is that still consider a bug or no?

BTW, I much prefer these start/stop methods are explicitly configured than implicitly called automatically.

No, not a bug.

This, afaik, has been default behavior since JBossAS 3.x.

And AS7 POJO subsystem is a port of Microcontainer's POJO behavior, which is (sort of) a port of Microkernel's MBean services.

[saltnlight5]

Alex, Thanks for the info.

So POJO subsystem invoking the start() twice is still expected? I understand default behavior is to call start() once already, but if user decided to explicitly set it as example above, shouldn't it still be only call it once? I am not sure I understand the benefit of calling it twice.

Zemian Deng

[alesj]

Alex, Thanks for the info.

It's Ales, Demian. ;-)

So POJO subsystem invoking the start() twice is still expected? I understand default behavior is to call start() once already, but if user decided to explicitly set it as example above, shouldn't it still be only call it once? I am not sure I understand the benefit of calling it twice.

Well, you need to know your tools, and this tool by default calls "start".

If you also tell it to call it once again, it will do just that.

You can disable the default lifecycle method call -- create, start, stop, destroy.

Maybe a warning is a valid feature, but I'm not yet sold on it.

[saltnlight5]

Oh, sorry for mispelling name Ales.

But my name is "Z"emian, not "D", so I guess we are even now.

Well, you need to know your tools, and this tool by default calls "start".

If you also tell it to call it once again, it will do just that.

Yeah, it's true that I need to know the tool to use it well. And I thank you for clarifying for me.

I am fine if you dont' consider this as bug. As you said it's was designed that way. However as a user, my feedback is that I would prefer a warning instead of invoking it twice on start().

Perhaps it's just my own preference and comfort level of working with POJO container system. I do not like this default behavior. It seem intrusive and I have to constantly worry a method will automatically get called unless I disabled them. The ration of me creating a bean with start() vs just a plain POJO is much smaller, so I rather it be explicit and not want it as default behavior.

Also, this is slightly off the topic, but Spring container behaves much more inline with my expectation. But I like to use JBossAS, and so I tried with Snowdrop integration. However this subsystem also has problem invoking stop() during shutdown.

See https://community.jboss.org/message/750872

[alesj]

But my name is "Z"emian, not "D", so I guess we are even now.

That was on purpose. ;-)

I am fine if you dont' consider this as bug. As you said it's was designed that way. However as a user, my feedback is that I would prefer a warning instead of invoking it twice on start().

Perhaps it's just my own preference and comfort level of working with POJO container system. I do not like this default behavior. It seem intrusive and I have to constantly worry a method will automatically get called unless I disabled them. The ration of me creating a bean with start() vs just a plain POJO is much smaller, so I rather it be explicit and not want it as default behavior.

Imo it's too late to change this now -- as it's been this way for almost 10y.

And I'm sure there are users who want to port their pre-JBossAS7 POJOs to this, w/o the need to add 1M start/stops -- as they expect this to be default.

Otoh, I'm open to patches.

e.g. this might be a switch in POJO subsystem' config -- disable all default lifecycle invocations

Also, this is slightly off the topic, but Spring container behaves much more inline with my expectation. But I like to use JBossAS, and so I tried with Snowdrop integration. However this subsystem also has problem invoking stop() during shutdown.

See https://community.jboss.org/message/750872

Yeah, saw that, but that's a different problem.