[Security & JAAS/JBoss] - Re: JACC on the fly method permission changes not reflecting
by tpnaidu79
According to the JACC spec When I call commit() on a PolicyConfiguration object , the PolicyConfiguration for that contextId is set inService (i.e; made active). I am able to debug and inspect the object state before commit() is called and after it is called. The PolicyConfiguration is reflecting the changes made by me on the fly. However, the behaviour of the container is as per the previous rules given as system startup. I tried to go through the JBossAS source code to figure out what the container was doing on commit(). JBossAS has a class called JBossPolicyConfiguration which is the implementation of PolicyConfiguration interface as defined by the JACC spec. The commit() method in JBossPolicyConfiguration in turn calls the commit() method of a DelegatingPolicy object which in turn calls the commit() method of a ContextPolicy object. The commit() method of a contextPolicy object is an empty method, it has no refresh or anything... in this case how does the container become aware of on the fly ejb method permission changes? The code of what I was trying to explain above is as follows:
JBossPolicyConfiguration code:
public void commit()
throws PolicyContextException
{
if( trace )
log.trace("commit");
validateState("commit");
policy.commit(contextID); // policy is a DelegatingPolicy object
}
DelegatingPolicy code:
public void commit(String contextID)
throws PolicyContextException
{
ContextPolicy policy = getContextPolicy(contextID);
openPolicies.remove(contextID);
activePolicies.put(contextID, policy);
policy.commit();
}
ContextPolicy code:
void commit()
throws PolicyContextException
{
}
I guess I am missing something here can anyone please help me.
Thank you,
-P
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964242#3964242
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964242
19 years, 9 months
[EJB 3.0] - persistent object modification by different threads safe?
by ppphoenixxx
Hi,
according to EJB3-Specs a single EntityManager object isn't thread-safe, so the same EntityManager shouldn't be used by different threads: but what about obtaining a set of persistent objects, applying some changes on them in a *different* thread, where no EntityManager methods are called or used?
Well it works, right out of the box: no EntityManager.clear or merge calls needed in the "original" thread - but I have no idea if this is safe, supposed to work or should be avoided at all costs: I only know that I spare myself a little work by not going the usual way to get me another session bean and obtain an entity manager there.
To give you some details about the application I am writing: Its a standard EJB3 one, with some persistent objects and a built in callback-server which listens in a different thread on a specific network port for connections and should do some persistent operations upon a callback-connection from a client.
Thanks for any input!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964237#3964237
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964237
19 years, 9 months
[EJB/JBoss] - Re: how to solve the problem
by fireflylove
when we swith webs very quickly ,it will occur the error,we don't know whether it is a problem of jboss configuration or something else. The error is as follows:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
java.lang.NullPointerException
org.compiere.model.MTab.toString(MTab.java:2282)
java.lang.String.valueOf(String.java:2577)
java.lang.StringBuilder.append(StringBuilder.java:116)
org.compiere.www.WWindowStatus.toString(WWindowStatus.java:75)
org.compiere.util.WebEnv.getServletInfo(WebEnv.java:659)
org.compiere.util.WebEnv.addFooter(WebEnv.java:490)
org.compiere.util.WebUtil.createResponse(WebUtil.java:485)
org.compiere.util.WebUtil.createErrorPage(WebUtil.java:109)
org.compiere.www.WWindow.doGet(WWindow.java:143)
javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.compiere.www.WFilter.doFilter(WFilter.java:142)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
note The full stack trace of the root cause is available in the Apache Tomcat/5.5.9 logs.
Apache Tomcat/5.5.9
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964233#3964233
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964233
19 years, 9 months