Sacha Labourey wrote:
> > Well the best advice I think is "just do it". :-)
>
> Great!
The best things are often the simplest :-)
> > Create the ejb-jar.xml just as with any other beans. The only difference
> > is that two entries will have the same bean class.
>
> So, the deployer uses the fully qualified class name (FQCN) to determine
> what to map to the database i.e. it won't create two (identical) DB tables
> (with different names!) for the two beans but instead share it?
No, incorrect.
> If this is
> true, that means that the "discriminant" for determining when to map a CMP
> bean to a new table is the FQCN?
Nope.
> Right?
Wrong.
> (it might have been the bean name,
> ...)
*That* is correct. Extension is that two deployed beans must, by
default, be mapped to two separate database tables, since they must have
different EJB names.
If this is not desired, such in your case, then you need to use jaws.xml
to explicitly set the table name to be equal, but also to use commit
option B or C so as to avoid caching problems.
> > The above is not the best way to solve this. Use security instead.
> > That's what it's for. I.e. restrict the methods that are not supposed to
> > be used by certain types of users. If you don't use security at all it
> > is still possible for (malicious) external clients to lookup the bean
> > with the admin interface and call it as it wishes.
>
> Yes, I thought about this, but my problem is not security related : I just
> want not to give to the client a HUGE (not so big in fact...) list of
> methods it will never use! It is more a "pedagogic" goal : not to confuse
> the client with tricky interfaces ;)
It's very rarely a good idea anyway to blindly use the remote interface
as a list of methods that may be invoked. Use a layer on top of your
beans to accomplish this, and you will more easily be able to make
multiple clients to one set of EJB's. That's one of the goals of EJB
anyway.
You may do as outlined above, but it is definitely not recommended.
Better to use either JavaBean layer on top that explicitly limits
available methods in client, or use security to limit access at
invoke-time, or use session bean as facade to provide several "faces" of
your application.
regards,
Rickard
--
Rickard Öberg
Email: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
