Re: [weld-dev] What is the best way to pass cofiguration to CDI bean using Weld?

[Mark Struberg]

you could look at Apache DeltaSpike @Configuration and he whole DS config 
mechanism.
http://deltaspike.apache.org/documentation/configuration.html
It's battle proven and also the origin of microprofile-config and JSR-382.Runs 
on anything EE6 ++, from Java7 to Java10
LieGrue,strub
 

On Tuesday, 3 April 2018, 10:25:38 CEST, Matej Novotny 
 wrote:  
 
 Hi Alex,

Not sure if I get what you need to do, but I'll take a shot at it.
What about using @PostConstruct interceptor, in which you take the injected 
Application bean and use it to set internal state in SomeManagerImpl?
Same could be done directly within constructor (with @Inject annotation) or an 
initializer method.

E.g.

@ApplicationScoped
public class SomeManagerImpl implements SomeManager{} {

 private MyConfiguration config;

 @Inject
 Application app;

 @PostConstruct
 public void doSomeInit() {
  config = app.getConfig(); // get config from Application and appply here
 }
}

If I misunderstood your question, please correct me :)

Matej


- Original Message -
> From: "Alex Sviridov" 
> To: "weld-dev" 
> Sent: Saturday, March 31, 2018 1:07:59 PM
> Subject: [weld-dev] What is the best way to pass cofiguration to CDI bean 
> using Weld?
> 
> Hi all
> 
> Could anyone suggest solution for the following situation.
> Lets suppose we have:
> 
> public interface SomeManager{}
> 
> @ApplicationScoped
> public class SomeManagerImpl implements SomeManager{}
> 
> @ApplicationScoped
> public class Application {} //application entry point
> 
> In Application I need to pass configuration to SomeManagerImpl, but I don't
> want to
> add setConfiguration method to SomeManager interface. What is the best way
> to do it in Weld? Maybe I use some CDI mechanisms, or add extra classes.
> Please, help.
> 
> Best regards, Alex Sviridov
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
  ___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Specializes bean in war causes unsatisfied resolution exception

[Mark Struberg]

I have to correct a few things:

a.) This whole scenario is NOT defined in the CDI specification
b.) This scenario in question is defined by the EE umbrella specification
c.) The behaviour of OWB/TomEE is perfectly fine from an EE umbrella perspective
d.) It also absolutely makes sense
e.) See CDI-129. You did blow a whole into Weld a long time ago, now you have 
to live with it. Otoh that doesn't render the structure and behaviour of EARs 
useless...
f.) OWB doesn't have this problem as the proxy will resolve the correct 
instance for each request. A request to any of the other WARs will use the 
original bean, while a request to the 'special' WAR will use the @Specializes 
class. This is imo also what makes the most sense for users. 
g.) Weld behaviour renders EARs dead and useless. We could go on and remove 
them from the EE specs at all in that case... 
h.) And then I wonder why we have Enterprise EE Servers at all if not even EARs 
work... 
i.) I suggest to seek clarification from Linda and Bill resp the EE umbrella EG.

LieGrue,
strub

> Am 01.12.2016 um 08:57 schrieb Martin Kouba :
> 
> Dne 30.11.2016 v 18:01 Benjamin Confino napsal(a):
>> Thank you for the prompt replies.
>> 
>> In answer to your question. It is UiSnapshotData which gets injected
>> under OWB.
> 
> Ok, thanks. From my point of view this violates the EE class loading rules.
> 
>> 
>> Regards
>> Benjamin
>> 
>> 
>> 
>> From:Martin Kouba 
>> To:Matej Novotny , Benjamin
>> Confino/UK/IBM@IBMGB,
>> Cc:Emily Jiang/UK/IBM@IBMGB, Tom Evans/UK/IBM@IBMGB,
>> weld-dev@lists.jboss.org
>> Date:29/11/2016 07:42
>> Subject:Re: [weld-dev] Specializes bean in war causes
>> unsatisfied resolution exception
>> 
>> 
>> 
>> 
>> Matej is correct. The specializing bean from the war disables the
>> specialized bean from ear/lib. And since the bean from war is not
>> visible to the bean from ear/lib (KinderzuschussKinderServiceImpl) an
>> unsatisfied dependency exists.
>> 
>> By the way, what instance of SnapshotData gets injected into
>> KinderzuschussKinderServiceImpl for OWB? Is it UiSnapshotData from the
>> war/lib?
>> 
>> Martin
>> 
>> Dne 29.11.2016 v 07:06 Matej Novotny napsal(a):
>>> Hello Benjamin
>>> 
>>> Thanks for well written question!
>>> 
 (You can see the application at was_bugs/was_bug22 at master ·
 thikade/was_bugs · GitHub )
>>> 
>>> Thanks! Took a glance and it looks like the infamous EAR visibility issue.
>>> 
 My first thought was that this application should not work
>>> 
>>> I agree with that. Anything located in EAR/lib cannot really "see"
>> into WAR.
>>> Hence the bean with @Specializes (in WAR) will disable the original
>> bean (in EAR/lib) and the injection cannot be performed as
>>> the specialized bean is not visible to the archive in EAR/lib.
>>> 
 I confirmed that this application works fine on OpenWebBeans.
>>> 
>>> The fact that it does NOT work should be in accord with Java EE spec
>> and its visibility restrictions.
>>> Maybe you should be asking OWB guys why does it work at all?
>>> 
>>> I am no EAR expert but I really think this is Java EE spec (not CDI)
>> intended behavior.
>>> 
>>> Matej
>>> 
>>> - Original Message -
 From: "Benjamin Confino" 
 To: weld-dev@lists.jboss.org
 Cc: "Tom Evans" , "Emily Jiang" 
 Sent: Monday, November 28, 2016 4:56:12 PM
 Subject: [weld-dev] Specializes bean in war causes unsatisfied
>> resolution exception
 
 Hello
 
 A customer of mine sent in a test application with the following
>> structure:
 
 A war file inside ear
 Two jar files inside ear/lib
 One jar file inside ear/war/WEB-INF/lib
 
 There is a class inside one of the ear/lib jar files which @Injects a
>> bean
 from the other ear/lib jar file
 
 And there is a class inside the ear/war/WEB-INF/lib jar file that
 @Specializes the bean inside an ear/lib jar file
 
 (You can see the application at was_bugs/was_bug22 at master ·
 thikade/was_bugs · GitHub )
 
 Attempting to run this application on Weld results in an Unsatisfied
 Resolution Exception. When I remove the jar containing the
>> @Specializes bean
 the application works correctly.
 
 
 My first thought was that this application should not work, because
>> the war
 file and it's internal jar would have a second classloader that would be
 invisible to the application classloader. However the customer
>> attested, and
 I confirmed that this application works fine on OpenWebBeans.
 
 I do not think this is an integration issue, because I tested this on
>> Wildfly
 and got the same error.
 
 
 So it seems that Weld throws an Unsatisfied Resolution Exception 

Re: [weld-dev] ApplicationScoped event fires on service invocation

[Mark Struberg]

But the ServletContextEvent is available much earlier.
I think this might rather be an integration issue. 


In OWB we don't fire the @Intialized for the ApplicationContext inside the 
ApplicationContext implementation but as part of the integration code, means 
TomEE, Geronimo, SAP, etc.

The interplay and boot order between EJB @Startup @Singleton and the CDI 
container is imo not really well defined. We just did what we think is best. 
Afair that means that in TomEE we fire the @Initialized _before_ we do @Startup 
but _after_ all the metadata parsing and EJB and CDI Extension handling was 
done. 


LieGrue,
strub





> On Friday, 19 August 2016, 15:37, Martin Kouba  wrote:
> > Hi Benjanmin,
> 
> for a web application the payload of 
> @Initialized(ApplicationScoped.class) must be the relevant 
> ServletContext. That's why Weld is waiting for a webapp to be ready 
> (implemented as 
> javax.servlet.ServletContextListener.contextInitialized(ServletContextEvent)).
> 
> Martin
> 
> Dne 19.8.2016 v 14:17 Benjamin Confino napsal(a):
>>  We have a user scenario where we wishes to replace @Singleton @Startup
>>  EJB beans with CDI beans. This was attempted by observing the
>>  ApplicationScoped initialization event to trigger the replacement code.
>> 
>>  However, the event was fired only after the service invocation, which
>>  was too late. Apparently OWB fires this event much earlier.
>>  The CDI spec states:
>> 
>>  The /application context /is provided by a built-in context object for
>>  the built-in scope type
>>  @ApplicationScoped. The application scope is active:
>>  • during the service() method of any servlet in the web application,
>>  during the doFilter()
>>  method of any servlet filter and when the container calls any
>>  ServletContextListener,
>>  HttpSessionListener, AsyncListener or ServletRequestListener,
>>  • during any Java EE web service invocation,
>>  • during any remote method invocation of any EJB, during any
>>  asynchronous method invocation
>>  of any EJB, during any call to an EJB timeout method and during message
>>  delivery to any EJB
>>  message-driven bean,
>>  • when the disposer method or @PreDestroy callback of any bean with any
>>  normal scope other
>>  than @ApplicationScoped is called, and
>>  *• during **@PostConstruct **callback of any bean.*
>> 
>>  The application context is shared between all servlet requests, web
>>  service invocations, EJB
>>  remote method invocations, EJB asynchronous method invocations, EJB
>>  timeouts and message
>>  deliveries to message-driven beans that execute within the same
>>  application. The application
>>  context is destroyed when the application is shut down.
>> 
>>  An event with qualifier @Initialized(ApplicationScoped.class) is fired
>>  when the application
>>  context is initialized and an event with qualifier
>>  @Destroyed(ApplicationScoped.class) is fired
>>  when the application is destroyed. The event payload is:
>>  • the ServletContext if the application is a web application deployed to
>>  a Servlet container, or
>>  • any java.lang.Object for other types of application.
>> 
>>  How do you interpret "initialized"? Does it mean the event is 
> fired only
>>  after the context is *active?*
>> 
>>  Is it possible to make the event firing a bit earlier, say around
>>  AfterDeploymentValidation?
>> 
>>  Below is the app to demonstrate the timing along with the server.xml:
>> 
>> 
>> 
>> 
>>  And here is the results of running it
>> 
>> 
>>  [AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
>>  [AUDIT   ] CWWKE0100I: This product is licensed for development, and
>>  limited production use. The full license terms can be viewed here:
>> 
> https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/16.0.0.2/lafiles/en.html
>> 
>>  [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
>>  *---> ApplicationScopedExtension, AfterDeploymentValidation event
>>  received, before looking up and touching @ApplicationScoped dummy bean*
>>  *---> ApplicationScopedDummyBean, @PostConstruct init method called*
>>  *---> ApplicationScopedExtension, after looking up and touching
>>  @ApplicationScoped dummy bean*
>>  [AUDIT   ] CWWKT0016I: Web application available (default_host):
>>  http://localhost:9080/70383.180.846.test-application/
>>  *---> ApplicationScopedObserverBean, observed
>>  @Initialized(ApplicationScoped.class) event.*
>>  [AUDIT   ] CWWKZ0001I: Application 70383.180.846.test-application
>>  started in 1.165 seconds.
>>  [AUDIT   ] CWWKF0012I: The server installed the following features:
>>  [jsp-2.3, ejbLite-3.2, managedBeans-1.0, jsf-2.2, beanValidation-1.1,
>>  servlet-3.1, ssl-1.0, jndi-1.0, jsonp-1.0, appSecurity-2.0, jdbc-4.1,
>>  jaxrs-2.0, jaxrsClient-2.0, el-3.0, json-1.0, cdi-1.2,
>>  distributedMap-1.0, webProfile-7.0, websocket-1.1, jpa-2.1].
>>  [AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a
>>  smarter 

Re: [weld-dev] CDI 1.2 tck challenge 1

[Mark Struberg]

No it makes perfect sense in _some_ cases to use Contexts.getRequestContxt() as 
BeanManager.getContext(RequestScoped.class) might throw a 
ContextNotActiveException.

LieGrue,
strub

  

 Am 07.05.2015 um 17:02 schrieb Jozef Hartinger jhart...@redhat.com:
 
 Hi Emily,
 
 you can submit TCK challenges direcly by opening JIRA issues at 
 https://issues.jboss.org/browse/CDITCK.
 
 As for this particular one I am not sure why the Contexts.getRequestContext() 
 method is still used in the tests. 
 BeanManager.getContext(RequestScoped.class) should IMHO be used instead.
 
 Jozef
 
 On 05/07/2015 01:50 PM, Emily Jiang wrote:
 
 I am trying to run cdi 1.2 tck:
 In test: 
 org.jboss.cdi.tck.tests.event.observer.conditional.ConditionalObserverTest
 Method: testConditionalObserverMethodNotInvokedIfNoActiveContext 
 
 I got this following failure:
 java.lang.IllegalStateException: Singleton not set for STATIC_INSTANCE = 
 [29478a84-0d13-49f5-b140-34a6cd92ab71, 0dd30cdc-10f4-4ec0-a8c5-d8fa3a82fc25, 
 bbc59ac1-4747-49d0-96a3-12f0d4987829, 3459400f-dd41-473c-a4db-94d60fe5899b, 
 10795c17-3611-41d5-b7ca-497709c2ad53, f10c929f-5314-44ba-aeb4-99888f6b4611, 
 a22c5a8f-bf26-4f54-a847-d1c7b5532426, 00c3de8d-65d9-4ba7-804a-9c3c515e59d7, 
 d7c8be7e-8b52-4c88-97e1-5ba6925fb794, 72ac8455-7c21-4090-b7ec-13d70c75a7d7, 
 dbe7255d-5485-4c2a-b547-058815660144, d3bb3d00-3214-48a5-b662-499010197e12]
 at 
 org.jboss.weld.bootstrap.api.helpers.RegistrySingletonProvider$RegistrySingleton.get(RegistrySingletonProvider.java:28)
 at org.jboss.weld.Container.instance(Container.java:55)
 at org.jboss.weld.tck.ContextsImpl.getRequestContext(ContextsImpl.java:33)
 at org.jboss.weld.tck.ContextsImpl.getRequestContext(ContextsImpl.java:30)
 at 
 org.jboss.cdi.tck.tests.event.observer.conditional.ConditionalObserverTest.testConditionalObserverMethodNotInvokedIfNoActiveContext(ConditionalObserverTest.java:96)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 
   From the stack trace, two strange things are happening:
 
 1) the TCK code is calling into org.jboss.weld.Container which is an 
 internal Weld class which should not be visible to application so the 
 application should not need to load them
 2) the TCK code is calling Container.instance() with no arguments, which 
 should not be called. We always use Container.instance(contextId), in 
 accordance with Weld doc A.3.2.4. Singleton SPI (this should be used in OSGi 
 environment).
 
 Can someone help to explain why the tck test was done this way? Is it 
 accurate?
 
 -- 
 Thanks
 Emily
 =
 Emily Jiang
 eji...@apache.org
 
 
 ___
 weld-dev mailing list
 
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev
 
 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev


___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] [cdi-dev] microbenchmark for CDI performance

[Mark Struberg]

Folks, you really scare me a bit!

I debugged into it and for the first BeanManger#getReference I get a proxy.

But for all other BeanManager#getReference I get the bare metal 
SimpleBeanWithoutInterceptor WITHOUT ANY PROXY.
Can you confirm this?
If so, then please tell me how you make this Serializable if it gets stored e.g 
in a Http Session?


This is just not conform to the CDI spec I fear. I even consider this a blocker 
bug...

LieGrue,
strub



 On Tuesday, 21 October 2014, 14:07, Jozef Hartinger jhart...@redhat.com 
 wrote:
  Btw I've run your benchmark locally and observed the following results:
 
 OWB 1.2.6: 9827ms
 Weld 2.2.5.Final: 20ms
 
 ;-)
 
 I did however tweak the test a bit so that Weld's optimizations can be 
 leveraged[1]. I admit that in certain situations (like your test without 
 my change) Weld performs worse than it should and this is a good input 
 for us.
 
 As for the NPE you observed not sure what is going on there. Perhaps 
 WeldContextControl implementation in DeltaSpike is not really thread safe?
 
 Jozef
 
 [1] https://github.com/jharting/cdi-performance/commits/weld
 
 On 10/21/2014 01:43 PM, Jozef Hartinger wrote:
  Hi Mark,
 
  thanks for showcasting your new feature. Great to see OWB getting
  faster! As for the micro benchmark I suggest that you check out JMH[1].
 
  If you need an input from the Weld team, use weld-dev@lists.jboss.org
 
  [1] http://openjdk.java.net/projects/code-tools/jmh/
 
  On 10/21/2014 11:59 AM, Mark Struberg wrote:
  Hi!
 
  Weld folks, I need some help with a micro benchmark:
 
  You know we've talked about disk footprint in SE, so I hacked 
 together a small microbenchmark and as a side effect we also got what is 
 really 
 needed to have CDI running
 
  https://github.com/struberg/cdi-performance
 
  I'm curious about missing some dependency excludes for Weld.
 
  could you please run
 
  $ mvn clean dependency:copy-dependencies -DincludeScope=compile 
 -PWeld -Dweld.version=2.2.5.Final
  $ ls -al target/dependency/
 
  and tell me which dependencies can be without having some CDI 
 functionality missing?
 
  Feel free to pimp the pom and ship a pull request.
 
 
  txs and LieGrue,
  strub
  ___
  cdi-dev mailing list
  cdi-...@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/cdi-dev
 
  Note that for all code provided on this list, the provider licenses the 
 code under the Apache License, Version 2 
 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
 provided 
 on this list, the provider waives all patent and other intellectual property 
 rights inherent in such information.
 
  ___
  cdi-dev mailing list
  cdi-...@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/cdi-dev
 
  Note that for all code provided on this list, the provider licenses the 
 code under the Apache License, Version 2 
 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
 provided 
 on this list, the provider waives all patent and other intellectual property 
 rights inherent in such information.
 
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] AfterBeanDiscovery and observer resolver cache

[Mark Struberg]

Hi Christian!

While I find it nice that this works with OWB I also have to agree that this is 
not a guaranteed behaviour by the spec intention.
What you could do in to hack around this issue is to have an @Observes@Any  
Object method which delivers the events with your own dynamic rules.
But be prepared that this might slow down your app a bit.

LieGrue,
strub





On Wednesday, 5 March 2014, 17:04, Christian Sadilek csadi...@redhat.com 
wrote:
 
Hi,

Yes, I expected this to not be an officially supported use case. So, I guess 
it's just a matter of improving the API design/documentation.

However, dynamically registering an observer method would really be useful in 
the case of Errai where we set up an event bridge between the server and the 
client and potentially discover new observers at runtime.

We could work around this by registering an observer method that observes all 
events and then handle the dispatching internally but that seems less 
efficient. Right now this works because OpenWebBeans doesn't cache the 
observers and allows invocations to AfterBeanDiscovery.addObserverMethod at 
runtime and because Weld has the functionality to clear the observer cache 
(although that's not public API).

My questions is: Is there a good reason not to support this going forward? Can 
we add alternative functionality to add observer methods at runtime (not using 
ABD)?

Cheers,
Christian


On 2014-03-05, at 4:37 AM, Martin Kouba mko...@redhat.com wrote:

 FYI I've informed CDI EG and it will be discussed on the next meeting
 whether to clarify this already in CDI 1.2 MR...
 
 M
 
 Dne 5.3.2014 10:19, Jozef Hartinger napsal(a):
 Agreed. It is definitely not the intention of the specification to allow 
 beans/observers/contexts to be added at runtime and applications should 
 not have any expectations of what these methods do when invoked outside 
 of the AfterBeanDiscovery observer.
 
 We'll add stricter validation to Weld to disallow this.
 
 On 03/05/2014 08:53 AM, Martin Kouba wrote:
 Hi Christian,this
 
 actually invoking any container lifecycle event method after the
 container initialization finished should have no effect. ABD event
 reference can escape but it does not mean you can invoke ABD.addBean()
 after ADV is fired.
 
 The spec wording is not very explicit here:
 During the application initialization process, the container fires a
 series of events, allowing portable extensions to integrate with
 the container initialization process defined in Section 12.2.
 
 Maybe we should file a new spec issue to clarify that such invocations
 should result in IllegalStateException...
 
 Martin
 
 
 Dne 4.3.2014 17:42, Christian Sadilek napsal(a):
 Hi Jozef,
 
 I think clearing the cache at the end of the Weld bootstrap process is 
 not enough to solve that particular problem since a CDI extension can 
 hold on to the ABD reference and invoke addObserverMethod later (multiple 
 times) which causes the same problem I described below. There's no 
 indication to the caller of addObserverMethod that it's in fact too late 
 to call that method.
 
 Since an ABD event reference can always escape (can be used outside the 
 method that observes it) it seems this issue should be resolved (although 
 it admittedly is an edge case).
 
 Cheers,
 Christian
 
 On 2014-03-04, at 11:29 AM, Jozef Hartinger jhart...@redhat.com wrote:
 
 Hi Christian,
 
 this sounds like a bug. All the resolution caches should be cleared at 
 the very end of Weld's bootstrap sequence (after ABD observers are 
 called). (see 
 https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldStartup.java#L415)
 
 Jozef
 
 On 03/04/2014 04:36 PM, Christian Sadilek wrote:
 Hi everyone,
 
 CDI extensions can observe the AfterBeanDiscovery event to register 
 observer methods (addObserverMethod). However, when an event is first 
 fired, the observers for that event are resolved and then cached (in 
 TypeSafeResolver). All future calls to addObserverMethod for an already 
 fired event with corresponding qualifiers will have no effect because 
 the observer result is read from cache and not recomputed.
 
 From an API perspective that's unfortunate because addObserverMethod 
 will only work until an event (with corresponding qualifiers) is fired 
 and there is no indication to the caller of that method that it didn't 
 have any effect when invoked after that.
 
 Possible solutions:
 
 - Provide some public API to clear/recompute that part the observer 
 cache. Maybe that exists? I couldn't find it which is why I am using 
 the private API and Reflection :(. Also let 
 AfterBeanDiscovery.addObserverMethod fail in that case with the advice 
 to reset the cache.
 
 - Recompute the corresponding part of the cache when addObserverMethod 
 is called (seems preferable).
 
 OpenWebBeans doesn't have this issue as their NotificationManager will 
 simply add the new ObserverMethod to a ConcurrentHashMap that is also 
 accessed when an 

Re: [weld-dev] PostConstruct PreDestroy in Java SE

[Mark Struberg]

The wording is not correct.

Each JSR-299 Container must _fully_ implement the JSR-330 specification and 
pass the JSR-330 TCK. Thus each CDI Container MUST support 
javax.inject.Singleton. But it's actually not really defined in detail how this 
scope should behave. And the atinject and EE specs also define that 
@PostConstruct and @PreDestroy must work for @Singleton beans. So this is imo a 
bug. But otoh I personally would suggest to not use javax.inject.Singleton 
because of the aforementioned underspecified behaviout.

LieGrue,
strub




- Original Message -
 From: Martin Kouba mko...@redhat.com
 To: Kristoffer Sjögren sto...@gmail.com
 Cc: weld-dev@lists.jboss.org
 Sent: Friday, 6 September 2013, 14:31
 Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE
 
 Actually there's no singleton scope and corresponding built-in context
 defined in the CDI spec. Though Weld API contains
 org.jboss.weld.context.SingletonContext. Also the docs are outdated
 (chapter 5.4. The singleton pseudo-scope). I think relevant classes
 should be deprecated and the docs updated.
 
 With regard to lifecycle callbacks - Weld only invalidates application
 context during shutdown right now [1].
 
 Martin
 
 [1]
 https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldRuntime.java#L56
 
 Dne 6.9.2013 14:09, Kristoffer Sjögren napsal(a):
  Hi
 
  We're running Weld 2.0.3.Final in a Java SE environment and have
  encountered a precarious situation where it seems like Weld is not
  consistent in handling the lifecycle of singleton beans.
 
  We have singleton beans with @PostConstruct and @PreDestroy methods.
  During Weld.initialize() all @PostConstruct methods are called. But
  during @PreDestroy methods are never called during Weld.shutdown().
  @PreDestroy is only called on beans which are @ApplicationScoped.
 
  Is this according to specification or a bug?
 
  Cheers,
  -Kristoffer
 
 
  ___
  weld-dev mailing list
  weld-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/weld-dev
 
 
 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev
 

___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] PostConstruct PreDestroy in Java SE

[Mark Struberg]

And before there are any questions: it's not directly stated inside the CDI 
spec but in the TCK documentation:

http://docs.jboss.org/cdi/tck/reference/1.0.4.SP1/pdf/jsr299-tck-reference-guide.pdf

JSR-330 - CDI builds on JSR-330, and as such JSR-299 implementations must 
additionally pass the JSR-330 TCK.

again: I agree with Martin that you should better not use it. But it should 
work nontheless.

LieGrue,
strub




- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: Martin Kouba mko...@redhat.com; Kristoffer Sjögren sto...@gmail.com
 Cc: weld-dev@lists.jboss.org weld-dev@lists.jboss.org
 Sent: Saturday, 7 September 2013, 19:22
 Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE
 
T he wording is not correct.
 
 Each JSR-299 Container must _fully_ implement the JSR-330 specification and 
 pass 
 the JSR-330 TCK. Thus each CDI Container MUST support javax.inject.Singleton. 
 But it's actually not really defined in detail how this scope should behave. 
 And the atinject and EE specs also define that @PostConstruct and @PreDestroy 
 must work for @Singleton beans. So this is imo a bug. But otoh I personally 
 would suggest to not use javax.inject.Singleton because of the aforementioned 
 underspecified behaviout.
 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
  From: Martin Kouba mko...@redhat.com
  To: Kristoffer Sjögren sto...@gmail.com
  Cc: weld-dev@lists.jboss.org
  Sent: Friday, 6 September 2013, 14:31
  Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE
 
  Actually there's no singleton scope and corresponding built-in context
  defined in the CDI spec. Though Weld API contains
  org.jboss.weld.context.SingletonContext. Also the docs are outdated
  (chapter 5.4. The singleton pseudo-scope). I think relevant classes
  should be deprecated and the docs updated.
 
  With regard to lifecycle callbacks - Weld only invalidates application
  context during shutdown right now [1].
 
  Martin
 
  [1]
 
 https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldRuntime.java#L56
 
  Dne 6.9.2013 14:09, Kristoffer Sjögren napsal(a):
   Hi
 
   We're running Weld 2.0.3.Final in a Java SE environment and have
   encountered a precarious situation where it seems like Weld is not
   consistent in handling the lifecycle of singleton beans.
 
   We have singleton beans with @PostConstruct and @PreDestroy methods.
   During Weld.initialize() all @PostConstruct methods are called. But
   during @PreDestroy methods are never called during Weld.shutdown().
   @PreDestroy is only called on beans which are @ApplicationScoped.
 
   Is this according to specification or a bug?
 
   Cheers,
   -Kristoffer
 
 
   ___
   weld-dev mailing list
   weld-dev@lists.jboss.org
   https://lists.jboss.org/mailman/listinfo/weld-dev
 
 
  ___
  weld-dev mailing list
  weld-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/weld-dev
 
 
 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev
 

___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] PostConstruct PreDestroy in Java SE

[Mark Struberg]

No, the TCK is part of the deliverable for the specification. As is the API 
JavaDoc. 

Also the spec mentions the 'Injection for Java' specification (== JSR-330) as 
reference.


LieGrue,
strub




 From: Kristoffer Sjögren sto...@gmail.com
To: Mark Struberg strub...@yahoo.de 
Cc: Martin Kouba mko...@redhat.com; weld-dev@lists.jboss.org 
weld-dev@lists.jboss.org 
Sent: Saturday, 7 September 2013, 20:54
Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE
 


Alright, the specification and TCK is inconsistent. But as a user, I dont care 
about the TCK and it does not make sense to enforce requirements on the 
specification in the TCK. For users, strictly speaking, anything not stated in 
the specification is unsupported. Correct?




 




On Sat, Sep 7, 2013 at 8:03 PM, Mark Struberg strub...@yahoo.de wrote:

And before there are any questions: it's not directly stated inside the CDI 
spec but in the TCK documentation:

http://docs.jboss.org/cdi/tck/reference/1.0.4.SP1/pdf/jsr299-tck-reference-guide.pdf

JSR-330 - CDI builds on JSR-330, and as such JSR-299 implementations must 
additionally pass the JSR-330 TCK.

again: I agree with Martin that you should better not use it. But it should 
work nontheless.


LieGrue,
strub




- Original Message -

 From: Mark Struberg strub...@yahoo.de
 To: Martin Kouba mko...@redhat.com; Kristoffer Sjögren sto...@gmail.com
 Cc: weld-dev@lists.jboss.org weld-dev@lists.jboss.org
 Sent: Saturday, 7 September 2013, 19:22
 Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE

T he wording is not correct.


 Each JSR-299 Container must _fully_ implement the JSR-330 specification and 
 pass
 the JSR-330 TCK. Thus each CDI Container MUST support 
 javax.inject.Singleton.
 But it's actually not really defined in detail how this scope should behave.
 And the atinject and EE specs also define that @PostConstruct and 
 @PreDestroy
 must work for @Singleton beans. So this is imo a bug. But otoh I personally
 would suggest to not use javax.inject.Singleton because of the 
 aforementioned
 underspecified behaviout.

 LieGrue,
 strub




 - Original Message -
  From: Martin Kouba mko...@redhat.com
  To: Kristoffer Sjögren sto...@gmail.com
  Cc: weld-dev@lists.jboss.org
  Sent: Friday, 6 September 2013, 14:31
  Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE

  Actually there's no singleton scope and corresponding built-in context
  defined in the CDI spec. Though Weld API contains
  org.jboss.weld.context.SingletonContext. Also the docs are outdated
  (chapter 5.4. The singleton pseudo-scope). I think relevant classes
  should be deprecated and the docs updated.

  With regard to lifecycle callbacks - Weld only invalidates application
  context during shutdown right now [1].

  Martin

  [1]

 https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldRuntime.java#L56

  Dne 6.9.2013 14:09, Kristoffer Sjögren napsal(a):
   Hi

   We're running Weld 2.0.3.Final in a Java SE environment and have
   encountered a precarious situation where it seems like Weld is not
   consistent in handling the lifecycle of singleton beans.

   We have singleton beans with @PostConstruct and @PreDestroy methods.
   During Weld.initialize() all @PostConstruct methods are called. But
   during @PreDestroy methods are never called during Weld.shutdown().
   @PreDestroy is only called on beans which are @ApplicationScoped.

   Is this according to specification or a bug?

   Cheers,
   -Kristoffer


   ___
   weld-dev mailing list
   weld-dev@lists.jboss.org
   https://lists.jboss.org/mailman/listinfo/weld-dev


  ___
  weld-dev mailing list
  weld-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/weld-dev


 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev






___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] PostConstruct PreDestroy in Java SE

[Mark Struberg]

No, I don't expect users to read the TCK - but it's binding for the container 
vendors.

Again: I completely agree with Martin with his advice to not use 
@javax.inject.Singleton in CDI projects as it is really underspecified in 
JSR-330 already. And JSR-299 does not add any wording to make things more 
clear. 

But the fuzzyness around @Singleton is mainly about it's lifecycle, etc. The 
requirement for @PostConstruct and @PreDestroy support is otoh actually pretty 
well defined in atinject imo.


LieGrue,
strub




 From: Kristoffer Sjögren sto...@gmail.com
To: Mark Struberg strub...@yahoo.de 
Cc: Martin Kouba mko...@redhat.com; weld-dev@lists.jboss.org 
weld-dev@lists.jboss.org 
Sent: Saturday, 7 September 2013, 21:11
Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE
 


http://docs.jboss.org/cdi/spec/1.1/cdi-spec.pdf 1.2.4 Relationship to 
Dependency Injection for Java  is what you referring to I suppose? But there 
is no telling how to use it. Also, its a bit unfortunate that we have two 
Singleton annotations, begging for confusion.


Nevermind vagueness, but do you expect users to read the TCK? Not trying 
criticize, there may be room for improvement here no?






On Sat, Sep 7, 2013 at 8:57 PM, Mark Struberg strub...@yahoo.de wrote:



No, the TCK is part of the deliverable for the specification. As is the API 
JavaDoc.

Also the spec mentions the 'Injection for Java' specification (== JSR-330) as 
reference.


LieGrue,
strub




 From: Kristoffer Sjögren sto...@gmail.com
To: Mark Struberg strub...@yahoo.de
Cc: Martin Kouba mko...@redhat.com; weld-dev@lists.jboss.org 
weld-dev@lists.jboss.org
Sent: Saturday, 7 September 2013, 20:54

Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE



Alright, the specification and TCK is inconsistent. But as a user, I dont 
care about the TCK and it does not make sense to enforce requirements on the 
specification in the TCK. For users, strictly speaking, anything not stated 
in the specification is unsupported. Correct?




 




On Sat, Sep 7, 2013 at 8:03 PM, Mark Struberg strub...@yahoo.de wrote:

And before there are any questions: it's not directly stated inside the CDI 
spec but in the TCK documentation:

http://docs.jboss.org/cdi/tck/reference/1.0.4.SP1/pdf/jsr299-tck-reference-guide.pdf

JSR-330 - CDI builds on JSR-330, and as such JSR-299 implementations must 
additionally pass the JSR-330 TCK.

again: I agree with Martin that you should better not use it. But it should 
work nontheless.


LieGrue,
strub




- Original Message -

 From: Mark Struberg strub...@yahoo.de
 To: Martin Kouba mko...@redhat.com; Kristoffer Sjögren 
 sto...@gmail.com
 Cc: weld-dev@lists.jboss.org weld-dev@lists.jboss.org
 Sent: Saturday, 7 September 2013, 19:22
 Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE

T he wording is not correct.


 Each JSR-299 Container must _fully_ implement the JSR-330 specification 
 and pass
 the JSR-330 TCK. Thus each CDI Container MUST support 
 javax.inject.Singleton.
 But it's actually not really defined in detail how this scope should 
 behave.
 And the atinject and EE specs also define that @PostConstruct and 
 @PreDestroy
 must work for @Singleton beans. So this is imo a bug. But otoh I 
 personally
 would suggest to not use javax.inject.Singleton because of the 
 aforementioned
 underspecified behaviout.

 LieGrue,
 strub




 - Original Message -
  From: Martin Kouba mko...@redhat.com
  To: Kristoffer Sjögren sto...@gmail.com
  Cc: weld-dev@lists.jboss.org
  Sent: Friday, 6 September 2013, 14:31
  Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE

  Actually there's no singleton scope and corresponding built-in context
  defined in the CDI spec. Though Weld API contains
  org.jboss.weld.context.SingletonContext. Also the docs are outdated
  (chapter 5.4. The singleton pseudo-scope). I think relevant classes
  should be deprecated and the docs updated.

  With regard to lifecycle callbacks - Weld only invalidates application
  context during shutdown right now [1].

  Martin

  [1]

 https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldRuntime.java#L56

  Dne 6.9.2013 14:09, Kristoffer Sjögren napsal(a):
   Hi

   We're running Weld 2.0.3.Final in a Java SE environment and have
   encountered a precarious situation where it seems like Weld is not
   consistent in handling the lifecycle of singleton beans.

   We have singleton beans with @PostConstruct and @PreDestroy methods.
   During Weld.initialize() all @PostConstruct methods are called. But
   during @PreDestroy methods are never called during Weld.shutdown().
   @PreDestroy is only called on beans which are @ApplicationScoped.

   Is this according to specification or a bug?

   Cheers,
   -Kristoffer


   ___
   weld-dev mailing list
   weld-dev@lists.jboss.org
   https

[weld-dev] are AnnotatedType and Co immutable?

[Mark Struberg]

Hi folks!

If I pat(@Observes ProcessAnnotatedType annotatedType), is it allowed to simply 
modify the Sets?

E.g. call 
annotatedType.getAnnotations().add(myOwnAnnotation) ?

The spec imo doesn't mention that those Sets are immutable, so it should work. 
It works in OWB at least, but what about Weld and CanDI?

txs and LieGrue,
strub




  
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] are AnnotatedType and Co immutable?

[Mark Struberg]

Hmm, I wouldn't argue that way.

The spec _and_ the JavaDocs just say Returns: all annotations of the program 
element, or an empty set if no annotations are present 

There is a hint in the spec which might underline your interpretation: Any 
observer of this event is permitted to _wrap_ and/or replace the 
AnnotatedType. But that sentence doesn't rule out the simple modification.

If they are all immutable, then we should express this explicitly in the 
CDI-1.1 spec!

LieGrue,
strub

--- On Fri, 3/18/11, Stuart Douglas stuart.w.doug...@gmail.com wrote:

 From: Stuart Douglas stuart.w.doug...@gmail.com
 Subject: Re: [weld-dev] are AnnotatedType and Co immutable?
 To: Mark Struberg strub...@yahoo.de
 Cc: weld-dev@lists.jboss.org weld-dev@lists.jboss.org
 Date: Friday, March 18, 2011, 9:35 AM
 In weld the sets are immutable (or
 defensive copies, can't remember). 
 
 I don't think that just because the spec does not mention
 immutability that you could expect to modify internal state
 of the annotated type through the set.
 
 Stuart
 
 Sent from my iPhone
 
 On 18/03/2011, at 20:24, Mark Struberg strub...@yahoo.de
 wrote:
 
  Hi folks!
  
  If I pat(@Observes ProcessAnnotatedType
 annotatedType), is it allowed to simply modify the Sets?
  
  E.g. call 
  annotatedType.getAnnotations().add(myOwnAnnotation) ?
  
  The spec imo doesn't mention that those Sets are
 immutable, so it should work. It works in OWB at least, but
 what about Weld and CanDI?
  
  txs and LieGrue,
  strub
  
  
  
  
  
  ___
  weld-dev mailing list
  weld-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/weld-dev
 


  
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] clarification of AfterDeploymentValidation

[Mark Struberg]

Hi!

I need to trigger a task once the whole CDI container got started, and I'm not 
sure  if the AfterDeploymentValidation can be used for this. Basically what I 
like to do is to warm-up  initialise CDI based services when the server has 
been started.

The AfterDeploymentValidation system event is defined as:

The container must fire a third event after it has validated that there are no 
deployment problems and before creating contexts or processing requests.

Thus especially the part before creating contexts is a bit unclear. Does this 
mean that no @ApplicationScoped, etc beans are available yet in this phase?

If so, do we like to introduce a new AfterServerStart event?

LieGrue,
strub


  
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] clarification of AfterDeploymentValidation

[Mark Struberg]

Hi Dan!

The trick with the servlet is neat ;)

 If you want to know when CDI is done starting up and when application-
 scoped beans are available, that's the AfterDeploymentValidation event.
Oki, this might work in Weld and in OWB, but does the Spec really forces this 
for any other container too? In other words: can a developer of an Extension 
_really_ count on it?

I also believe it is ambiguous, so should I file a CDI spec clarification issue?

txs and LieGrue,
strub


--- On Fri, 1/14/11, Dan Allen dan.j.al...@gmail.com wrote:

From: Dan Allen dan.j.al...@gmail.com
Subject: Re: [weld-dev] clarification of AfterDeploymentValidation
To: Mark Struberg strub...@yahoo.de
Cc: weld-dev@lists.jboss.org
Date: Friday, January 14, 2011, 9:18 PM

I've actually had this exact same dilemma in Seam. I want to know when 
everything is ready. So it really depends on how you define after (or started)
If you want to know when CDI is done starting up and when application-scoped 
beans are available, that's the AfterDeploymentValidation event. However, I 
also believe that this sounds too ambiguous. You have to know that deployment 
validation is the last phase to know that the CDI beans are ready.


Then there is the question of when is the module deployed? (module meaning 
web archive, for instance). It amazes me that there is no definitive event in 
Java EE for this. I've hacked around this in Seam by registering a Servlet with 
a very low priority and fire an event in the init() method.


https://github.com/seam/servlet/blob/master/impl/src/main/java/org/jboss/seam/servlet/event/ServletEventBridgeServlet.java


I consider that a design requirement for EE 7.

-Dan

On Fri, Jan 14, 2011 at 16:09, Mark Struberg strub...@yahoo.de wrote:


Hi!



I need to trigger a task once the whole CDI container got started, and I'm not 
sure  if the AfterDeploymentValidation can be used for this. Basically what I 
like to do is to warm-up  initialise CDI based services when the server has 
been started.





The AfterDeploymentValidation system event is defined as:



The container must fire a third event after it has validated that there are no 
deployment problems and before creating contexts or processing requests.



Thus especially the part before creating contexts is a bit unclear. Does this 
mean that no @ApplicationScoped, etc beans are available yet in this phase?



If so, do we like to introduce a new AfterServerStart event?



LieGrue,

strub







___

weld-dev mailing list

weld-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/weld-dev




-- 
Dan AllenPrincipal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com


http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen







  

___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] CODI and JBoss AS 6 final: ProjectStageActivationExtension didn't implement the Extension interface

[Mark Struberg]

I partly agree: 

1.) yes, it's not really 100% defined in the spec, and this should get fixed
2.) no, Weld did definitely support this a few months ago
3.) Seam-faces uses the same impl thus you'd need to fix it there also
4.) the CreationalContext is also not defined as Serializable, and there is no 
passivationId for those. So as per the pure spec, it would currently be 
impossible to implement this if the Container doesn't provide Serializable 
Beans.

Weld still seems to implements Serializable (or Externalizable) for the 
CreationalContext, so this part is already not spec conform. I see no reason 
why Weld cannot re-enable serialisation support for Beans too ;) 

We of course also need to ping Reza for resin. Pete, I don't remember anymore, 
was he involved in our discussion about this early last year?

LieGrue,
strub


--- On Wed, 1/5/11, Michael Schütz michaelschuet...@gmail.com wrote:

From: Michael Schütz michaelschuet...@gmail.com
Subject: Re: [weld-dev] CODI and JBoss AS 6 final: 
ProjectStageActivationExtension didn't implement the Extension interface
To: Pete Muir pm...@redhat.com
Cc: Pete Muir pm...@bleepbleep.org.uk, weld-dev@lists.jboss.org 
weld-dev@lists.jboss.org
Date: Wednesday, January 5, 2011, 11:15 PM

Pretty interesting!

Thanks a lot for all your help.

I did file an JIRA issue: https://issues.apache.org/jira/browse/EXTCDI-118


Michael


2011/1/5 Pete Muir pm...@redhat.com

Basically the issue is that the spec doesn't place any mandate on a 
PassivationCapable bean being serializable when passed to a Context impl. This 
is something we should definitely change in the spec (see CDI-24) as it's quite 
simple for the container to do for you, and something we can do in Weld for 
1.2.0 (see WELD-793) but for CODI to be spec compliant for CDI 1.0 it does 
need to remove this assumption.




NB OWB already does this hence why it works there.



On 5 Jan 2011, at 13:15, Pete Muir wrote:



 Ok, so it sounds like a poor assumption by CODI that the Bean object is 
 serializable. Michael, I suggest you file an issue in their issue tracker for 
 this.



 On 5 Jan 2011, at 13:11, Mark Struberg wrote:



 Hmm Beans are serialized all the day if you use a @ViewScoped context 
 because the JSF ViewMap gets serialized/deserialized on every request. And 
 the ViewScopeContext stores all the beans (+contextual instances, dependent 
 objects, etc) in the ViewMap. I remember that this used to work in an 
 earlier Weld version.






 LieGrue,

 strub





 --- On Wed, 1/5/11, Pete Muir pm...@bleepbleep.org.uk wrote:



 From: Pete Muir pm...@bleepbleep.org.uk

 Subject: Re: [weld-dev] CODI and JBoss AS 6 final: 
 ProjectStageActivationExtension didn't implement the Extension interface

 To: Michael Schütz michaelschuet...@gmail.com

 Cc: Dan Allen dan.j.al...@gmail.com, Mark Struberg 
 strub...@yahoo.de, weld-dev@lists.jboss.org weld-dev@lists.jboss.org


 Date: Wednesday, January 5, 2011, 11:24 AM

 Weird, I wonder what is trying to

 serialize a bean object, there is no spec requirement for

 these to be serializable. Can you find out?



 On 5 Jan 2011, at 09:03, Michael Schütz wrote:



 Dan,

 thanks again.



 Having MyFaces configured now.



 Getting following error:

 09:58:21,068 INFO

 [org.apache.myfaces.util.ExternalSpecifications] MyFaces

 Unified EL support enabled

 09:58:21,209 INFO

 [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/myfaces-cdi-1.0.2-SNAPSHOT]]

 No state saving method defined, assuming default server

 state saving

 09:58:28,820 SCHWERWIEGEND

 [org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementHelper]

 Exiting serializeView - Could not serialize state:

 org.jboss.weld.bean.ManagedBean:

 java.io.NotSerializableException:

 org.jboss.weld.bean.ManagedBean

         at

 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)

 [:1.6.0_21]

         at

 java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)

 [:1.6.0_21]

         at

 java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1246)

 [:1.6.0_21]

         at

 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

 [:1.6.0_21]

         at

 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

 [:1.6.0_21]

         at

 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

 [:1.6.0_21]

         at

 java.lang.reflect.Method.invoke(Method.java:597)

 [:1.6.0_21]

         at

 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)

 [:1.6.0_21]

         at

 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)

 [:1.6.0_21]

         at

 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)

 [:1.6.0_21]

         at

 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)

 [:1.6.0_21]

         at

 java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)

 [:1.6.0_21