[Design of JBoss jBPM] - Re: Task Forms
by david.lloyd＠jboss.com
"tom.baeyens(a)jboss.com" wrote : Using EL to access variables is a good thing (maybe they already are included in the lookup). But you should take into account that users can define variable names with spaces. In that case we need another lookup mechanism.
Ok, in that case probably it's more appropriate to say:
<h:inputText value="#{var['payment ID']}"/>
"tom.baeyens(a)jboss.com" wrote : Also I not so sure if a dependency on the runtime environment is a problem if that environment is properly documented and makes use of known technologies.
But requiring certain beans to be present is a nuicance. I don't want the task forms to be expecting certain managed beans, because this restricts my ability to make changes.
"tom.baeyens(a)jboss.com" wrote : We should avoid that people have to learn the jBPM Form Layer apart from JSF and Facelets. At least, this was the idea when designing the forms solution.
I wouldn't want to create a vastly new syntax or anything. But generally speaking, using a variety of component libraries is a very normal pratice that Facelets users are used to. It makes perfect sense to provide a component library for dealing with task forms; it's the most natural integration with Facelets in my opinion.
"tom.baeyens(a)jboss.com" wrote : Also with the buttons, the idea was that the graphical designer will generate those. After initial generation of the form by the gpd, the users now are able to customize the boring form layout to their own wishes.
I still maintain that some type of custom component is needed here. Better that the user could say:
<tf:button transition="to receive payments" .../>
...but still be able to specify all the standard JSF button attributes as well, including images, ID, styleClass, etc.
"tom.baeyens(a)jboss.com" wrote : By just using plain JSF/Facelets constructs, it seems much more flexible for users to start tweaking the graphical form.
I agree.
"tom.baeyens(a)jboss.com" wrote : On the other hand, if users don't customize the forms, they can always re-generate after they made some updates that have an impact on the form.
|
| So this explains why I was not too concerned with usability of the form constructs. My main concern was lowering the learning curve. The other important thought is that mostly, users will generate the forms and will not be looking at the form code.
With the form designer generating the inital form, I don't think usability will be a problem at all. If the user gets "lost" they can always just regenerate. In which case, the next most significant concern is implementation. I don't want to be in a situation where we've painted ourselves into a corner, just because it was a convenient first pass of an implementation. At the very least, I want to remove the usage of "taskBean" from the generated forms completely, and also I want to remove anything having to do with page navigation (in this case, action="" on the buttons).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983923#3983923
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983923
19 years, 5 months
[Design of JBoss/Tomcat Integration] - Problems with WAR within EAR
by bill.burke＠jboss.com
I'm deploying a WAR within an EAR and getting the following error. Does Tomcat expect an exploded directory in order to be deployed? The file being passed is a tempory .jar file created by NestedJarHandler.
| 15:18:21,375 ERROR [StandardContext] Error starting static Resources
| java.lang.IllegalArgumentException: Document base C:\Documents and Settings\wburke\Local Settings\Temp\nestedjar49905.tm
| p does not exist or is not a readable directory
| at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:140)
| at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3940)
| at org.apache.catalina.core.StandardContext.start(StandardContext.java:4111)
| at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
| at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
| at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:296)
| at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.apache.catalina.core.StandardContext.init(StandardContext.java:5277)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:296)
| at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.web.tomcat.tc6.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:289)
| at org.jboss.web.tomcat.tc6.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:120)
| at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:362)
| at org.jboss.web.deployers.WebModule.startModule(WebModule.java:88)
| at org.jboss.web.deployers.WebModule.start(WebModule.java:66)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:184)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
| at org.jboss.system.microcontainer.ServiceControllerContextAction.install(ServiceControllerContextAction.java:46
| )
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:5
| 1)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226)
| at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:198)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:538)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:472)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:320)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
| at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
| at org.jboss.system.ServiceController.start(ServiceController.java:431)
| at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:124)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:85)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:44)
| at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.ja
| va:53)
| at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
| at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:145)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:440)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:381)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:366)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:246)
| at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
| at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:401)
| at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:340)
| at org.jboss.Main.boot(Main.java:210)
| at org.jboss.Main$1.run(Main.java:508)
| at java.lang.Thread.run(Thread.java:595)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983903#3983903
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983903
19 years, 5 months
[Design of JBossCache] - Re: Document where non-String FQN do not work, JBCACHE-838
by bstansberry＠jboss.com
+1 on not restricting to String if where we can get around it.
+10 on better documenting the limitation.
I think the String limitation for Region comes from the old o.j.c.marshall.Region. This limitation was added because the Fqn was used in the marshalling code by a message recipient to determine what classloader to use to deserialize the message. That led to a chicken-or-egg problem: if one of the objects in the Fqn itself required the classloader, you were out of luck.
Solving that problem didn't really require use of String only. It just requires that no classes not visible to TreeCacheMarshaller.class.getClassLoader() be used in the Region Fqn. That's significantly less restrictive and can be documented.
JGroups partial state transfer adds a new problem in that the JGroups API requires use of String instead of Object as the identifier of the partial state. It would be nice if that were changed in a later release., although as an API change it would probably take a while to work its way into JBC.
For now, can we think of a way to use a String as a substitute for the Region Fqn in the partial state transfer call? E.g. restrict the components of a Region Fqn to String/Number/Enum, all of which can be fairly safely converted to a String. Or hopefully something more elegant than that :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983895#3983895
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983895
19 years, 5 months
[Design of JBossCache] - Document where non-String FQN do not work, JBCACHE-838
by genman
(From the issue)
Clearly, Region names are supposed to be described using String-only FQNs. This is because Regions are configured using String names in their configuration.
Also, the file and JDBC based persistence system do not handle non-String FQNs.
But here are several use cases for using non-String FQN.
For example, at my past company, we stored mobile handset data by country code and phone numbers as numbers. Things like integers and enumerated types are obviously more lightweight than string objects as keys. Personally, I think that being able to use appropriate types in the FQN is worthwhile efficiency and is more consistent with the Java philosophy of type safety.
In any case, it would be nice to have an audit of areas that:
0. Do support non-String FQN by design.
1. Do not support non-String FQN, but possibly could (create new issues for these?).
2. Cannot support non-String FQN, and are not documented.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983888#3983888
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983888
19 years, 5 months