[JBoss Portal] - Expanded Programmatic Security
by brownfielda
I'm attempting to write a portlet that has some additional internal security features. The overall goal will be to allow selected access to MBeans on a remote server (for the time being the goal is to restart foreign JVMs on a WAS 5.1 AS).
At any rate, I was hoping to make the security checks internal to the portlet based on a user's JBP roles. In doing so, I have set up portlet.xml with the following:
. . .
| <security-role-ref>
| <role-name>MyPortletUser</role-name>
| <role-link>User</role-link>
| </security-role-ref>
| <security-role-ref>
| <role-name>MyPortletAdmin</role-name>
| <role-link>Admin</role-link>
| </security-role-ref>
| . . .
With this setup, I can programmatically check if a user is part of a particular group with isUserInRole() for either of the two listed roles. My curiosity is if the roles that I use inside the portlet are strictly defined by the contents of this descriptor.
Would it be possible to test against some other role-name, without editing the descriptor?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064524#4064524
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064524
19Â years
[JBossCache] - CR3 Listener
by FredrikJ
I just upgraded to CR3 and found out that the CacheListener interface has been removed in favor for the annotationbased listener.
Some gripes:
1. Wouldn't this be considered a major api change(?) and as such should not go in between two cr releases?
2. I understand that the benefit is that you can choose to declare only those listener methods you are interested of, thus reducing the amount of empty boilerplate listener methods. However, the downpart is that we are losing type safety here and I personally do not consider this a good bargain.
>From the documentation we can read:
anonymous wrote : Methods annotated as such need to be public, have a void return type, and accept a single parameter of type org.jboss.cache.notifications.event.Event or one of it's subtypes.
Now, isn't this exactly why we have interfaces? An interface enforces signature and types. If we fail to honor the interface we get a nice compilation error, with the annotation based model we will get runtime checking and runtime errors.
If we look at the list of available annotations here http://labs.jboss.com/file-access/default/members/jbosscache/freezone/doc... we can see that the input ot the methods differ. Now I have to switch between my IDE and the documentation to lookup the annotation and what the proper signature is. Should I fail to comply, my IDE will not tell me since there is no compile-time checking.
Furthermore, since there is no longer a CacheListener interface, I cannot use that interface for listener-registration in layers created on top of the cache, forcing me either into allowing Object or creating my own Listener interface which will allow me at least some typesafety. But in the end I will never really know until the cache is started and every possible listener has been registered to the cache, right?
Generally I'm not opposed annotations. I think they do fill a purpose, but I can't seem understand the reasons for this particular design decision.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064522#4064522
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064522
19Â years
Using Java Persistence from web tier
by Mikael Ståldal
What is the correct way of accessing a Java Persistence unit from the web tier (no EJB
session beans)?
I use JBoss 4.2.0.
I can't get the resource injection annotations @PersistenceUnit or @PersistenceContext to
work, so I have done like this:
public class MyServletContextListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
try {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("myunit");
sce.getServletContext().setAttribute(EntityManagerFactory.class.getName(), emf);
}
catch (RuntimeException e) {
throw e;
}
catch (Exception e) {
throw new RuntimeException(e);
}
}
public void contextDestroyed(ServletContextEvent sce) {
EntityManagerFactory emf = (EntityManagerFactory)sce.getServletContext().getAttribute(
EntityManagerFactory.class.getName());
if (emf != null) {
emf.close();
}
}
}
and for each web request I do like this:
EntityManagerFactory emf =
(EntityManagerFactory)context.getAttribute(EntityManagerFactory.class.getName());
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin();
try {
// process the request here...
transaction.commit();
} catch (Exception e) {
transaction.rollback();
// log the error
} finally {
em.close();
}
It seems to work, but is it thread-safe and does it give reasonable performance?
19Â years
[JBoss jBPM] - Re: Error introduced in 3.2.1
by rgullett
Here's a junit test case and an ActionHandler that I wire in. It runs green in 3.2.GA, but fails in 3.2.1.
Thanks,
Randy
package com.jbpm.test;
import java.util.HashMap;
import java.util.Map;
import junit.framework.TestCase;
import org.dom4j.Element;
import org.jbpm.graph.def.ProcessDefinition;
import org.jbpm.graph.exe.ProcessInstance;
import org.jbpm.graph.node.ProcessState;
import org.jbpm.graph.node.SubProcessResolver;
public class JBPMDemoTestCase extends TestCase {
public void testJbpm() {
String className = DoNothingActionHandler.class.getName();
ProcessInstance processInstance = initProcessInstance();
assertEquals("Instance is in wrong state", "start", processInstance.getRootToken()
.getNode().getName());
processInstance.signal();
}
private ProcessInstance initProcessInstance() {
MapBasedProcessRepository mapBasedProcessRepository = new MapBasedProcessRepository();
ProcessState.setDefaultSubProcessResolver(mapBasedProcessRepository);
ProcessDefinition subProcessDefinition =
ProcessDefinition.parseXmlString(
"<process-definition"
+ " xmlns='urn:jbpm.org:jpdl-3.2' name='subProcessName'>"
+ "<start-state name='start'>"
+ ""
+ "</start-state>"
+ "<end-state name='subProcessEndState'></end-state>"
+ ""
+ ""
+ ""
+ ""
+ "</process-definition>");
mapBasedProcessRepository.add(subProcessDefinition);
ProcessDefinition processDefinition =
ProcessDefinition.parseXmlString(
"<process-definition xmlns='' name='processName'>"
+ "<start-state name='start'>"
+ ""
+ "</start-state>"
+ "<end-state name='superProcessEnd'></end-state>"
+ "<process-state name='processState'>"
+ "<sub-process name='subProcessName' />"
+ "" + "</process-state>"
+ ""
+ ""
+ ""
+ ""
+ ""
+ ""
+ ""
+ ""
+ "</process-definition>");
mapBasedProcessRepository.add(processDefinition);
ProcessInstance processInstance = new ProcessInstance(processDefinition);
return processInstance;
}
private static class MapBasedProcessRepository implements SubProcessResolver {
protected MapBasedProcessRepository() {}
private Map<String, ProcessDefinition> processes = new HashMap<String, ProcessDefinition>();
public void add(ProcessDefinition processDefinition) {
processes.put(processDefinition.getName(), processDefinition);
}
public ProcessDefinition findSubProcess(Element subProcessElement) {
String processName = subProcessElement.attributeValue("name");
return processes.get(processName);
}
}
}
package com.jbpm.test;
import org.jbpm.graph.def.ActionHandler;
import org.jbpm.graph.exe.ExecutionContext;
public class DoNothingActionHandler implements ActionHandler {
public DoNothingActionHandler() {
}
/**
* @inheritDoc
*/
public void execute(ExecutionContext executionContext) throws Exception {
executionContext.leaveNode();
}
}
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064516#4064516
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064516
19Â years
[JBoss Portal] - Re: portal-migration autocommit exception
by k3nnymusic
sorry update:
when i removed STRICT_TRANS_TABLES from my.ini, reconnect the server and start portal-migration, it stops in create tables step14:27:09,868 INFO [SettingsFactory] Automatic flush during beforeCompletion(): disabled
| 14:27:09,868 INFO [SettingsFactory] Automatic session close at end of transaction: disabled
| 14:27:09,868 INFO [SettingsFactory] JDBC batch size: 15
| 14:27:09,868 INFO [SettingsFactory] JDBC batch updates for versioned data: disabled
| 14:27:09,868 INFO [SettingsFactory] Scrollable result sets: enabled
| 14:27:09,868 INFO [SettingsFactory] JDBC3 getGeneratedKeys(): disabled
| 14:27:09,868 INFO [SettingsFactory] Connection release mode: auto
| 14:27:09,868 INFO [SettingsFactory] Default batch fetch size: 1
| 14:27:09,868 INFO [SettingsFactory] Generate SQL with comments: disabled
| 14:27:09,868 INFO [SettingsFactory] Order SQL updates by primary key: disabled
| 14:27:09,868 INFO [SettingsFactory] Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
| 14:27:09,868 INFO [ASTQueryTranslatorFactory] Using ASTQueryTranslatorFactory
| 14:27:09,868 INFO [SettingsFactory] Query language substitutions: {}
| 14:27:09,868 INFO [SettingsFactory] JPA-QL strict compliance: disabled
| 14:27:09,868 INFO [SettingsFactory] Second-level cache: disabled
| 14:27:09,868 INFO [SettingsFactory] Query cache: disabled
| 14:27:09,868 INFO [SettingsFactory] Optimize cache for minimal puts: disabled
| 14:27:09,868 INFO [SettingsFactory] Structured second-level cache entries: disabled
| 14:27:09,868 INFO [SettingsFactory] Statistics: disabled
| 14:27:09,868 INFO [SettingsFactory] Deleted entity synthetic identifier rollback: disabled
| 14:27:09,915 INFO [SettingsFactory] Default entity-mode: pojo
| 14:27:09,915 INFO [SessionFactoryImpl] building session factory
| 14:27:10,290 INFO [SessionFactoryObjectFactory] Not binding factory to JNDI, no JNDI name configured
| 14:27:10,447 INFO [Dialect] Using dialect: org.hibernate.dialect.MySQLDialect
| 14:27:10,478 INFO [SchemaExport] Running hbm2ddl schema export
| 14:27:10,493 INFO [SchemaExport] exporting generated schema to database
| 14:27:10,493 INFO [NamingHelper] JNDI InitialContext properties:{}
| 14:27:10,493 INFO [DatasourceConnectionProvider] Using datasource: java:/PortalDS_2_4
and don't response
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064514#4064514
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064514
19Â years