Arun Somasundaram

Ranch Hand
+ Follow
since Jul 25, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Arun Somasundaram

Cheers Tim, nice explanation. Just wanted to confirm the setup I shared works. There was a configuration mistake with one of the <Realm> attributes which prevented successful LDAP authentication.

The corrected Realm looks like this. I have removed the userPattern and replaced it with userBase and userSearch. In the original config I have mixed userPattern and userSubtree which doesn't go together as per the tomcat config spec. It's either userPattern or userBase, userSearch and userSubtree to locate a user based on DN in directory server.


I have a follow up question, if it is ok to continue that in this thread. The use case is to use LDAP only for authentication, once authenticated I would like to apply a role only to a certain subset of authenticated users i.e. something of the sort that roles will be locally maintained in tomcat in a file. I suppose the tomcat-users.xml is not effective here as the authentication happens through JNDIRealm and not through the MemoryRealm. Happy to create a new post if the policy does not allow to continue this discussion in this thread.
3 years ago
Thanks for your response, Tim. Yes, I am just testing the migrations in a lower environment. Sorry, I have not been more clear about the setup structure.

As you could see from my post that I have defined a JNDIRealm in context.xml. That context.xml has been placed in CATALINA_BASE/webapps/myapp/META-INF as I expect only "myapp" to use LDAP authentication.

The web.xml as seen in my post above is placed in CATALINA_BASE/webapps/myapp/WEB-INF.

My query is how does the login-config in web.xml would know it has to use the JNDI Realm for authentication if there is no scope to define a name for <Realm/> defined in META-INF/context.xml? I interpret from your reply, since the auth-method in login-config of web.xml is set to BASIC, the container would automatically pick up the JNDI Realm defined in META-INF/context.xml?
3 years ago
Hi Ranch members,

I am migrating configurations from JBoss to Tomcat 8.5. I would like anybody accessing the app to be authenticated through LDAP via BASIC authentication. Unlike in Jboss 6.x, in Tomcat 8.5 I don't see the Realm name attribute available which can be then referred in the login-config of the app's web.xml instructing the container to use the specified Realm for authentication. In the below example, I have supplied a Realm name in the <login-config> to use which is "MySecurityRealm" as seen in the web.xml, however I don't see a way to map that name to <Realm/> as the name attribute is not supported. In this instance, how to instruct the login module to use the JNDI Realm for authentication? Any inputs is much appreciated.

Here is the link to apache configuration reference for 8.5 - http://tomcat.apache.org/tomcat-8.5-doc/config/realm.html#JNDI_Directory_Realm_-_org.apache.catalina.realm.JNDIRealm

In the web app's context.xml I have the Realm defined as below.



In the web app's web.xml, I have the following security configuration.




Many thanks
Arun
3 years ago
Hi all,
I have uderstood all the J2EE design patterns except the Context Object pattern(implementaion part). Can any one give me a simple example for J2EE Context Object deisgn pattern. I have understood Context Objects are used to share infrastructure information across the tiers in a protocol independent way. Also I have undestood It's similar to the Transfer Object but the difference is , the Transfer Object is used for carrying business information across tiers. What infrastructure (security,request,configuration) info is carried by a Context Object? Any simple example on this pattern would be very much appreciated rather than an explanation thanks in advance

D. Ogranos wrote:
They enable the compiler to spot obvious mistakes like inserting integers into string lists. But on the byte code level there isn't a difference between a generic and non-generic list.



I haven't said at byte code level there is a difference between generic and non generic list. It's a very basic thing that the generics are used by the compiler to ensure type safety.I don't suppose you have understood my whole point Can any one else give an explanation for it?
14 years ago

In the second case the compiler creates code that just takes Object elements from the list, and passes them to the PrintStream.println(Object) method



In the second case why the compiler doesn't tries to make sure it actually has Integer objects with the checkcast instruction since the <Integer> generic type is used.
In the first case why the compiler tries to make sure it actually has String objects with the checkcast instruction. If the compiler does make sure about the type of the objects in the first case it must also make sure about the type of the objects in the second case because in the both the cases the collection uses generic types.

Note:

println(int x); is also available
14 years ago

I assume that in the second case, the compiler ("knowing" that he has a list of Integers) just creates code that uses the "toString()" method of the objects in the list. So the code will run without problems.

For the first case? Again assuming, the compiler expects String objects, so he doesn't use the toString() method. Then the virtual machine finds that the object type is in fact not String. Integer is not convertible to String so you get the exception.



I am not convinced with the second explanation. Is the above two explanations incorrect? if it is incorrect then what could be the reason for the first case to fail?
14 years ago
Ofcourse if the List parameter in the addObjects() uses the <Integer> generic code then the compiler complains about the error. My doubt is why there is no exception generated at runtime when the List type is <Integer> in the main().
14 years ago
I encountered the below mentioned exception when I executed the following code :



Output:

Hi
Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
at pack1.TestList1.main(TestList1.java:12)


But the following code just works fine when the generic type of the List is <Integer> and produces the below mentioned output



Output :

Hi
52
589.235


It is obvious that the generics is used by the compiler at compile time and not by the JVM to ensure the post Java 5 code works with the Pre Java 5 code. It is also clear that the compiler induces the code for type casting in the list.get() when the list uses generics. Here I would like to know why the TestList1 generates the runtime exception and how the TestList2 runs successfully?
14 years ago
Hi,

I have encountered the below mentioned Exception when I try to run the following code.Here the server is running in a remote system:

SQLException : IO exception network adapter couldn't establish connection with the database





What can be done to resolve this problem?
I tried to parse a XML file and print the contents in the console, but I got the following error:-



The source code is as follws:-

XMLTest.java



SAXHandler.java



[/CODE]
Hi i am getting the following exception when i run the login.jsp. I use JDBC ODBC bridge driver to connect to the database.The database I use is MS Access.There is no error in jsp but still I am getting the exception

java.sql.SQLException: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

Here is the source cose for login.jsp:-



I set the user DSN name as forum.

Any one Help me to come out of this problem.
Ben I have checked the id , and the rs these are not null.But I can't able to find where the actual mistake lies.

Here is the stack trace from my logs directory.

17 years ago
JSP
Ben I have checked the id , and the rs these are not null.But I can't able to find where the actual mistake lies.

Here is the stack trace from my logs directory.
17 years ago
JSP