So is there a workaround for this annoyance? Btw I set
ear-subdeployments-isolated to false, so if that can be the cause for
that it would be nice to know. Not that I would want to set it to true,
but I am just curious about what effect the isolated classloading would
have on the DS when put into EAR/lib. Would the classloading still work
properly?
Have you looked at my code regarding MessageBundle? I think that there
is something wrong. When the bean is @ApplicationScoped there should be
only one call to BeanLifecycle.create(Bean<T>, CreationalContext<T>) right?
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 10.05.2013 23:26, schrieb Christian Kaltepoth:
Hey,
actually I was thinking about whether it would be a good idea to completely
remove this BeanManagerProvider warning. I doubt that it is very useful. It
seems to be caused by the fact that AS7 sends the extension events with a
different context classloader in EAR deployments. I'm note sure if this is
a AS7 bug or not, but it seems like many uses are affected by this log
flooding although the BeanManagerProvider works fine.
Christian
2013/5/10 Christian Beikov <christian.bei...@gmail.com>
Hey there,
a quick question again. I am facing a problem regarding
BeanManagerProvider when deploying my app as EAR with two WARs. The
BeanManagerInfo.booted flag seems to be false and therefore it prints like
200 Messages per HTTP Request into my log file.
Deltaspike API and Impl are both in EAR/lib. I am using 0.3-incubating.
Furthermore I use JBoss AS 7.1.0.Final which comes with Weld 1.1.5 AFAIK.
I found two main places where the BeanManagerProvider was excessively
requested.
One of these places is the constructor of my custom
javax.faces.context.**ExceptionHandler.
Is it a good idea to cache the ExceptionHandler instance in the
javax.faces.context.**ExceptionHandlerFactory? If it was, that would at
least reduce the messages a bit for now.
The second place I found to be a heavy user of the
BeanManagerProvider.**getInstance()
method is in a custom BeanLifcycle class for the MessageBundle beans. The
code there is mostly from PartialBeanLifecycle(the method which is calling
the getInstance() method so often is the createHandlerInstance() method). I
only removed some lines that handeled abstract classes etc. It seems that
although I defined the Bean to be @ApplicationScoped, it gets created on
every access. Maybe I did something wrong in there too?
Can anyone help me please? Also see the code I use for the MessageBundle
stuff.
MessageBundleBeanLifecycle - http://pastebin.com/4g8HyPqG
MessageBundleExtension - http://pastebin.com/Gg48VmaZ
MessageBundleInvocationHandler - http://pastebin.com/X6eP0FkG
CoreConfigSource - http://pastebin.com/utW2CFka
CoreClassDeactivator - http://pastebin.com/C11Pu9L1
Finally the @ApplicationScoped and @Named MessageBundle I use -
http://pastebin.com/D2kxNmiR
Thanks in advance!
--
Mit freundlichen Grüßen,
------------------------------**------------------------------**
------------
*Christian Beikov*
