[Design of JBoss jBPM] - Re: extending form / task functionality
by cocampo
"tom.baeyens(a)jboss.com" wrote : forms are not included in the process definition because they are too big. also, we moved to xhtml facelets files for forms. this adds extra customizability for the users. meaning that the gpd can create flat list forms, but the users can easily customize these forms and make the user experience better.
Please pardon me, I didn't mean "include the whole form definition", but a "link" to the page (a la JSF). Of course, managed by jBPM (they way you can actually do by using pageflows, but in a single file --> process definition + pageflow definition).
"tom.baeyens(a)jboss.com" wrote : it remains to be seen wether in real intranet applications, the forms mechanism will be used. for some reason or another projects always include their own UI, not leveraging the task UI included in jbpm.
I agree with you, I think most developers will want their own look and feel, but I don't know if it's desireable that you need to develop/code the dependencies between tasks and forms; have you seen Carnot? I'm thinking of something like that; please take a look at http://www.carnot.ag/products/workflow/products/rad/products/rad/casabac-...). However, I think pageflows are a more powerful mechanism than just defining a single page, but an integration directly from the GPD would be nice (IMHO).
Let me know what you think about this.
Thanks for your time.[/url]
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979388#3979388
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979388
19 years, 5 months
[Design of Kosmos] - Re: SvnMonitoringPortlet
by lamerbot
I found class com.liferay.util.axis.SimpleHTTPSender in liferay/common/lib/ext/util-java.jar (standart deployment)
Full stack trace related to the SVN:
| 18:05:37,699 INFO [SvnMonitoringPortlet] Viewing...
| 18:05:37,870 INFO [MethodResultCacheInterceptor] Cache-miss: reloading "hu.midori.kosmos.server.svn
| .SvnServiceImpl.getRepositories.http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/"...
| 18:05:38,011 INFO [SvnServiceImpl] Analyzing log of "http://anonsvn.labs.jboss.com/labs/jbossrules/
| trunk" repository...
| 18:05:39,824 ERROR [SvnServiceImpl] Unable to process the SVN repo
| org.tmatesoft.svn.core.SVNException: svn: REPORT of '/!svn/bc/6912/labs/jbossrules/trunk': 400 Bad R
| equest (http://anonsvn.labs.jboss.com)
| at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:43)
| at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.log(DAVRepository.java:487)
| at org.tmatesoft.svn.core.io.SVNRepository.log(SVNRepository.java:629)
| at org.tmatesoft.svn.core.io.SVNRepository.log(SVNRepository.java:919)
| at hu.midori.kosmos.server.svn.SvnServiceImpl.analyzeLog(SvnServiceImpl.java:166)
| at hu.midori.kosmos.server.svn.SvnServiceImpl.getRepositories(SvnServiceImpl.java:80)
| 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:287
| )
| at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMe
| thodInvocation.java:181)
| at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvo
| cation.java:148)
| at hu.midori.kosmos.server.MethodResultCacheInterceptor.invoke(MethodResultCacheInterceptor.
| java:56)
| at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvo
| cation.java:170)
| at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)
| at $Proxy134.getRepositories(Unknown Source)
| 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:287
| )
| at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMe
| thodInvocation.java:181)
| at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvo
| cation.java:148)
| at org.springframework.remoting.support.RemoteInvocationTraceInterceptor.invoke(RemoteInvoca
| tionTraceInterceptor.java:68)
| at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvo
| cation.java:170)
| at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)
| at $Proxy135.getRepositories(Unknown Source)
| 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 com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:157)
| at org.springframework.remoting.caucho.HessianServiceExporter.handleRequest(HessianServiceEx
| porter.java:110)
| at org.springframework.web.servlet.mvc.SimpleHandlerAdapter.handle(SimpleHandlerAdapter.java
| :46)
| at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:792)
| at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:726)
| at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:396
| )
| at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:360)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
| ava:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
|
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
| ava:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
|
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.ja
| va:159)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11P
| rotocol.java:744)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| at java.lang.Thread.run(Thread.java:595)
| 18:05:39,855 INFO [MethodResultCacheInterceptor] Cache-miss: reloading "hu.midori.kosmos.server.svn
| .SvnServiceImpl.getRepositories.http://anonsvn.labs.jboss.com/labs/kosmos/trunk/"...
| 18:05:39,855 INFO [SvnServiceImpl] Analyzing log of "http://anonsvn.labs.jboss.com/labs/kosmos/trun
| k" repository...
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979385#3979385
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979385
19 years, 5 months
[Design of JBossCache] - Re: POJOization of config elements
by bstansberry＠jboss.com
I think we're about 90% on the same page :-)
"manik.surtani(a)jboss.com" wrote : How would implementation-specific values be set? Again, using your BuddyLocator example, I presume this would be using BuddyLocatorConfig.getBuddyLocatorProperties()? We're back to dealing with properties objects; how does this help the MC, except for the case of *known* setters/getters such as getBuddyLocatorClass()?
|
The get/setBuddyLocatorProperties() method isn't *really* meant for use by the MC. It's there to support the old style config, where we parse the existing format. AFAIK, we still need to support that.
anonymous wrote :
| 1) Use a BuddyLocatorConfig that just contains *known* setters/getters, such as BuddyLocatorClass.
Yep. But this base class is the one that gets instantiated if we use the old style config. So, the get/setProperties method needs to be there as well to have some way to pass in the config properties if the MC isn't used.
anonymous wrote :
| 2) If people wish to implement their own BuddyLocator, they would also provide their own subclass to BuddyLocatorConfig, adding their own custom setters/getters.
|
Yes, that's what I intend. However, if your BuddyLocator impl is ever going to be used w/ an old-style config file, your BuddyLocator impl needs to also be able to configure itself from a basic BuddyLocatorConfig instance's getProperties() method.
A custom BL impl only used with the MC may not ever concern itself with the Properties; but the standard ones we ship w/ JBC need to be able to configure themselves via Properties.
anonymous wrote :
| 3) The MC would still be able to inject this BLC subclass into the custom BL impl, since the interface methods comply. The BL impl will be responsible for casting the BLC to the BLC subclass and extracting impl-specific configs.
|
If the BL impl needs to support the old style config method, it does this when the BLC is passed in:
a) Check if the BLC is of its custom type. If yes, cast it and use it directly to configure yourself.
b) If not, it's a base BLC type created from the old style config. Configure yourself from its properties. (Typically I'd do that by passing the base BLC instance to a c'tor of my custom BLC subclass. The subclass then knows how to build itself from the Properties. The BL then uses the custom BLC instance internally. This approach is an implementation detail though.)
I'm not thinking in terms of the MC injecting a BLC into a BL. The MC does this:
1) builds a complex, composite Configuration object. A BLC is just a sub-component of that. MC creates a BLC, injects that into a BuddyReplicationConfig, which is then injected into the top level Configuration.
2) MC builds the Cache by passing the Configuration into the factory. Then the internal JBC code builds the cache based on the Configuration; BL gets instantiated and passed its config as part of that. I think the rules for building a Cache are too complex to try to have the MC do it directly; the factory provides a good encapsulation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979361#3979361
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979361
19 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Server-side Thread-per-connection Model
by timfox
There is also another issue here:
Currently the channels are architected according to a SEDAish style.
All the message adding and delivery operations for a particular channel are handled by the same thread, this means we reduce context switches because there aren't multiple threads blocking and unblocking to do operations on the channel.
Each channel has it's own "event queue" where delivery, or message handling operations can be deposited for execution on the queues thread. (Actually different queues can share the same thread but that is not relevant to the discussion).
Currently we only have a partial SEDAish approach since remoting does not allow us to write back to the socket using a different thread.
E.g. ideally we want to do something like this (using NIO):
Have a selector loop which responds to NIO events on the NIO channels, then depending which queue the event is destined for (the event could be a send, or an acknowledge or a cancel for instance), the selector loop thread would lookup the correct queue and deposit the event on the queues event queue.
For those events which can be asynchronous (e.g. ack, cancel) the request eventually gets processed by on the event queue thread and that is the end of that.
For synchronous operations e.g. send, the event queue thread would write back the response (non blocking) to the channel when the send was complete.
This gives a very nice usage of threads with a minimal amount of forced context switches - the only ones are in transferring the event from the selector thread to the event queue thread.
Currently since we're using blocking IO, and remoting needs to write the response back on the same thread as the request, in the case of send the following happens:
The server socket thread unblocks as the invocation arrives, the event is added to the queues event queue, then the server socket thread needs to block again until the send has been processed on the event queue (it uses a future for that). Therefore we have an extra context switch.
If we have a lot of requests then we have a lot of threads blocking/unblocking.
I suspect this would have performance implications.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979343#3979343
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979343
19 years, 5 months