Have trouble with weld 1.1.0

[geschtli.mymail.trash-mail.com]

First, reactivating passivated beans is not possoble in the moment.

Second, the beans are not removable from the container, if they
does not have an interface.

Are there fixed planed for the next release?
  

[asiandub]

(1)
I have a possibly similar problem here, but you should provide a bit more information about your scenario.

I'll file a JIRA about my issue today.

(2)
What are you trying to achieve? And how?

[geschtli.mymail.trash-mail.com]

Hello

- My system is jboss 6 final and weld 1.1.0 -

I can't make such beans get been reactivated:

@Named(myWorker)
@SessionScoped
@Stateful
public class WorkerBean implements MyWorker,Serializable

(The interface 'MyWorker' i have only used , that jboss can at
session timeout remove the beans. With the 'no-interface view'
the beans remains in the container)

Perhaps the cdi beans specification is not compatible with the
ejb3 container specification at all?

Another problem is, i must switch off passivation complete,
while the beans are not reactivated and all ends up in an crash.

[geschtli.mymail.trash-mail.com]

Crash means, i get an weld proxy error with a class cast exception,
if i will reactivate the beans.

[geschtli.mymail.trash-mail.com]

My solution for that was, give all cdi beans an
inteface, shut off passivation and shorten the
session timeout a bit, then all works correkt.
(But it's not a good solution for a production server
with many sessions, i think)

The passivation problem is in my opinion a critical bug,
that destroys the actual session.

[asiandub]

The interface 'MyWorker' i have only used , that jboss can at session timeout remove the beans. With the 'no-interface view' the beans remains in the container

I must admit that I don't have any deeper knowledge about how beans are removed by the container, but I doubt that this cannot happen in no-interface-view. Sounds interesting enough, are you aware of any further resources about that?

[geschtli.mymail.trash-mail.com]

Hi

Now you can test it yourself. Create a cdi bean an call it once, that it is loaded in the
container.The shut off jboss and have a look at the end in the log file.
(In the sources you can test it with the @PreDestroy annotation)

[asiandub]

I see what you mean...

I wouldn't be too alarmed that those beans remain in the container forever. I'm pretty sure that - unless you are working with extreme performance / memory requirements - you can rely on a reasonable timeout mechanism that passivates / destroyes / removes them, probably closely linked to the conversation timeout, which defaults to 5 min (if I recall correctly).

Would still be interesting to know (and understand) why these log messages are written. Certainly not because the container has no handle on the component...!?

[geschtli.mymail.trash-mail.com]

I think it's importent to know how its own application works correct,
also to understand how the container works (not indeep).
But that is not the main problem.
The biggest problem is that weld 1.1 works in the moment
not correct with passivation in an EJB3 container.

I think the problem can be found in the different
specification's, that are not compatible at this point.
Each for its own can be total correct layoutet, but
not together.

'A key must suit in the key hole':-)