Sometimes when you are working in Admin mode on DB2 using Configuration Assistant you may accidentally delete the repository information relating to authentication/authorization. This may also happen due to some other reason. If you are able to open Control Center and able to view the database tables using any other user then you are safe.
Right click on the database name and select authorize. Now add the user that you want to give access rights. Similarly add group if you need to provide access to a group. Grant all the required access rights then apply. Restart DB2 server to let the changes take effect this will resolve the problem encountered by you.
Friday, February 19, 2010
Friday, February 5, 2010
Scoped Classloading in WebSphere
Often there are situations when libraries included in the web archive (*.war) file are to be loaded first since their version differs from the version being loaded at enterprise archive (*.ear) level. Lets take an example where X.ear has a war module Z.war. There is a common.jar file which is included at X.ear level. If Z.war wants to provide its own version of the common.jar file then the best way to load this jar file is to use application class loader only to load war module files also. By default application (.ear) has application scope class loader and web module (.war) has its own class loader. The default setting to load classes is “Parent First”. Change this setting to “Parent Last” and also change the setting to single calss loader as per the figure shown below:
There is only one class loader for application and all web module files are also loaded using the same application class loader. This makes web module level classes also visible to the application class loader. As per the hierarchy, parent class loader cannot see classes loaded by the child class loader. In this case all files are loaded by one class loader therefore all classes are visible to each other across the application. Moreover, we have asked it to load child classes first, therefore, it will loaded web module (.war) classes first and then will load the classes defined at application level. This way web module can load its own classes first and hide the classes provided by application.
There is only one class loader for application and all web module files are also loaded using the same application class loader. This makes web module level classes also visible to the application class loader. As per the hierarchy, parent class loader cannot see classes loaded by the child class loader. In this case all files are loaded by one class loader therefore all classes are visible to each other across the application. Moreover, we have asked it to load child classes first, therefore, it will loaded web module (.war) classes first and then will load the classes defined at application level. This way web module can load its own classes first and hide the classes provided by application.
Subscribe to:
Posts (Atom)