4 Replies Latest reply on Jan 30, 2010 8:13 PM by Pete Muir

    WELD-000019 Error destroying an instance

    Dave Halliday Newbie

      I'm using Weld with GlassFish v3.  I'm getting the follow error in the logs:

      SEVERE: WELD-000019 Error destroying an instance org.jboss.weld.bean...(name of my class)

      I'm new to Weld.  How do I go about diagnosing this?  There is no stacktrace in the logs.  Can I turn on a debug mode or something to get more information?  Is there documentation for the error code?  I couldn't find any.



        • 1. Re: WELD-000019 Error destroying an instance
          Pete Muir Master

          No documentation yet, that is still in the works. You'll need to figure out how to get the exception out of GlassFish (it's logged at debug level, we need to add that to the message...)

          • 2. Re: WELD-000019 Error destroying an instance
            Dave Halliday Newbie

            Thanks for the reply.  I set the logging to FINE on GlassFish and got the following stacktrace.  Looks like it's being thrown from GlassFish code, not Weld.  Maybe I need a @Disposes method to close the EntityManager that I injected?

                    at com.sun.enterprise.container.common.impl.EntityManagerWrapper.close(EntityManagerWrapper.java:826)
                    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                    at java.lang.reflect.Method.invoke(Method.java:597)
                    at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:46)
                    at javax.persistence.EntityManager_$$_javassist_62.close(EntityManager_$$_javassist_62.java)
                    at org.jboss.weld.bean.builtin.ee.PersistenceContextProducerField.defaultDispose(PersistenceContextProducerField.java:58)
                    at org.jboss.weld.bean.builtin.ee.PersistenceContextProducerField.defaultDispose(PersistenceContextProducerField.java:29)
                    at org.jboss.weld.bean.ProducerField$1.dispose(ProducerField.java:88)
                    at org.jboss.weld.bean.ProducerField.destroy(ProducerField.java:113)
                    at org.jboss.weld.context.ForwardingContextual.destroy(ForwardingContextual.java:18)
                    at org.jboss.weld.context.DependentInstancesStore.destroy(DependentInstancesStore.java:79)
                    at org.jboss.weld.context.DependentInstancesStore.destroyDependentInstances(DependentInstancesStore.java:73)
                    at org.jboss.weld.context.CreationalContextImpl.release(CreationalContextImpl.java:79)
                    at org.jboss.weld.bean.ManagedBean.destroy(ManagedBean.java:181)

            • 3. Re: WELD-000019 Error destroying an instance
              Dave Halliday Newbie

              The GlassFish code that gets called by Weld looks like this:

                  public void close() {
                      Agent callFlowAgent = Switch.getSwitch().getCallFlowAgent();
                      if(callFlowAgent.isEnabled()) {
                      // close() not allowed on container-managed EMs.
                      throw new IllegalStateException();

              Seems like Weld should not be calling close() on the EntityManager?  I added a do nothing @Disposes method and that suppresses the error. 

              public class MyDatabase {
                  @PersistenceContext(unitName = "myPU")
                  private EntityManager em;
                  public EntityManager getEm() {
                      return em;
                  public void doNothing(@Disposes EntityManager em) {
                      // don't call close

              I'm still not clear if this a problem with how I'm using EntityManagers or if Weld is doing the wrong thing in this case.  Any insight?

              • 4. Re: WELD-000019 Error destroying an instance
                Pete Muir Master

                Yup, well known issue in 1.0.0, fixed in 1.0.1 which I just pushed to Maven, and hopefully GlassFish will pick up soon.