[QA of JBoss Portal] - Injecting MC beans into the servlet context
by julien＠jboss.com
- MC is able to pick beans from a factory.
- MC is able to inject beans into a Map.
given that we can have a bean factory that produces a POJO that has a Map as property. That Map is a wrapper around the ServletContext attributes.
| public class ServletContextAttributes
| {
| private final ServletContext context;
| public ServletContextAttributesInj(ServletContext context)
| {
| this.context = context;
| }
| public void setAttributes(Map attrs)
| {
| for (Iterator i = attrs.entrySet().iterator();i.hasNext();)
| {
| Map.Entry entry = (Map.Entry)i.next();
| String name = (String)entry.getKey();
| Object value = entry.getValue();
| context.setAttribute(name, value);
| }
| }
| }
|
For the bean factory one already exist in the test module : org.jboss.portal.test.framework.TestBeanFactory
Then at startup of the servlet context listener we would have something like:
| public void contextInitialized(ServletContextEvent event)
| {
| // Create wrapper that configures
| ServletContextAttributes attrs = new ServletContextAttributes(event.getServletContext());
|
| // Configure MC
| TestRuntimeContext runtimeContext = new TestRuntimeContext("jboss-beans.xml");
| runtimeContext.addBean("ServletContextAttributes", attrs);
| runtimeContext.start();
| }
|
and in jboss-beans.xml we would have something like :
| <deployment ...>
|
| ... <!-- Declare all beans that are wired like AuthorizationDomainRegistry, etc... -->
|
| <!-- That's one bean that interest us to be injected in the servlet context as an attribute -->
| <bean name="PortalObjectContainer" class="org.jboss.portal.core.impl.model.portal.PersistentPortalObjectContainer">
| <property name="sessionFactoryJNDIName">java:/SessionFactory</property>
| <property name="authorizationDomainRegistry"><inject bean="AuthorizationDomainRegistry"/></property>
| <property name="portalAuthorizationManagerFactory"><inject bean="AuthorizationManagerFactory"/></property>
| <property name="contentProviderRegistry"><inject bean="ContentProviderRegistry"/></property>
| </bean>
|
| <bean name="ServletContextAttributes" class="ServletContextAttributes">
| <constructor factoryMethod="getBean">
| <factory bean="BeanFactory"/>
| <parameter>ServletContextAttributes</parameter>
| </constructor>
| <property name="attributes">
| <map keyClass="java.lang.String">
| <entry>
| <key>PortalObjectContainer</key>
| <value><inject bean="PortalObjectContainer"/></value>
| </entry>
| </map>
| </property>
| </bean>
|
| </deployment>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054428#4054428
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054428
19 years
[Design of JBoss jBPM] - Re: Thinking about transition attrs
by brittm
anonymous wrote : Why the need for it to be in tables?
The point in using tables is consistency. To get configuration about a Transition, a user should expect to retrieve the transition and then retrieve the configuration off of it, just like they would for anything else.
anonymous wrote : I hate 'generic' tags. They quickly become meaningless.
Quite possible (on the meaningless part--I'm not qualified to comment on wether you like them or not :-) ). However, a 'meta' tag is no more meaningless than a note pad; its not the note pad that matters, its what you put in it, and that can only be as meaningless as you allow it to be. By giving developers a meta tag, we would in essence simply be giving them a place to jot down notes about their process elements (notes that they can access programatically later in the same way they access the jpdl elements themselves).
anonymous wrote : Would we see people using it? Would they give feedback on how they use it? I doubt it.
Well, we would use it. And I'm not shy about giving feedback. :-)
anonymous wrote : maybe because I use jBPM to little hands on and spend to much time in the forum ;-)
Unfortunately, I'm doing the opposite. Working with it too much and following the project too little.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054404#4054404
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054404
19 years
[Design of JBoss jBPM] - Re: process patch files
by lucabotti
Why do not simply add a compatibility flag for the new process description (or for any node of the process descritpion) which could state the compatibility of the new process definition version with older process instances.
When an instance token is signalled, instead of moving blindly in the path, it could check if next version is backward compatible.
Also a node old-to-new mapping kind of descriptor shoud be added, or asked to be resolved at deployment.
This way:
1) I am a process in a node - token - so when i need to move i check if newer process definitions exist and if they are compatible.
2) If it exists, i lookup in the node old-to-new mapping to check the node compatibility and lookup for transitions (and tasks, and actions, and so on...)
Just (a silly?) idea.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054382#4054382
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054382
19 years
[Design of JBoss jBPM] - Re: jbpm4jsf java 5 dependency
by jeffdelong
Tom said
anonymous wrote : What we can do is add more packages in the deploy directory
Yes, please put the other war packagaes in the deploy directory, so we can deploy wars and ears containing these wars to jdk5 / JBossAS4.2 environments.
I think it is great that David has tested these other combinations, and can build wars that work in each. In the past we had to deploy them in the field only to find out there were various jar incompatibilities with newer versions of the app server. We almost always start of a new project with the latest release version of the AS, so this always bit us in the past. I don't mind having to repackage an ear (be nice if there were scripts to do it with a build.properties file to describe which app server and jdk and pick the correct war version you wanted). But I don't want to have to go to CVS and build from source.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054345#4054345
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054345
19 years