October 2009 - jboss-dev-forums - Jboss List Archives

[JBoss Web Services Development] - Re: Keep alive doesn't doesn't work for closed TCP/IP connec

by richard.opalka＠jboss.com

The fix is not acceptable :( We cannot simply catch exception and resend the message. This fix won't work for long streaming attachments :( It just works for really simple usecases. The correct fix will be to detect closed connections before writing to the stream. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258305#4258305 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258305

16 years, 2 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] - Web application deployment directory

by juicebox

Hello guys, I'm developing an application consisting of a .war and a .jar both wrapped inside an .ear. The web module (.war) contains a Flex application compiled into a .swf file. When I deploy the .ear archive, the web application in the .war file is extracted to a temporary directory, whose location varies in every deployment (e.g. ./jboss-5.1.0.GA/server/default/tmp/3j011-7yxnpe-g0ad7tf5-1-g0ad9aer-b4/web.war/) To speed up things, I set the flex module output directory pointing to the webapp root, so that when I recompile I see the changes applied immediately. The problem is that with JBoss, the webapp root directory is varying all the time as described before. Is there any way in which I can instruct JBoss to uncompress the archives to an arbitrary directory? Any suggestion will be appreciated! Thanks in advance View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258304#4258304 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258304

16 years, 2 months

1
0
0 / 0

[jBPM Development] - Re: parser for each jpdl release

by sebastian.s

Thank you very much for the update, Tom. From what I can say with my limited knowledge to me this sounds like a reasonable way to account for backwards comptability while allowing enhancements for jPDL which are necessary. By the way: Did anybody manage to look in to this issue here? https://jira.jboss.org/jira/browse/JBPM-2537 I'd love to here your opinion on this. To me it is a priority issue for the next release because the bug prevents you from using a lot of the features and the power jBPM offers. Thanks for your efforts and keep up the good work! :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258281#4258281 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258281

16 years, 2 months

1
0
0 / 0

[jBPM Development] - parser for each jpdl release

by tom.baeyens＠jboss.com

Just wanted to give you guys an early update. I encountered a significant unexpected issue. It was related to updating the classloading. Due to updates in classloading, I came to change the jPDL parsing. the occasion here is minor: i want to refactor the expr attribute to object-expr in user code declarations. but the implications seem to be hard. Then I realized that the old (v4.0 and v4.1) process files are in the DB. For users that want to upgrade, this parser change potentially breaks existing installations in a non-recoverable manner as the new parser might not parse the existing deployed process definitions in the same way. (the XML is stored in the DB) The solution I'm currently targetting for is pretty involved: * Each release will have its own namespace URI. (i forgot this in 4.1. so release 4.1 still contains the 4.0 namespace) * Each version of jPDL will add it's own parser. All old parsers will be kept in the codebase as well. So that jBPM can still deploy older process versions that are deployed and stored in the DB. * Each time when a process is deployed, the optional namespace declaration is checked. If not present, the jPDL version deployer will add the namespace and re-serialize the process xml in the deployment that will be stored in the DB. That way the deployed process in the DB will contain the version explicitly of the process XML. And later, each time when jBPM parses that process file after a reboot, then the correct parser associated with that jPDL version can be used. * So users should still be able to deploy e.g. a jPDL process in version 4.3 XML in jBPM version 4.7 * Migration tool will apply the namespace check and add the 4.0 namespace. * For testing, I think it is sufficient to use a single test suite. When we embark on a new version, the full test suite will be using the new version's parser. The old version's parser will not be changed any more. So that is why I think it is ok if it is not tested any more. from a first glance, this seens to be the only way in which we can support decent backwards compatibility and still allow us to evolve the language. thoughts ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258277#4258277 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258277

16 years, 2 months

1
0
0 / 0

[JBoss ESB Development] - Re: XPath Routing

by tfennelly

"ldimaggi(a)redhat.com" wrote : Just to confirm, these changes should have no impact to existing configurations and .esb's that make use of content based routing? (aka no migration) That's correct. "ldimaggi(a)redhat.com" wrote : And - the ESB (eclipse) editor will be upated to handle the changes when 4.7 goes GA? | I believe so :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258272#4258272 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258272

16 years, 2 months

1
0
0 / 0

[JBoss ESB Development] - Re: XPath Routing

by ldimaggi＠redhat.com

Just to confirm, these changes should have no impact to existing configurations and .esb's that make use of content based routing? (aka no migration) And - the ESB (eclipse) editor will be upated to handle the changes when 4.7 goes GA? Thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258269#4258269 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258269

16 years, 2 months

1
0
0 / 0

[JCA Development] - Design of ConnectionManager API

by gurkanerdogdu

Hi; Currently there is an interface org.jboss.jca.core.api.ConnectionManager (CM) and org.jboss.jca.core.api.RealConnectionManager (RCM). CM delegates connection creation operation to the RCM that is responsible for doing all connection related stuff (including transactions). WDYT? --Gurkan View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258262#4258262 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258262

16 years, 2 months

1
0
0 / 0

[JBoss Messaging Development] - FilterParser.jj

by mikechang

I am just reading the new JMS server source code, inside eclipse org.jboss.messaging.core.filter.impl.FilterImpl.java references the FilterParse.jj which is not a java file (well strickly speaking) thus it does not pass eclipse compile time check, so does anyone of you have any ideas to get around of this problem? thx Mike View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258261#4258261 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258261

16 years, 2 months

1
0
0 / 0

[JBoss XML Binding Development] - Re: XB profiling during the AS start-up

by jesper.pedersen

I changed my XML parsing from JAXB/XJC to a StAX model (Sun implementation). Maybe Woodstock can lower the times even more... JAXB/XJC: bootstrap.xml: 385 ms naming.xml: 71 ms transaction.xml: 23 ms jca.xml: 58 ms StAX: bootstrap.xml: 18 ms naming.xml: 5 ms transaction.xml: 1 ms jca.xml: 2 ms The times are from the file handle is created to the Java model is returned, e.g. includes the time spend on creating factories and unmarshallers. There may be other areas that needs to be covered by JBXB - so I can't say if the results will map directly to your case. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258237#4258237 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258237

16 years, 2 months

1
0
0 / 0

[jBPM Development] - Re: (JBPM 4.1) Console process definition list

by kukeltje

afaik the forms engine does not pas the actor to the bpm engine/core yet. There is a jira issue for this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258231#4258231 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258231

16 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2009