[Security & JAAS/JBoss] - EJB Session Context Returns Incorrect Principal With Custom
by lent
Hello,
I'm using JBoss Application Server 4.0.5GA.
I wrote a custom login module which accepts either the user credentials or accepts a token which they still pass through the username/password fields. In my login module, when I detect that a token is being passed in, I retrieve the user associated with the token and then login as that user. The user is logged in properly and the correct user (Principal) is returned from the Subject retrieved from PolicyContext and security checks are performed correctly based on this user. However, if I call SessionContext.getPrincipal, then the Pricipal returned is one based on the passed in credentials (in this case the token itself) instead of being the logged in user.
Can anyone shed light on this behaviour? Is there something special that I have to do to ensure that SessionContext has the correct Principal?
Regards,
Len Takeuchi
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148238#4148238
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148238
17 years, 11 months
[JBossWS] - send HaspMap<String, ArrayList<String>> over WS
by peiguo
I have getter/setter defined for properties, but still cannot send object of this class through WS, because the JBOSS generated WSDL doesn't include correct information for ArrayList. How can I correct this?
| package org.jboss.tutorial.webservice.bean;
|
| import java.util.*;
| import java.io.*;
|
| public class Something {
| private int a;
| private double b;
|
|
| private HashMap<String, ArrayList<String>> c;
|
| public Something() {
| a = 1;
| b = 2.0;
| c = new HashMap<String, ArrayList<String>>();
| {
| ArrayList<String> arr = new ArrayList<String>();
| arr.add("This is fun");
| arr.add("Interesting");
| arr.add("What is this?");
| c.put("thought", arr);
| }
| {
| ArrayList<String> arr = new ArrayList<String>();
| arr.add("Kaveh");
| arr.add("David");
| arr.add("Costa");
| c.put("name", arr);
| }
| {
| ArrayList<String> arr = new ArrayList<String>();
| arr.add("green apple");
| arr.add("orange orange");
| arr.add("yellow mango");
| c.put("fruit", arr);
| }
| {
| ArrayList<String> arr = new ArrayList<String>();
| arr.add("they shoot horse");
| arr.add("sleppless in seattle");
| arr.add("thank you for smoking");
| c.put("movie", arr);
| }
| }
|
| public int getA() {
| return a;
| }
|
| public void setA(int a) {
| this.a = a;
| }
|
| public double getB() {
| return b;
| }
|
| public void setB(double b) {
| this.b = b;
| }
|
| public HashMap<String, ArrayList<String>> getC() {
| return c;
| }
|
| public void setC(HashMap<String, ArrayList<String>> c) {
| this.c = c;
| }
|
| public ArrayList<String> getC(String i) {
| return c.get(i);
| }
|
| public void setC(String i, ArrayList<String> c) {
| this.c.put(i, c);
| }
|
| }
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148233#4148233
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148233
17 years, 11 months
[Clustering/JBoss] - Re: Large CPU Increase Using Buddy Session Replication
by bstansberry＠jboss.com
The session gets replicated at most once per request, so if you call setAttribute multiple times in the course of a single request, that doesn't trigger multiple replications. Replication happens after the request thread exits your application code.
Performance tweaks:
1) In jboss-web.xml use replication-trigger SET instead of the default SET_AND_NON_PRIMITIVE_GET. Avoids replication after read-only requests. Only do this if you are sure your code calls setAttribute as part of every request wherein the attribute object is modified.
2) In jboss-web.xml use replication-granularity ATTRIBUTE instead of the default SESSION. Only the attributes made dirty during the request are replicated. SESSION replicates the whole session object.
You could also try replication granularity FIELD, but to use that you'd need to bytecode enhance the classes you store in the session.
Re: other changes:
NONE instead of REPEATABLE_READ will leave you exposed to providing corrupted state during state transfer to a new node that joins the cluster. You can try READ_COMMITTED and see if that gives you an improvment.
REPL_ASYNC is the right choice.
OPTIMISTIC locking will hurt performance of the session repl use case.
Use of a replication queue isn't going to reduce CPU usage. It will just isolate web request threads from having to block waiting to put replication messages on the wire.
Using "interval" SnapshotMode with a snapshot interval of 10000 in jbossweb-tomcat55.sar/META-INF/jboss-service.xml may reduce CPU usage if you make multiple requests that trigger session replication within the 10 seconds. The session will get replicated just once. Of course this or a replication queue both reduce the up-to-date-ness of your replicated data.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148205#4148205
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148205
17 years, 11 months