from ebj 2.0 spec 21.2.4:
"The Bean Provider should neither implement security mechanisms nor hard-code
security policies in the enterprise beansÂ’ business methods. Rather, the Bean
Provider should rely on the security mechanisms provided by the EJB Container,
and should let the Application Assem
OK, I see your point.
So I think we need to differentiate *class metadata* and *component
metadata*.
IMHO, as long as components are concerned, XML descriptors are fine and CLR
metadata would not add anything. But, if we speak more about, at a "lower"
level, class metadata, I agree that this is
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Sacha Labourey
> Furthermore, on this particular issue (10 different bean "types" but the
> same remote/home/bean), I do not see why the CLR would add simplicity?
Sorry, brain shortcut.
What I m
Hello Cedric,
> Yes. That's the whole point of deployment descriptors (that and
> the fact that
> Java bytecode doesn't support metadata... I wish Java worked on the CLR,
> Microsoft definitely solved this problem)
Sure, but on the other hand, that is just a packaging issue/view ;) an EJB
JAR i
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Zhang
> 1. For an EJB container, is it easier to manage 100 pooled instances of the
> same stateless session bean class or 100 pooled instances of 10 different
> SLSBs(10 instances for each
Hi, all
I have two questions:
1. For an EJB container, is it easier to manage 100 pooled instances of the
same stateless session bean class or 100 pooled instances of 10 different
SLSBs(10 instances for each SLSB)?
2. Can I specify 10 different EJBs in the xml deployment descriptor with
differe
