Doing method names, roles and principal bindings dynamically

Question

Hi,
We are using Weblogic 6.0 and have a question about Weblogic security and EJBs.
In Weblogic EJB security methods are mapped to roles in the EJB deployment descriptor
and roles are mapped to principals in the Weblogic deployment descriptors. All
this is statically defined.
The bindings frrom roles to principals in Weblogic deployment descriptors are
a tad to static for us. Is it possible to implement this dynamically through ACLs
or anything. I've tried to implement the 'Realm.getAcl(...)', but it doesn't seem
to want to use my ACLs and I really don't know what permissions that I should
implement in them. Does anyone know of any documents describing this?
Likewise we also wonder if we can dynamically map the method names to roles which
today are described in EJB deployment descriptors and how is that done?
have a nice day
ThorÅge
Telenor Mobil, Tlf: 22 78 47 59, Mob: [phone], [email protected]
"All suspects are guilty! Otherwise they wouldn't be suspects; would they?"

Answer 1

OK, a partial answer for the accessor name issue is this (inline JAXB used for brevity; external declarations probably better in practice):
1) change your schema root element to
<xs:schema
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
     jxb:version="1.0"2) do NOT modify the products element definition
3) instead, modify the product element definition to
<xs:element name="product">
     <xs:annotation>
        <xs:appinfo>
            <jxb:property name="productList"/>
        </xs:appinfo>
     </xs:annotation>
     <xs:complexType>
     </xs:complexType>
</xs:element>Then the JAXB autogenerated .java file for the products element (Products.java) will have an accessor method named getProductList as desired.
But all is not totally well: suppose that that product element is used not only inside the products element, but is also used inside the foo element where it has
minOccurs="1" maxOccurs="1"Then it will not be represented in Foo.java as a List<Product> field, but instead will be a simple reference to a Product. However, its name will misleadingly be given as productList.
So JAXB bindingd are not really a cure: it looks like JAXB needs to add smarts to its code generator.
Another thing that the JAXB code generator needs to do is not only dump lazy initialization, but it should use minOccurs values of > 16 to initialize, say, ArrayList fields to larger sizes to minimize resizings since you know that more than the default number of items will be in the ArrayList.