JAAS authentication with WebLogic 6 - "Invalid Configuration Class Name"

For starters, I took the sample file examples.security.jaas.SampleConfig, changed the name and
package, compiled, and copied it to the right place in the classes directory of the webapp project.
The class is specified as a parameter in startWebLogic.cmd:
-Dweblogic.security.jaas.Configuration="com.ww.opd.auth.JAASConfiguration"
When a servlet attempts to get LoginContext, I get this error:
"Invalid Configuration Class Name: com.ww.opd.auth.JAASConfiguration"
The class file is definitely in the right place. What's the deal?
Thanks,
Rob

Seems to be a ClassLoader problem. The sample is a client app, so no problem. But if you create
a Configuration class to run on the server (to set up a LoginModule for authenticating clients)...
I think what's happening is that the System class loader, using the CLASSPATH in the environment
of the WebLogic server when it starts, attempts to load the Configuration class and can't (because it
is in the CLASSPATH of the web app, not of the System class loader). If you add the Configuration
class to the CLASSPATH of the WebLogic server, then it gets loaded but the LoginModule can't be
found. If you add the LoginModule to the WebLogic server CLASSPATH, then any classes that it calls
must also be in the WebLogic server CLASSPATH.
Could someone from BEA please comment: is that the intention, that any classes used for JAAS
authentication be part of the server's CLASSPATH, not part of the web application?
Thanks,
Rob
"Rob Weltman" <[email protected]> wrote:
>
For starters, I took the sample file examples.security.jaas.SampleConfig, changed the name and
package, compiled, and copied it to the right place in the classes directory of the webapp project.
The class is specified as a parameter in startWebLogic.cmd:
-Dweblogic.security.jaas.Configuration="com.ww.opd.auth.JAASConfiguration"
When a servlet attempts to get LoginContext, I get this error:
"Invalid Configuration Class Name: com.ww.opd.auth.JAASConfiguration"
The class file is definitely in the right place. What's the deal?
Thanks,
Rob

Similar Messages

  • No Configuration Class Name Supplied Error !

    What with this message?
    ' No Configuration Class Name Supplied'
    When I try to create a LoginContext Object with the command line :
    lc = new LoginContext("MyAppli", new MyCallbackHandler());
    The following lines are in my java.security file
    login.configuration.provider=com.sun.security.auth.login.ConfigFile
    login.config.url.1=file:${java.home}/lib/security/matrix.login.config
    Is this a ClassPath problem?
    Somenone help me please
    Kalisen

    thanks for your answer,
    I still need a precision.
    I already have a block of this kind :
    myAppli {
    com.sun.security.auth.module.SolarisLoginModule required debug=true;
    ...in a file name MyAppli.login.config
    and I put a reference to it in the java.security file
    as below:
    login.configuration.provider=com.sun.security.auth.login.ConfigFile
    login.config.url.1=file:${java.home}/lib/security/Myappli.login.config
    but it still tell me that no configuration class name was supplied !
    It is the implementation of the Configuration interface it didn't find. And it is supposed to be by default the class com.sun.security.auth.login.ConfigFile
    And this class is in the JAAS package which itself is in the CLASSPATH so what's missing????
    every configuration file I did touch are in the ${java.home}/lib/security/ directory so they all are accessible...
    I NEED A CLUE
    thanks in advance !
         

  • No Configuration Class Name Supplied Error ! ROUND 2

    thanks for your answer,
    I still need a precision.
    I already have a block of this kind :
    myAppli {
    com.sun.security.auth.module.SolarisLoginModule required debug=true;
    ...in a file name MyAppli.login.config
    and I put a reference to it in the java.security file
    as below:
    login.configuration.provider=com.sun.security.auth.login.ConfigFile
    login.config.url.1=file:${java.home}/lib/security/Myappli.login.config
    but it still tell me that no configuration class name was supplied !
    It is the implementation of the Configuration interface it didn't find. And it is supposed to be by default the class com.sun.security.auth.login.ConfigFile
    And this class is in the JAAS package which itself is in the CLASSPATH so what's missing????
    every configuration file I did touch are in the ${java.home}/lib/security/ directory so they all are accessible...
    I NEED A CLUE
    thanks in advance !

    Try to put jaas.jar first in the classpath (if you are not using jdk 1.4)

  • ClassCircularityError in JAAS Authorization with Weblogic Server 10.3

    We are implementing JAAS authorization in which roles and policies are stored in a custom JAAS policy file and users are stored in the embedded LDAP server provided by Weblogic. We are facing problem is authorizing users using the custom policy created.
    We have implemented the JAAS authentication service with weblogic server 10g R3 and user's information stored in embedded LDAP server provided WLS. Given below are the details of implementation for JAAS Authorization:
    Following are the custom classes created:
    1. Custom Principal Class
    public class Principal implements java.security.Principal, java.io.Serializable {
    private String name;
    public Principal() {
    name = "";
    public Principal(String newName) {
    name = newName;
    public boolean equals(Object o) {
    if (o == null)
    return false;
    if (this == o)
    return true;
    if (o instanceof Principal) {
    if (((Principal) o).getName().equals(name))
    return true;
    else
    return false;
    else
    return false;
    public int hashCode() {
    return name.hashCode();
    public String toString() {
    return name;
    public String getName() {
    return name;
    2. Custom Permission Class
    public class ActionPermission extends Permission {
         public ActionPermission(String name) {
              super(name);
         @Override
         public boolean equals(Object obj) {
              if ((obj instanceof ActionPermission)
                        && ((ActionPermission) obj).getName().equals(this.getName())) {
                   return true;
              } else {
                   return false;
         @Override
         public String getActions() {
              return "";
         @Override
         public int hashCode() {
              return this.getName().hashCode();
         @Override
         public boolean implies(Permission permission) {
              if (!(permission instanceof ActionPermission)) {
                   return false;
              String thisName = this.getName();
              String permName = permission.getName();
              if (this.getName().equals("*")) {
                   return true;
              if (thisName.endsWith("*")
                        && permName.startsWith(thisName.substring(0, thisName
                                  .lastIndexOf("*")))) {
                   return true;
              if (thisName.equals(permName)) {
                   return true;
              return false;
    Following are the configuration changes:
    1. Added custom policy to weblogic.policy.
    grant Principal com.scotia.security.authorization.Principal "test" <User defined in the embedded LDAP server of WLS>{
    permission com.scotia.security.authorization.permission.ActionPermission "viewScreen";
    2. Set the java security manager in startWeblogic.cmd file.
    %JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% -Dweblogic.Name=%SERVER_NAME% -Djava.security.manager -Djava.security.policy=%WL_HOME%\server\lib\weblogic.policy %PROXY_SETTINGS% %SERVER_CLASS%
    3. Set Realm "Security Model" to "Custom Roles and Policies".
    Right now we are facing the given below exception:
    java.lang.ClassCircularityError: com/scotia/security/authorization/THORPrincipal
         at java.lang.Class.forName0(Native Method)
         at java.lang.Class.forName(Class.java:247)
         at sun.security.provider.PolicyFile.addPermissions(PolicyFile.java:1381)
         at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1268)
         at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1231)
         at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1167)
         at sun.security.provider.PolicyFile.implies(PolicyFile.java:1122)
         at weblogic.security.service.WLSPolicy.implies(Unknown Source)
         at java.security.ProtectionDomain.implies(ProtectionDomain.java:213)
         at java.security.AccessControlContext.checkPermission(AccessControlContext.java:301)
         at java.security.AccessController.checkPermission(AccessController.java:546)
         at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
         at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
         at java.io.File.exists(File.java:731)
         at weblogic.utils.classloaders.DirectoryClassFinder.getSource(DirectoryClassFinder.java:36)
    Please help if anyone has some clue regarding this exception. We tried checking the jdk version used by eclipse and weblogic and found it to be same.

    1. Custom Principal Class
    public class Principal implements java.security.Principal, java.io.Serializable {Rename it. You are asking for trouble naming a class after an interface it implements.
    java.lang.ClassCircularityError: com/scotia/security/authorization/THORPrincipalWhat's that class? You haven't shown us.

  • IIS authentication with weblogic

    I am trying to use IIS authentication with my ADF application deployed on weblogic. Is there any documentation for this?
    I want to use windows authentication with IIS. So users should not get any prompt for username / password to the application after they loggen in their windows machine.
    It should be like intranet ADF application.
    Thanks

    I am trying to use IIS authentication with my ADF application deployed on weblogic. Is there any documentation for this?
    I want to use windows authentication with IIS. So users should not get any prompt for username / password to the application after they loggen in their windows machine.
    It should be like intranet ADF application.
    Thanks

  • How to deal with '$' sign in the class name?

    I want to put my Java Applet game on my homepage. But the server which I set up my homepage doesn't support the file name like XXX$XXX.class, which has '$' sign in the file name. Would anyone can tell me how to deal with this problem? And how can I make the game work on my homepage? Thanks.

    Don't forget, this include both concrete inner classes as well as any anonymous inner classes you create, like
    myButton.addActionListener(new ActionListener()
      // Yada Yada Yada

  • Jaas authentication with cutom realm problem

    I'm having this problem, I have a web application made with JSF running on Sun One Application Server 9, and I made a cutom realm with Jaas so that the server will be handeling the authentication and it is working fine. The problem is that i want to load some info into the user's session after that he have been authenticated based on the username. But I have on clue how to do it. so I'll be very thanks full it anybody helped me.

    Did you resolve this problem? Please let me know. I have the same issue now and don;t know what I should be doing next

  • AS3 - dynamic class names with *new* operator

    I'm using AcrtionScript 3 and Adobe Flash 9 Public Alpha.
    I have 50 movie clips in the Library that use Linkage to set
    the Class name to: Img1, Img2, Img3, ..., Img50.
    I have a parent class named RandImg. I want the constructor
    for RandImg to randomly select one of the 50 movie clips from the
    Library and display it. I could get this working by generating a
    random number, and then writing a really huge switch statement to
    associate each possible random number with its respective Library
    Movie Clip Class name, but I would much rather do this with a
    dynamic/variable class name based on the random number, such as:
    var nImgChoice:Number = Math.floor( Math.random( ) * 50 ) +
    1;
    var mcImg:MovieClip = new [ "Img"+String(nImgChoice) ] ( );
    addChild( mcImg );
    Note that this used to be possible in AS 2 by doing the
    following:
    this.attachMovie( "Img"+String(nImgChoice) , "mcImg",
    this.getNextHighestDepth());
    Suggestions?
    Thanks,
    ~JC

    import flash.display.DisplayObject;
    import flash.display.Sprite;
    import flash.utils.getDefinitionByName;
    var nImgChoice:Number = Math.floor( Math.random( ) * 50 ) +
    1;
    var ClassReference:Class =
    getDefinitionByName("Img"+String(nImgChoice) ) as
    Class;
    var instance:Object = new ClassReference();
    addChild(DisplayObject(instance));

  • Ejb-jar.xml not using fully qualified class names

    HI,
    I am trying yo upgrade my application from weblogic 8.1 to weblogic 9.2.3. My application has both session and enitybeans. I updated weblogic related jars with 9.x version. But while running ejbgen, i am getting the following exception.
    *[java] weblogic.ejb.container.deployer.DeploymentDescriptorException: Unable to set the transaction attribute for method 'updateService(abcTO)' on EJB 'AbcService'. No matching method could be found. Please verify the method signature specified in the ejb-jar.xml file matches that of your Local interface for this EJB.*
    In ejb-jar.xml file, it is not creating the fully qualified class name for abcTo in <method-param>. In component interface, the method signature is not contaning fully qualified class name for the parameters and return values.
    If i change the signature in the bean with the fully qualified class name of the parameter, the ejb-jar.xml file is creating fine. But there are 100's of signatures i need to change if this is the only solution.
    Can you please advice what i need to change when i upgrade from weblogic 8 to 9 series from session and entity bean's point of view?
    Thanks in Advance
    Naveen.
    Edited by: avn_venki on Mar 16, 2009 7:15 AM
    Edited by: avn_venki on Mar 16, 2009 7:15 AM

    ejb-jar.xml has always required fully-qualified class names. If some vendors have accepted unqualified class names unfortunately that
    behavior is non-portable. Your best bet is to fully-qualify the names. Perhaps you can find some tools to help you given the large
    number of components in your application.

  • Configuring PAM login modules with weblogic 6.1

    I am trying to configure my own PAM login module to work on the same JVM as weblogic.
    I have my own security policy that does not rely on weblogic however when trying
    to login after creating a specific login context :
    LoginContext loginContext = new LoginContext("XXLogin",subject,
    callbackHandler);
    loginContext.login();
    The JVM tries to invoke weblogic's own internal server login module. It looks
    for the callback the login module uses and then fails.
    The same problem ocurrs at weblogic startup. Weblogic appears to overide the -Djava.security.auth.login.config=jaas.config
    with their own login configuration file:WLHOME\lib\server.policy. Is this supposed
    to be a standard PAM login configuration file or weblogic's own interpretation
    of it ? (It is called a policy file which normally relates to grants and permissions
    in JAVA). Anyway we modified this file to include our own login module under a
    different AuthenticationConfigurationName. However weblogic attempted to use our
    login module as well as their own. According to the jaas api when creating a login
    context the application configuration name is specified however weblogic appears
    to be ignoring this !! Also we have found that a PAM configuration file that we
    had did not parse with weblogic, however it worked with the standard PAM configuration
    file parser. This implies that weblogic does not use the standard parser. Any
    help welcome !!

    Hi Parthasarathy,
    Thanks for the pointer. Your suggestion was the first step to getting our Security
    Model to be compatible with the WebLogic 6.1 model. As suggested I removed the
    the default LoginModule (ServerLoginModule) from the Server.policy file and replaced
    it with our Login Module. Then we defined JVM properties for the weblogic.management.password
    property in the startweblogic command file to supply the authentication information
    required by WebLogic.
    The next problem that I encountered was that we use files in the jaas.jar for
    Authorisation when I tried to access these files (e.g. javax.security.auth.Policy)
    I got a sealing violation as the JVM had previously loaded other class files in
    this package from the weblogic.jar (as weblogic uses these files for authorisation).
    It was possible to get around this problem by putting the jaas.jar ahead of the
    weblogic.jar in the classpath.
    After this I just needed to set up permissions in the weblogic.policy file for
    authorisation and we were there.
    Regards
    Paul
    Parthasarathy Seshadri <[email protected]> wrote:
    Please note from the documentation:
    http://e-docs.bea.com/wls/docs61//security/prog.html#1039659
    that WLS uses the default Login Module (weblogic.security.internal.ServerLoginModule)
    to gather authentication informatino
    during server initialization. To replace the default Login module, edit
    the Server.policy file and replace the name of the
    default Login module with the name of a custom Login module.
    Please inform whether the above information is useful. Thank you.
    Paul Petley wrote:
    I am trying to configure my own PAM login module to work on the sameJVM as weblogic.
    I have my own security policy that does not rely on weblogic howeverwhen trying
    to login after creating a specific login context :
    LoginContext loginContext = new LoginContext("XXLogin",subject,
    callbackHandler);
    loginContext.login();
    The JVM tries to invoke weblogic's own internal server login module.It looks
    for the callback the login module uses and then fails.
    The same problem ocurrs at weblogic startup. Weblogic appears to overidethe -Djava.security.auth.login.config=jaas.config
    with their own login configuration file:WLHOME\lib\server.policy. Isthis supposed
    to be a standard PAM login configuration file or weblogic's own interpretation
    of it ? (It is called a policy file which normally relates to grantsand permissions
    in JAVA). Anyway we modified this file to include our own login moduleunder a
    different AuthenticationConfigurationName. However weblogic attemptedto use our
    login module as well as their own. According to the jaas api when creatinga login
    context the application configuration name is specified however weblogicappears
    to be ignoring this !! Also we have found that a PAM configurationfile that we
    had did not parse with weblogic, however it worked with the standardPAM configuration
    file parser. This implies that weblogic does not use the standard parser.Any
    help welcome !!--
    Developer Relations Engineer
    BEA Support

  • Programmatic JAAS Authentication for Web/EJBs on WebLogic 12c

    Technologies: JSPs, Servlets, EJBs (version 2.1)
    Database: Oracle 11g Database
    Application Server: WebLogic 12c
    I am working on a project where the users and roles are stored on an Oracle database (as database users with roles granted to them). We therefore need a custom authentication method (the default WebLogic UsernamePasswordLoginModule won't cut it). We created a DatabaseUserLoginModule prior to migrating from a 10g enviroment to 11g/12c.
    public class DatabaseUserLoginModule implements LoginModule
         public boolean login() throws LoginException
              Connection conn = null;
              try
                   s
                   InitialContext ic = new InitialContext();
                   DataSource ds = (DataSource)ic.lookup(jndiDSName);
                   conn = ds.getConnection(username, password);
                   List dbauth = new ArrayList();
                   String rolesSQL = "SELECT GRANTED_ROLE FROM USER_ROLE_PRIVS UNION SELECT GRANTED_ROLE FROM ROLE_ROLE_PRIVS";
                   Statement rolesStmt = conn.createStatement();
                   ResultSet results = rolesStmt.executeQuery(rolesSQL);
                   dbauth.add(new DBUserPrincipal(username));
                   while (results.next())
                        String roleName = results.getString("GRANTED_ROLE");
                        DBRolePrincipal dbRolePrincipal = new DBRolePrincipal(roleName);
                        dbauth.add(dbRolePrincipal);
                   authPrincipals = (Principal[])dbauth.toArray(new Principal[dbauth.size()]);
              catch (Exception e)
                   throw new LoginExcpetion(e.getMessage());
              finally
                   try
                        conn.close();
                   catch (Exception e)
                        throw new LoginExcpetion(e.getMessage());
              return true;
         public boolean commit() throws LoginException
              for (int i = 0; i < authPrincipals.length; i++)
                   subject.getPrincipals().add(authPrincipals[i]);
              return true;
    The getConnection() method on the datasource works with a database username and password thanks to the new "Use Database Credentials" option for WebLogic datasources and granting CONNECT THROUGH (datasource user) privilege for each user.
    We have configured a JAAS context to use this login module by creating a jaas.conf file and setting JAVA_OPTIONS to include "-Djava.security.auth.login.config=%DOMAIN_HOME%\bin\jaas.conf". The file looks like this:
    Test {
    xxxx.controller.security.loginmodule.DatabaseUserLoginModule required;
    When the user logs in, the application uses a LoginContext object to perform authentication:
        PassiveCallbackHandler cbh = new PassiveCallbackHandler(username, password);
        lc = new LoginContext("Test", cbh);
        lc.login();
    This successfully uses the DatabaseUserLoginModule to authenticate the user and populate the Subject with the appropriate roles.
    The next step is to use an InitialContext to lookup an EJB and call a method. We have permissions in ejb-jar.xml for each method, based on database roles:
    <method-permission>
         <role-name>XXXX_USER</role-name>
         <method>
              <ejb-name>AccessControl</ejb-name>
              <method-intf>Home</method-intf>
             <method-name>create</method-name>
             <method-params>
                   <method-param>java.lang.String</method-param>
             </method-params>
         </method>
         <method>
             <ejb-name>AccessControl</ejb-name>
             <method-intf>Remote</method-intf>
             <method-name>remove</method-name>
         </method>
         <method>
             <ejb-name>AccessControl</ejb-name>
             <method-intf>Remote</method-intf>
             <method-name>processFailedLogin</method-name>
             <method-params>
                   <method-param>java.lang.String</method-param>
             </method-params>
         </method>
         <method>
             <ejb-name>AccessControl</ejb-name>
             <method-intf>Remote</method-intf>
             <method-name>processSuccessfulLogin</method-name>
             <method-params>
                   <method-param>java.lang.String</method-param>
             </method-params>
         </method>
    </method-permission>
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
    env.put(Context.PROVIDER_URL, "t3://localhost:7101");
    env.put(Context.SECURITY_PRINCIPAL, username);
    env.put(Context.SECURITY_CREDENTIALS, password);
    InitialContext ic = new InitialContext(env);
    ic.lookup("EJBName");
    The problem is that when the InitialContext is initialised I get the following error:
    javax.naming.AuthenticationException [Root exception is javax.security.auth.login.FailedLoginException: [Security:090304]Authentication Failed: User XXXX_USER] javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User XXXX_USER denied]
    It looks like the InitialContext is attempting to authenticate the user through WebLogic's default authenticator. How do I tell it to use the JAAS context (with the custom login module) I have already set up?
    If I use the default constructor (new InitialContext()) then I get a different error when calling an EJB method:
    <java.rmi.AccessException: [EJB:010160]Security violation: User <anonymous> has insufficient permission to access EJB type=<ejb>, application=TestApplication, module=TestEJB.jar, ejb=AccessControl, method=processSuccessfulLogin, methodInterface=Remote, signature={java.lang.String}.>
    In this case, how do I propagate the Subject after using LoginContext so that the user calling EJB methods is not anonymous?

    This is the JDev & ADF forum. Your question is better asked in one of the WebLogic forums!
    Timo

  • Has anyone used JAAS with WebLogic?

    Has anyone used JAAS with Weblogic? I was looking at their example, and I have a bunch of questions about it. Here goes:
    Basically the problem is this: the plug-in LoginModule model of JAAS used in WebLogic (with EJB Servers) seems to allow clients to falsely authenticate.
    Let me give you a little background on what brought me to this. You can find the WebLogic JAAS example (to which I refer below) in the pdf: http://e-docs.bea.com/wls/docs61/pdf/security.pdf . (I believe you want pages 64-74) WebLogic, I believe goes about this all wrong. They allow the client to use their own LoginModules, as well as CallBackHandlers. This is dangerous, as it allows them to get a reference (in the module) to the LoginContext's Subject and authenticate themselves (i.e. associate a Principal with the subject). As we know from JAAS, the way AccessController checks permissions is by looking at the Principal in the Subject and seeing if that Principal is granted the permission in the "policy" file (or by checking with the Policy class). What it does NOT do, is see if that Subject
    has the right to hold that Principal. Rather, it assumes the Subject is authenticated.
    So a user who is allowed to use their own Module (as WebLogic's example shows) could do something like:
    //THEIR LOGIN MODULE (SOME CODE CUT-OUT FOR BREVITY)
    public class BasicModule implements LoginModule
    private NameCallback strName;
    private PasswordCallback strPass;
    private CallbackHandler myCB;
    private Subject subj;
             //INITIALIZE THIS MODULE
               public void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options)
                      try
                           //SET SUBJECT
                             subj = subject;  //NOTE: THIS GIVES YOU REFERENCE
    TO LOGIN CONTEXT'S SUBJECT
                                                     // AND ALLOWS YOU TO PASS
    IT BACK TO THE LOGIN CONTEXT
                           //SET CALLBACKHANDLERS
                             strName = new NameCallback("Your Name: ");
                             strPass = new PasswordCallback("Password:", false);
                             Callback[] cb = { strName, strPass };
                           //HANDLE THE CALLBACKS
                             callbackHandler.handle(cb);
                      } catch (Exception e) { System.out.println(e); }
         //LOG THE USER IN
           public boolean login() throws LoginException
              //TEST TO SEE IF SUBJECT HOLDS ANYTHING YET
              System.out.println( "PRIOR TO AUTHENTICATION, SUBJECT HOLDS: " +
    subj.getPrincipals().size() + " Principals");
              //SUBJECT AUTHENTICATED - BECAUSE SUBJECT NOW HOLDS THE PRINCIPAL
               MyPrincipal m = new MyPrincipal("Admin");
               subj.getPrincipals().add(m);
               return true;
             public boolean commit() throws LoginException
                   return true;
        }(Sorry for all that code)
    I tested the above code, and it fully associates the Subject (and its principal) with the LoginContext. So my question is, where in the process (and code) can we put the LoginContext and Modules so that a client cannot
    do this? With the above example, there is no Security. (a call to: myLoginContext.getSubject().doAs(...) will work)
    I think the key here is to understand JAAS's plug-in security model to mean:
    (Below are my words)
    The point of JAAS is to allow an application to use different ways of authenticating without changing the application's code, but NOT to allow the user to authenticate however they want.
    In WebLogic's example, they unfortunately seem to have used the latter understanding, i.e. "allow the user to authenticate however they want."
    That, as I think I've shown, is not security. So how do we solve this? We need to put JAAS on the server side (with no direct JAAS client-side), and that includes the LoginModules as well as LoginContext. So for an EJB Server this means that the same internal permission
    checking code can be used regardless of whether a client connects through
    RMI/RMI-IIOP/JEREMIE (etc). It does NOT mean that the client gets to choose
    how they authenticate (except by choosing YOUR set ways).
    Before we even deal with a serialized subject, we need to see how JAAS can
    even be used on the back-end of an RMI (RMI-IIOP/JEREMIE) application.
    I think what needs to be done, is the client needs to have the stubs for our
    LoginModule, LoginContext, CallBackHandler, CallBacks. Then they can put
    their info into those, and everything is handled server-side. So they may
    not even need to send a Subject across anyways (but they may want to as
    well).
    Please let me know if anyone sees this problem too, or if I am just completely
    off track with this one. I think figuring out how to do JAAS as though
    everything were local, and then putting RMI (or whatever) on top is the
    first thing to tackle.

    Send this to:
    newsgroups.bea.com / security-group.

  • Configuring kodo-jdo-2.5.3 with weblogic 8.1 using JCA

    Hi there.
    I am trying to configure kodo-jdo-2.5.3 in WebLogic 8.1 using JCA method.
    The issue I got was that I got DB authentication failed. I have tested my
    JDBC connect -- working fine, I have turned on JDBC log in WL, it looks
    fine.
    It looks like that KODO was still trying to create its own JDBC connection
    even I have specified
    <config-property>
    <description>The JNDI name of the connection factory to use for
    obtaining connections.</description>
    <config-property-name>ConnectionFactoryName</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>datasource.oracle9</config-property-value>
    </config-property>
    "datasource.oracle9" is the JNDI name of my data source.
    The error message is the following. I will really appreciate your help.
    Melvin
    Oct 19, 2003 4:20:53 AM com.solarmetric.kodo.impl.jdbc.RegisterListener
    registerClass
    SEVERE: com.solarmetric.kodo.runtime.FatalDataStoreException:
    java.sql.SQLException: User: melvin, f
    ailed to be authenticated. [code=0;state=null]
    NestedThrowables:
    java.sql.SQLException: User: melvin, failed to be authenticated.
    com.solarmetric.kodo.runtime.FatalDataStoreException:
    java.sql.SQLException: User: melvin, failed to
    be authenticated. [code=0;state=null]
    NestedThrowables:
    java.sql.SQLException: User: melvin, failed to be authenticated.
    at
    com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwFatal(SQLExceptions.java:58)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFacto
    ry.java:212)
    at
    com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfigurat
    ion.java:370)
    at
    com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClassInternal(JDBCPe
    rsistenceManagerFactory.java:455)
    at
    com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClass(JDBCPersistenc
    eManagerFactory.java:338)
    at
    com.solarmetric.kodo.impl.jdbc.RegisterListener.registerClass(RegisterListener.java:53)
    at
    javax.jdo.spi.JDOImplHelper.registerClass(JDOImplHelper.java:269)
    at samples.j2ee.Car.<clinit>(Car.java)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:140)
    at samples.j2ee.ejb.CarBean.class$(CarBean.java:11)
    at samples.j2ee.ejb.CarBean.list(CarBean.java:136)
    at
    samples.j2ee.ejb.CarEJB_pgfrtx_EOImpl.list(CarEJB_pgfrtx_EOImpl.java:201)
    at jsp_servlet.__index._jspService(__index.java:170)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
    at
    weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.jav
    a:1053)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:431)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
    at
    weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
    ontext.java:6310)
    at
    weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
    at
    weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
    at
    weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:36
    22)
    at
    weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
    NestedThrowablesStackTrace:
    java.sql.SQLException: User: melvin, failed to be authenticated.
    at
    weblogic.jdbc.common.internal.RmiDataSource.getSubject(RmiDataSource.java:257)
    at
    weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:188)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.DataSourceConnector.getConnection(DataSourceConnec
    tor.java:63)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFacto
    ry.java:179)
    at
    com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfigurat
    ion.java:370)
    at
    com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClassInternal(JDBCPe
    rsistenceManagerFactory.java:455)
    at
    com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClass(JDBCPersistenc
    eManagerFactory.java:338)
    at
    com.solarmetric.kodo.impl.jdbc.RegisterListener.registerClass(RegisterListener.java:53)
    at
    javax.jdo.spi.JDOImplHelper.registerClass(JDOImplHelper.java:269)
    at samples.j2ee.Car.<clinit>(Car.java)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:140)
    at samples.j2ee.ejb.CarBean.class$(CarBean.java:11)
    at samples.j2ee.ejb.CarBean.list(CarBean.java:136)
    at
    samples.j2ee.ejb.CarEJB_pgfrtx_EOImpl.list(CarEJB_pgfrtx_EOImpl.java:201)
    at jsp_servlet.__index._jspService(__index.java:170)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
    at
    weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.jav
    a:1053)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:431)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
    at
    weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
    ontext.java:6310)
    at
    weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
    at
    weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
    at
    weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:36
    22)
    at
    weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
    <Oct 19, 2003 4:20:53 AM CDT> <Info> <EJB> <BEA-010051> <EJB Exception
    occurred during invocation fr
    om home: samples.j2ee.ejb.CarEJB_pgfrtx_HomeImpl@1c059f6 threw exception:
    com.solarmetric.kodo.runti
    me.FatalDataStoreException: java.sql.SQLException: User: melvin, failed to
    be authenticated. [code=0
    ;state=null]
    NestedThrowables:
    java.sql.SQLException: User: melvin, failed to be authenticated.
    com.solarmetric.kodo.runtime.FatalDataStoreException:
    java.sql.SQLException: User: melvin, failed to
    be authenticated. [code=0;state=null]
    NestedThrowables:
    java.sql.SQLException: User: melvin, failed to be authenticated.
    at
    com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwFatal(SQLExceptions.java:58)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFacto
    ry.java:212)
    at
    com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfigurat
    ion.java:370)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getDictionary(JDBCStoreManager.ja
    va:753)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getClassMapping(JDBCStoreManager.
    java:1023)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getClassMapping(JDBCStoreManager.
    java:1037)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCExtent.getResultList(JDBCExtent.java:71)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCExtent.getIterator(JDBCExtent.java:47)
    at
    com.solarmetric.kodo.runtime.ExtentImpl$MultipleSubclassIterator.newIterator(ExtentImpl.j
    ava:344)
    at serp.util.MultiIterator.setIterator(MultiIterator.java:74)
    at serp.util.MultiIterator.hasNext(MultiIterator.java:29)
    at serp.util.LookaheadIterator.setNext(LookaheadIterator.java:133)
    at
    serp.util.LookaheadIterator.initialize(LookaheadIterator.java:118)
    at serp.util.LookaheadIterator.hasNext(LookaheadIterator.java:48)
    at serp.util.MultiIterator.setIterator(MultiIterator.java:73)
    at serp.util.MultiIterator.hasNext(MultiIterator.java:29)
    at
    com.solarmetric.kodo.runtime.ExtentImpl$TransactionAwareIterator.hasNext(ExtentImpl.java:
    403)
    at samples.j2ee.ejb.CarBean.list(CarBean.java:138)
    at
    samples.j2ee.ejb.CarEJB_pgfrtx_EOImpl.list(CarEJB_pgfrtx_EOImpl.java:201)
    at jsp_servlet.__index._jspService(__index.java:170)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
    at
    weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.jav
    a:1053)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:431)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
    at
    weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
    ontext.java:6310)
    at
    weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
    at
    weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
    at
    weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:36
    22)
    at
    weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
    NestedThrowablesStackTrace:
    java.sql.SQLException: User: melvin, failed to be authenticated.
    at
    weblogic.jdbc.common.internal.RmiDataSource.getSubject(RmiDataSource.java:257)
    at
    weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:188)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.DataSourceConnector.getConnection(DataSourceConnec
    tor.java:63)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFacto
    ry.java:179)
    at
    com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfigurat
    ion.java:370)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getDictionary(JDBCStoreManager.ja
    va:753)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getClassMapping(JDBCStoreManager.
    java:1023)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.getClassMapping(JDBCStoreManager.
    java:1037)

    Alex Robbins wrote:
    Try removing <authentication-mechanism> from the ra.xml file of the Kodo
    JCA connector. Then it won't try to authenticate against the WL security
    realm. (If you want connector-level authentication as well as DB-conn
    authentication i think you'll have to configure WL security. I don't know
    how). This worked for me.
    Alex.Hi, The following is the ra.xml, please see any problem.
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE connector PUBLIC '-//Sun Microsystems, Inc.//DTD Connector
    1.0//EN' 'http://java.sun.com/dtd/connector_1_0.dtd'>
    <connector>
    <display-name>KodoJDO</display-name>
    <description>Resource Adapter for integration of the Kodo Java Data
    Objects (JDO) implementation with J2EE 1.3 compliant managed
    environments</description>
    <icon>
    <small-icon>kodo16.gif</small-icon>
    <large-icon>kodo32.gif</large-icon>
    </icon>
    <vendor-name>Solarmetric, Inc.</vendor-name>
    <spec-version>1.0</spec-version>
    <eis-type>jdo</eis-type>
    <version>1.0</version>
    <license>
    <description>See http://www.solarmetric.com for terms and license
    conditions.</description>
    <license-required>true</license-required>
    </license>
    <resourceadapter>
    <managedconnectionfactory-class>com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl</managedconnectionfactory-class>
    <connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface>
    <connectionfactory-impl-class>com.solarmetric.kodo.impl.jdbc.ee.JDOConnectionFactory</connectionfactory-impl-class>
    <connection-interface>javax.resource.cci.Connection</connection-interface>
    <connection-impl-class>com.solarmetric.kodo.ee.EEPersistenceManager</connection-impl-class>
    <transaction-support>XATransaction</transaction-support>
    <config-property>
    <description>The number of hard references to cached objects that the
    PersistenceManager's cache will retain (in addition to the soft reference
    cache that it maintains). Setting this to a higher value will result in
    more objects being retained in the cache, at the cost of utilizing more
    memory resources. Setting it to -1 will cause the PersistenceManager to
    maintain hard references only. This will result in better performance, but
    can have adverse effects on memory usage.</description>
    <config-property-name>CacheReferenceSize</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>1000</config-property-value>
    </config-property>
    <config-property>
    <description>The class name of ether the JDBC java.sql.Driver, or an
    instance of a javax.sql.DataSource to use to connect to the data
    source.</description>
    <config-property-name>ConnectionDriverName</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The JNDI name of the connection factory to use for
    finding non-transactional connections. If specified, this is the
    connection that will be used for access for obtaining sequence
    numbers.</description>
    <config-property-name>ConnectionFactory2Name</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>jdbc/petshop</config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to be passed to
    the JDBC Driver when obtaining a Connection for the ConnectionFactory2
    (which will be used to obtain sequence numbers). Properties are of the
    form "key=value". If a javax.sql.DataSource class is defined in the
    javax.jdo.option.ConnectionDriverName property, then this property will be
    used to set bean-like properties in the DataSource instance upon creation.
    These properties vary depending on the DataSource in use: see the
    documentation for your DataSource for details on the properties to
    use.</description>
    <config-property-name>ConnectionFactory2Properties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The JNDI name of the connection factory to use for
    obtaining connections.</description>
    <config-property-name>ConnectionFactoryName</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>PetShopXADataSource</config-property-value>
    </config-property>
    <config-property>
    <description>The password for the user specified in
    ConnectionUserName</description>
    <config-property-name>ConnectionPassword</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to be passed to
    the JDBC Driver when obtaining a Connection. Properties are of the form
    "key=value". If a javax.sql.DataSource class is defined in the
    javax.jdo.option.ConnectionDriverName property, then this property will be
    used to set bean-like properties in the DataSource instance upon creation.
    These properties vary depending on the DataSource in use: see the
    documentation for your DataSource for details on the properties to
    use.</description>
    <config-property-name>ConnectionProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The connection retain mode. Possible options are
    "persistence-manager", "transaction", and "on-demand". Default value is
    "on-demand".</description>
    <config-property-name>ConnectionRetainMode</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>on-demand</config-property-value>
    </config-property>
    <config-property>
    <description>The number of seconds to wait between testing
    connections retrieved from the connection pool. Only valid when using the
    built-in Kodo connection pooling.</description>
    <config-property-name>ConnectionTestTimeout</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>10</config-property-value>
    </config-property>
    <config-property>
    <description>The URL for the data source.</description>
    <config-property-name>ConnectionURL</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The username for the connection listed in
    ConnectionURL.</description>
    <config-property-name>ConnectionUserName</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The name of the class to use for caching of data loaded
    from the data store. Must implement
    com.solarmetric.kodo.runtime.datacache.DataCache.</description>
    <config-property-name>DataCacheClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to pass to the
    class defined in com.solarmetric.kodo.DataCacheClass upon
    initialization.</description>
    <config-property-name>DataCacheProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The name of the default class to use for mapping
    persistent classes to the database. Must extend
    com.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping.</description>
    <config-property-name>DefaultClassMappingClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>com.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping</config-property-value>
    </config-property>
    <config-property>
    <description>The number of seconds that data in the data cache is
    valid for. A value of 0 or less means that by default, cached data does
    not time out.</description>
    <config-property-name>DefaultDataCacheTimeout</config-property-name>
    <config-property-type>java.lang.Double</config-property-type>
    <config-property-value>0.0</config-property-value>
    </config-property>
    <config-property>
    <description>The number of rows that will be pre-fetched when an
    element in a Query result is accessed.</description>
    <config-property-name>DefaultFetchBatchSize</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>10</config-property-value>
    </config-property>
    <config-property>
    <description>The threshold below which result lists will be
    completely instantiated upon their creation. A value of -1 will always
    force all results to be completely instantiated, thus disabling lazy
    result loading.</description>
    <config-property-name>DefaultFetchThreshold</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>30</config-property-value>
    </config-property>
    <config-property>
    <description>The name of the default class to use for managing
    subclass indicator columns. Must implement the
    com.solarmetric.kodo.impl.jdbc.ormapping.SubclassProvider interface. See
    custom class indicator documentation for more information about subclass
    providers.</description>
    <config-property-name>DefaultSubclassProviderClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>com.solarmetric.kodo.impl.jdbc.ormapping.SubclassProviderImpl</config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to pass to the
    class defined in
    com.solarmetric.kodo.impl.jdbc.DefaultSubclassProviderClass upon
    initialization.</description>
    <config-property-name>DefaultSubclassProviderProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The DBDictionary to use for this configuration. This is
    auto-detected based on the setting of javax.jdo.option.ConnectionURL, so
    you need only set this to override the default with your own custom
    DBDictionary or if you are using an unrecognized driver.</description>
    <config-property-name>DictionaryClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of name-value properties
    settings to pass to the dictionary defined by
    com.solarmetric.kodo.impl.jdbc.DictionaryClass. Many of the DBDictionary
    options are automatically configured by concrete subclasses of
    GenericDictionary. The defaults can, however, be overridden by using this
    property.</description>
    <config-property-name>DictionaryProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>If true, then Kodo JDO will allow the use of query
    filter extensions. See the query extensions documentation for more
    information.</description>
    <config-property-name>EnableQueryExtensions</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of fetch group names that
    PersistenceManagers will load by default when loading data from the
    database.</description>
    <config-property-name>FetchGroups</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>If true, then all fields of all classes in a given
    inheritance hierarchy will by default map into the least-derived type's
    default primary table. If false then a new default primary table will be
    created for each class in the inheritance hierarchy, and each type's
    declared fields will map to that table by default.</description>
    <config-property-name>FlatInheritanceMapping</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>true</config-property-value>
    </config-property>
    <config-property>
    <description>A String value indicating whether or not Kodo should
    automatically flush modifications to the data store before executing
    queries.</description>
    <config-property-name>FlushBeforeQueries</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>with-connection</config-property-value>
    </config-property>
    <config-property>
    <description>If false, then the JDO implementation must consider
    modifications, deletions, and additions in the PersistenceManager
    transaction cache when executing a query inside a transaction. Else, the
    implementation is free to ignore the cache and execute the query directly
    against the data store.</description>
    <config-property-name>IgnoreCache</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>The license key provided to you by SolarMetric. Keys
    are available at www.solarmetric.com</description>
    <config-property-name>LicenseKey</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>xxxx</config-property-value>
    </config-property>
    <config-property>
    <description>The name of the class to use for obtaining a reference
    to the transaction manager in an enterprise environment. Must implement
    the com.solarmetric.kodo.ee.ManagedRuntime interface.</description>
    <config-property-name>ManagedRuntimeClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>com.solarmetric.kodo.ee.AutomaticManagedRuntime</config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to pass to the
    class defined in com.solarmetric.kodo.ManagedRuntimeClass upon
    initialization.</description>
    <config-property-name>ManagedRuntimeProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The maximum number of connections to pool. If all of
    these are in use, then PersistenceManager instances must wait for a
    connection to become available. This option has been removed from the
    specification, but we still use the javax.jdo.option for backwards
    compatibility.</description>
    <config-property-name>MaxPool</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>200</config-property-value>
    </config-property>
    <config-property>
    <description>The minimum number of connections to keep in the pool.
    This option has been removed from the specification, but we still use the
    javax.jdo.option for backwards compatibility.</description>
    <config-property-name>MinPool</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>2</config-property-value>
    </config-property>
    <config-property>
    <description>The number of milliseconds to wait for a pooled
    connection before throwing an exception if the pool is empty. This option
    has been removed from the specification, but we still use the
    javax.jdo.option for backwards compatibility.</description>
    <config-property-name>MsWait</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>30000</config-property-value>
    </config-property>
    <config-property>
    <description>If true, then the application plans to have multiple
    threads simultaneously accessing a single PersistenceManager, so measures
    must be taken to ensure that the implementation is thread-safe. Otherwise,
    the implementation need not address thread safety.</description>
    <config-property-name>Multithreaded</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>If true, then it is possible to read persistent data
    outside the context of a transaction. Otherwise, a transaction must be in
    progress in order read data.</description>
    <config-property-name>NontransactionalRead</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>true</config-property-value>
    </config-property>
    <config-property>
    <description>If true, then it is possible to write to fields of a
    persistent-nontransactional object when a transaction is not in progress.
    If false, such a write will result in a JDOUserException.</description>
    <config-property-name>NontransactionalWrite</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>Selects between optimistic and pessimistic (data store)
    transactional modes.</description>
    <config-property-name>Optimistic</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>The name of the class that the
    PersistenceManagerFactory should create when creating a new
    PersistenceManagerImpl. Must extend
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.</description>
    <config-property-name>PersistenceManagerClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The name of the concrete implementation of
    javax.jdo.PersistenceManagerFactory that
    javax.jdo.JDOHelper.getPersistenceManagerFactory () should create. For
    Kodo JDO, this should be
    com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory or
    com.solarmetric.kodo.impl.jdbc.ee.EEPersistenceManagerFactory, or a custom
    extension of one of these types.</description>
    <config-property-name>PersistenceManagerFactoryClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory</config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to pass to the
    class defined in com.solarmetric.kodo.PersistenceManagerClass upon
    initialization.</description>
    <config-property-name>PersistenceManagerProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of classes that will be
    initialized whenever a new PersistenceManager is instantiated. This can be
    used to get around issues with application identity classes not being
    associated with their respective persistent classes.</description>
    <config-property-name>PersistentTypes</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The name of the class to use to proxy second class
    objects in managed instances. Must implement
    com.solarmetric.kodo.util.ProxyManager.</description>
    <config-property-name>ProxyManagerClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>com.solarmetric.kodo.util.SimpleProxyManager</config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to pass to the
    class defined in com.solarmetric.kodo.ProxyManagerClass upon
    initialization.</description>
    <config-property-name>ProxyManagerProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The name of the class to use for caching of queries
    loaded from the data store. Must implement
    com.solarmetric.kodo.runtime.datacache.QueryCache.</description>
    <config-property-name>QueryCacheClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>com.solarmetric.kodo.runtime.datacache.query.QueryCacheImpl</config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to pass to the
    class defined in com.solarmetric.kodo.QueryCacheClass upon
    initialization.</description>
    <config-property-name>QueryCacheProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>A list of query filter listeners to add to the default
    list of extensions. Ignored if com.solarmetric.kodo.EnableQueryExtensions
    is false.</description>
    <config-property-name>QueryFilterListeners</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The name of the class to use for communicating commit
    information among JVMs. Must implement
    com.solarmetric.kodo.runtime.event.RemoteCommitProvider.</description>
    <config-property-name>RemoteCommitProviderClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to pass to the
    class defined in com.solarmetric.kodo.RemoteCommitProviderClass upon
    initialization.</description>
    <config-property-name>RemoteCommitProviderProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>If true, then fields in a persistence-capable object
    that have been changed during a transaction will be rolled back to their
    original values upon a rollback. Otherwise, the values will not be changed
    upon rollback.</description>
    <config-property-name>RestoreValues</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>true</config-property-value>
    </config-property>
    <config-property>
    <description>The name of the class that will be used as the
    Collection implementation for returning ResultList instances. It must be
    an instance of
    com.solarmetric.kodo.runtime.objectprovider.ResultList.</description>
    <config-property-name>ResultListClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The property string used to configure the instance of
    the ResultListClass.</description>
    <config-property-name>ResultListProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>If true, then fields in a persistence-capable object
    that have been read during a transaction must be preserved in memory after
    the transaction commits. Otherwise, persistence-capable objects must
    transition to the hollow state upon commit, meaning that subsequent reads
    will result in a database round-trip.</description>
    <config-property-name>RetainValues</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>The name of the class to use for generating sequence
    numbers when using data store identity. Must implement the
    com.solarmetric.kodo.impl.jdbc.SequenceFactory interface.</description>
    <config-property-name>SequenceFactoryClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory</config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to pass to the
    class defined in com.solarmetric.kodo.impl.jdbc.SequenceFactoryClass upon
    initialization.</description>
    <config-property-name>SequenceFactoryProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The class names of a SQLExecutionListener
    implementation to install on the SQLExecutionManager.</description>
    <config-property-name>SQLExecutionListenerClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The name of a custom SQLExecutionManager to be used for
    all issuance of SQL to the data store. Must implement
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManager.</description>
    <config-property-name>SQLExecutionManagerClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl</config-property-value>
    </config-property>
    <config-property>
    <description>The size of the PreparedStatement cache that is
    maintained in the DataSource implementation.</description>
    <config-property-name>StatementCacheMaxSize</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>70</config-property-value>
    </config-property>
    <config-property>
    <description>The time, in seconds, after which a JDBC query will be
    aborted if it has not yet returned any values. This value is simply passed
    to the JDBC driver's Statement.setTimeout method; Kodo does not perform
    any addition timeout actions. Note that many JDBC drivers either ignore
    this request, or improperly handle it, which may result in application
    deadlocks.</description>
    <config-property-name>StatementExecutionTimeout</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>-1</config-property-value>
    </config-property>
    <config-property>
    <description>If true, the Kodo runtime will automatically attempt to
    refresh the database schema when persistent classes are referenced,
    allowing the developer to bypass the schematool step. This property is
    only intended to be used for development. As automatic schema migration
    can result in data loss, this feature should never be enabled on a
    production system. Furthermore, this feature has serious adverse affects
    on Kodo's runtime performace. Ensure that it is disabled before doing any
    performance analysis.</description>
    <config-property-name>SynchronizeSchema</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>The name of the class to use to store
    persistence-capable objects involved in a PM's transaction cache. Must
    implement com.solarmetric.kodo.runtime.StateManagerSet.</description>
    <config-property-name>TransactionCacheClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>com.solarmetric.kodo.runtime.FifoStateManagerSet</config-property-value>
    </config-property>
    <config-property>
    <description>A space-separated list of properties to pass to the
    class defined in com.solarmetric.kodo.TransactionCacheClass upon
    initialization.</description>
    <config-property-name>TransactionCacheProperties</config-property-name>
    <config-property-type>java.lang.String</config-property

  • Configure Visualvm with weblogic 10.0

    I followed the procedure below to configure VisualVm with weblogic 10.0
    I have installed jdk1.6_18 in /usr/jdk1.6_18 on solaris 10.0.
    created jstatd.all.policy file with entry
    grant codebase "file:${java.home}/../lib/tools.jar" {
    permission java.security.AllPermission;
    in /usr/jdk1.6_18/bin
    executed below line from the same where i have the jstatd.all.policy file
    jstatd -J-Djava.security.policy=jstatd.all.policy
    I am unable to enable jstatd i getting the following error:
    ./jstatd -J-Djava.security.policy=java.all.policy
    Error occurred during initialization of VM
    java/lang/NoClassDefFoundError: java/lang/Object
    I have followed the below link to configure
    http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14287864
    Any help would be greatly appreciated.

    Hi,
    Step1). Please open "java.policy" file from the following location <JAVA_HOME>\jre\lib\security
    Step2). // Standard extensions get all permissions by default and add the Highlighted Code Snippet there at the TOP below is the modified content of "java.policy" file
    // Standard extensions get all permissions by default
    <font color=red>
    grant codeBase "file:C:/bea103/jdk160_05/lib/tools.jar" {
    permission java.security.AllPermission;
    </font>
    grant codeBase "file:${{java.ext.dirs}}/*" {
         permission java.security.AllPermission;
    // default permissions granted to all domains
    grant {
         // Allows any thread to stop itself using the java.lang.Thread.stop()
         // method that takes no argument.
         // Note that this permission is granted by default only to remain
         // backwards compatible.
         // It is strongly recommended that you either remove this permission
         // from this policy file or further restrict it to code sources
         // that you specify, because Thread.stop() is potentially unsafe.
         // See "http://java.sun.com/notes" for more information.
         permission java.lang.RuntimePermission "stopThread";
         // allows anyone to listen on un-privileged ports
         permission java.net.SocketPermission "localhost:1024-", "listen";
         // "standard" properies that can be read by anyone
         permission java.util.PropertyPermission "java.version", "read";
         permission java.util.PropertyPermission "java.vendor", "read";
         permission java.util.PropertyPermission "java.vendor.url", "read";
         permission java.util.PropertyPermission "java.class.version", "read";
         permission java.util.PropertyPermission "os.name", "read";
         permission java.util.PropertyPermission "os.version", "read";
         permission java.util.PropertyPermission "os.arch", "read";
         permission java.util.PropertyPermission "file.separator", "read";
         permission java.util.PropertyPermission "path.separator", "read";
         permission java.util.PropertyPermission "line.separator", "read";
         permission java.util.PropertyPermission "java.specification.version", "read";
         permission java.util.PropertyPermission "java.specification.vendor", "read";
         permission java.util.PropertyPermission "java.specification.name", "read";
         permission java.util.PropertyPermission "java.vm.specification.version", "read";
         permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
         permission java.util.PropertyPermission "java.vm.specification.name", "read";
         permission java.util.PropertyPermission "java.vm.version", "read";
         permission java.util.PropertyPermission "java.vm.vendor", "read";
         permission java.util.PropertyPermission "java.vm.name", "read";
    Step3). run the "jstack"
    Thanks
    Jay SenSharma
    http://jaysensharma.wordpress.com  (WebLogic Wonders Are Here)

  • What's the point of Weblogic JAAS authentication?

    Hello, I'm looking into one way authentication using weblogic and JAAS,
    Weblogic say this is the preferred mechanism, however I can't see the
    advantages. My (ok, limited) understanding of it is thus:
    The advantage of JAAS is that you can specify different login modules to
    utilise different types of authentication. However authentication to a
    weblogic server will only work by calling
    weblogic.security.auth.Authenticate.authenticate (due to weblogic's own
    implementation of the javax.security.auth. classes), thus only one
    loginmodule is available.
    The ability to use different authentication types is provided by the
    application server by using/creating different realms. The client possibly
    being able to specify different authentication by one of the arguments to a
    custom realm(?).
    Thus why bother with JAAS seeing that it doesn't seem to offer anything
    extra over JNDI authentication and requires more code?
    Thanks, any ideas appreciated.
    Alan.

    Good point.
    "James" <[email protected]> wrote in message
    news:3c506266$[email protected]..
    This may not apply to you, but I have to consider the need to remain
    portable between different vendor's application servers. WebLogic's
    proprietary realm architecture makes it a pain to get up and going in a
    Websphere or a Oracle AS. So I see that as a major advantage.
    James
    Viewlocity, Inc.
    http://www.viewlocity.com
    "Alan Phillips" <alan.phillips@|remove|ftid.com> wrote in message
    news:[email protected]..
    Hello, I'm looking into one way authentication using weblogic and JAAS,
    Weblogic say this is the preferred mechanism, however I can't see the
    advantages. My (ok, limited) understanding of it is thus:
    The advantage of JAAS is that you can specify different login modules to
    utilise different types of authentication. However authentication to a
    weblogic server will only work by calling
    weblogic.security.auth.Authenticate.authenticate (due to weblogic's own
    implementation of the javax.security.auth. classes), thus only one
    loginmodule is available.
    The ability to use different authentication types is provided by the
    application server by using/creating different realms. The client
    possibly
    being able to specify different authentication by one of the argumentsto
    a
    custom realm(?).
    Thus why bother with JAAS seeing that it doesn't seem to offer anything
    extra over JNDI authentication and requires more code?
    Thanks, any ideas appreciated.
    Alan.

Maybe you are looking for