[JBoss jBPM] - DeployProcessTask in 3.2.1
by holly77
I just found out that my ant task that was working with jbpm-3.4.1 will not work any more with jbpm-3.2.1
| <target name="deploy.par" depends="create.par">
| <taskdef name="deploypar"
| classname="org.jbpm.ant.DeployProcessTask">
| <classpath refid="compile.classpath" />
| <classpath refid="hibernate"/>
| <classpath path="./lib/commons-collections-3.2.jar" />
| <classpath path="${jboss.root.dir}/server/default/lib/cglib.jar" />
| <classpath path="${jboss.root.dir}/server/default/lib/antlr-2.7.6.jar" />
| </taskdef>
| <deploypar process="jpdl/deployment/test.par"
| cfg="jpdl/deployment/hibernate.cfg.xml" />
| </target>
|
I get the following error message:
| BUILD FAILED
| .../build.xml:161: deploypar doesn't support the "cfg" attribute
|
The 'cfg' attribute is not valid any more...
I found out that there's an attribute 'jbpmCfg' now, instead.
But configuring the deploypar target with 'jbpmCfg' attribute pointing to my 'hibernate.cfg.xml' doesn't work. Either pointing it to my jbpm.cfg.xml and configuring the path to my hibernate.cfg.xml within the jbpm.cfg.xml file doesn't work.
It always results in
| couldn't deploy process archives : hibernate.cfg.xml not found
|
Documentation in user guide is not up to date, i.e. still described with 'cfg' attribute setting.
Anybody knows how to set up my paths correctly?
Anybody got a working ant task example with jbpm 3.2.x?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120129#4120129
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120129
18 years, 5 months
[JBoss Messaging] - Failing client blocks JMS server
by rtm333
Hi,
We are using JBM 1.4.0.SP3 on JBoss AS 4.2.2.GA without clustering.
We have observed that (under high load) one suddenly dying remote JMS topic subscriber (e.g. when blue screening or disconnected from the network) might block message delivery to all other clients for a rather long time. It takes somewhere between ten to twenty minutes before finally an "java.io.IOException: Connection timed out" is thrown and processing continues normally. This can be accelerated by rebooting or reconnecting the failing client, respectively.
Is this the behaviour to be expected? Is there a timeout parameter that can be changed to reduce the blocking time significantly?
I have stack traces from the blocking server-side threads (one per JMS session), but as they are rather long I just wanted to get a quick opinion before posting them.
Thanks in advance for any help.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120128#4120128
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120128
18 years, 5 months
[JBoss Seam] - no-connection servlet issue
by mars1412
NOT URGENT
I have a (third party) java applet, that connects to my servlet sending following request when it is initialized:
HEAD /twentyfouract//servlets/multiupload HTTP/1.1
| Host: localhost
| Connection: close
this works fine and returns what I expect (I implemented only doPost):
HTTP/1.1 405 HTTP method GET is not supported by this URL
but since I need some seam components in my servlet, I activate the seam web context filter, in my components.xml as described in http://docs.jboss.com/seam/latest/reference/en/html/configuration.html#d0...:
<web:context-filter url-pattern="/servlets/*" />
when I activate this context filter, the request above will always cause the following exception on the server:
| 15:10:16,631 ERROR [[multiupload]] Servlet.service() for servlet multiupload threw exception
| java.lang.IllegalStateException: Cannot create a session after the response has been committed
| at org.apache.catalina.connector.Request.doGetSession(Request.java:2284)
| at org.apache.catalina.connector.Request.getSession(Request.java:2066)
| at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
| at org.jboss.seam.servlet.ServletRequestSessionMap.put(ServletRequestSessionMap.java:87)
| at org.jboss.seam.servlet.ServletRequestSessionMap.put(ServletRequestSessionMap.java:25)
| at org.jboss.seam.contexts.BasicContext.set(BasicContext.java:80)
| at org.jboss.seam.Component.newInstance(Component.java:1980)
| at org.jboss.seam.Component.getInstance(Component.java:1878)
| at org.jboss.seam.Component.getInstance(Component.java:1857)
| at org.jboss.seam.Component.getInstance(Component.java:1834)
| at org.jboss.seam.web.Session.getInstance(Session.java:122)
| at org.jboss.seam.contexts.Contexts.flushAndDestroyContexts(Contexts.java:375)
| at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:132)
| at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:65)
| at org.jboss.seam.web.ContextFilter.doFilter(ContextFilter.java:37)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
| at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
| at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:150)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:619)
|
note: this is not urgent - the applet and the servlet (doPost()) work correctly
I just think, that this behaviour might indicate a (minor) bug in the filter, so maybe anyone of the SEAM team might check this
for SEAM users, who might be interested in getting rid of this exception, here is what I did:
I simply implemented the doGet method and return a plain/text:
then my applet still works, and my servlet does not throw this exception anymore
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120117#4120117
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120117
18 years, 5 months
[Installation, Configuration & DEPLOYMENT] - Add directory to server classpath?
by tbaker73
I work at a company that is starting to use JBoss in addition to Websphere. Under Websphere, the company distributes a 'core' set of utility jars and some common configuration files (xml and properties files) on all Websphere servers as a 'shared library' that gets added to the server classpath. All the jars are placed in one or two directories on each server, and then Webpshere allows those directories to be added to the classpath (it is not necessary to add each individual file to the classpath which in this case would be time consuming and require a decent amount of maintenance with each release of the 'core' utilities).
Is there a way to do a similar thing with JBoss? I saw that in jboss-service.xml, you can add a directory to the classpath and specify that all the archives in that directory should be included (code snippet below) but this doesn't load the properties and xml files to the server classpath.
<classpath codebase="file:/path/to/core/lib/dir" archives="*"/>
Any help/suggestions would be greatly appreciated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120114#4120114
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120114
18 years, 5 months