[JBoss JIRA] Created: (JBESB-2821) HttpRouter fire java.lang.IllegalArgumentException if the Status Code is 304 (Not Modified)
by Kevin Conner (JIRA)
HttpRouter fire java.lang.IllegalArgumentException if the Status Code is 304 (Not Modified)
-------------------------------------------------------------------------------------------
Key: JBESB-2821
URL: https://jira.jboss.org/jira/browse/JBESB-2821
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Adapters, Rosetta
Affects Versions: 4.6
Reporter: Magesh Kumar B
Assignee: Magesh Kumar B
Fix For: 4.7
When a GET is requested with If-Modified-Since in the header, the server responds with 304 - Not Modified with no Response Body[1] if the document requested is not modified since. We get the following error in such situations.
WARN [org.jboss.soa.esb.actions.routing.http.HttpRouter] Received status code '304' on HTTP org.apache.commons.httpclient.methods.GetMethod@5583aa request to 'http://server/url'.
ERROR [org.jboss.soa.esb.listeners.gateway.JBossRemotingGatewayListener] JBoss Remoting Gateway failed to synchronously deliver message to target service [Service:Category].
org.jboss.soa.esb.couriers.FaultMessageException: java.lang.IllegalArgumentException: null 'stream' arg passed in method call.
at org.jboss.soa.esb.listeners.message.errors.Factory.createExceptionFromFault(Factory.java:50)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:207)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:580)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:493)
at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:343)
at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:204)
at org.jboss.soa.esb.listeners.message.UncomposedMessageDeliveryAdapter.deliverSyncWithoutDecomposing(UncomposedMessageDeliveryAdapter.java:107)
at org.jboss.soa.esb.listeners.message.UncomposedMessageDeliveryAdapter.deliverSync(UncomposedMessageDeliveryAdapter.java:86)
at org.jboss.soa.esb.listeners.gateway.JBossRemotingGatewayListener.invoke(JBossRemotingGatewayListener.java:345)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:866)
at org.jboss.remoting.transport.coyote.CoyoteInvoker.service(CoyoteInvoker.java:310)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: null 'stream' arg passed in method call.
at org.jboss.internal.soa.esb.util.StreamUtils.readStream(StreamUtils.java:47)
at org.jboss.soa.esb.actions.routing.http.HttpRouter.process(HttpRouter.java:109)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:615)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:574)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:408)
at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
... 1 more
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
"10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields. "
Note: This happens only after applying this fix, else it is never caught or identified
https://jira.jboss.org/jira/browse/JBESB-2525
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBESB-2192) [AbstractFileGateway] Composer <LocalFileMessageComposer> Failed. MessageDeliverException: Invalid File payload. File 'C:\... .esbWorking' doesn't exist.
by Douglas Zanatta Ulian (JIRA)
[AbstractFileGateway] Composer <LocalFileMessageComposer> Failed. MessageDeliverException: Invalid File payload. File 'C:\... .esbWorking' doesn't exist.
---------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBESB-2192
URL: https://jira.jboss.org/jira/browse/JBESB-2192
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.4 CP1
Environment: Windows XP SP3, JBoss AS 4.2.2.GA
Reporter: Douglas Zanatta Ulian
I'm working on an integration project where ESB is responsible for:
1: picking up XML message files in a remote host using an ftp-provider and writing them to a local directory.
2: loading each file from the local dir using fs-provider,
3: validating its XML message,
4: consuming the message using hibernate,
5: creating a result message to be returned to the sender,
6: writing it to a success/error directory,
7: loading the result message file using fs-provider,
8: sending the return info through a web service.
The problem seems to be on step 7, when multiple "return message files" are placed on the dir to be sent back to the sender, after working well with a couple of files I get the following exception:
2008-11-13 16:17:11,154 ERROR [org.jboss.soa.esb.listeners.gateway.AbstractFileGateway] Composer <org.jboss.soa.esb.listeners.gateway.LocalFileMessageComposer> Failed.
org.jboss.soa.esb.listeners.message.MessageDeliverException: Invalid File payload. File 'C:\message\loja\ok\9844_MsgUnidade_13112008_35501.msg.esbWorking' doesn't exist.
at org.jboss.soa.esb.listeners.gateway.LocalFileMessageComposer.compose(LocalFileMessageComposer.java:63)
at org.jboss.soa.esb.listeners.gateway.LocalFileMessageComposer.compose(LocalFileMessageComposer.java:44)
at org.jboss.soa.esb.listeners.gateway.AbstractFileGateway.onSchedule(AbstractFileGateway.java:156)
at org.jboss.soa.esb.schedule.ScheduleProvider$ESBScheduledJob.execute(ScheduleProvider.java:227)
at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
Although the exception is raised, the process is completed and step 8 is executed, making it looks like there are two threads working on the same file, where one of them completes the entire pipeline while the other fails on step 7... though I've configured it to work with a single thread!
my jboss-esb.xml looks like this:
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml..." parameterReloadSecs="5">
<providers>
<ftp-provider name="FTPprovider" hostname="${caravelas.ftp}">
<ftp-bus busid="helloFTPChannel" >
<ftp-message-filter
username="caravelas"
password="colombo"
passive="false"
directory="${caravelas.ftp.directory}"
input-suffix=".msg"
work-suffix=".esbWorking"
post-delete="false"
post-suffix=".COMPLETE"
error-delete="false"
error-suffix=".HAS_ERROR"/>
</ftp-bus>
</ftp-provider>
<fs-provider name="FSprovider">
<fs-bus busid="SucessoFileChannel" >
<fs-message-filter
directory="${caravelas.message.ok}"
input-suffix=".msg"
work-suffix=".esbWorking"
post-delete="false"
post-directory="${caravelas.message.ok}"
post-suffix=".sentToEsb"
error-delete="false"
error-directory="${caravelas.message.ok}"
error-suffix=".IN_ERROR"
/>
</fs-bus>
<fs-bus busid="ErroFileChannel" >
<fs-message-filter
directory="${caravelas.message.erro}"
input-suffix=".msg"
work-suffix=".esbWorking"
post-delete="false"
post-directory="${caravelas.message.erro}"
post-suffix=".sentToEsb"
error-delete="false"
error-directory="${caravelas.message.erro}"
error-suffix=".IN_ERROR"
/>
</fs-bus>
</fs-provider>
<jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
<jms-bus busid="quickstartEsbChannel">
<jms-message-filter dest-type="QUEUE" dest-name="queue/B"/>
</jms-bus>
<jms-bus busid="Business_Rules_ClientePFisica">
<jms-message-filter dest-type="QUEUE" dest-name="queue/ConsumidorClientePFisicaService"/>
</jms-bus>
<jms-bus busid="Business_Rules_Linha">
<jms-message-filter dest-type="QUEUE" dest-name="queue/ConsumidorLinhaService"/>
</jms-bus>
<jms-bus busid="Business_Rules_Familia">
<jms-message-filter dest-type="QUEUE" dest-name="queue/ConsumidorFamiliaService"/>
</jms-bus>
<jms-bus busid="Business_Rules_Unidade">
<jms-message-filter dest-type="QUEUE" dest-name="queue/ConsumidorUnidadeService"/>
</jms-bus>
<jms-bus busid="Queue_ERRO">
<jms-message-filter dest-type="QUEUE" dest-name="queue/ERRO" />
</jms-bus>
<jms-bus busid="Queue_SUCESSO">
<jms-message-filter dest-type="QUEUE" dest-name="queue/SUCESSO" />
</jms-bus>
<jms-bus busid="Queue_RETORNO_SUCESSO">
<jms-message-filter dest-type="QUEUE" dest-name="queue/RetornoSucesso"/>
</jms-bus>
<jms-bus busid="Queue_RETORNO_ERRO">
<jms-message-filter dest-type="QUEUE" dest-name="queue/RetornoErro"/>
</jms-bus>
</jms-provider>
<schedule-provider name="cronExample">
<cron-schedule scheduleid="cron-schedule" cronExpression="0/5 * * * * ?"/>
</schedule-provider>
</providers>
<services>
<service category="myCategory" name="myFileListener" description="Hello World File Action (esb listener)" >
<listeners>
<ftp-listener name="FtpGateway" busidref="helloFTPChannel" is-gateway="true" scheduleidref="cron-schedule" />
<jms-listener name="helloWorldFileAction" busidref="quickstartEsbChannel" />
</listeners>
<actions>
<action name="ValidaMensagem" class="com.colombo.esb.action.ValidaMensagem"/>
<action name="ContentBasedRouter" class="org.jboss.soa.esb.actions.ContentBasedRouter">
<property name="ruleSet" value="rotas.drl" />
<property name="ruleReload" value="true" />
<property name="destinations">
<route-to destination-name="ConsumidorClientePFisicaService" service-category="ConsumidorServices" service-name="ConsumidorClientePFisicaService" />
<route-to destination-name="ConsumidorLinhaService" service-category="ConsumidorServices" service-name="ConsumidorLinhaService"/>
<route-to destination-name="ConsumidorFamiliaService" service-category="ConsumidorServices" service-name="ConsumidorFamiliaService" />
<route-to destination-name="ConsumidorUnidadeService" service-category="ConsumidorServices" service-name="ConsumidorUnidadeService" />
</property>
<property name="object-paths">
<object-path esb="body.mensagem_tipo" />
</property>
</action>
</actions>
</service>
<service category="ConsumidorServices" name="ConsumidorClientePFisicaService" description="Consumidor de ClientePFisica">
<listeners>
<jms-listener name="Business_Rules_ClientePFisica" busidref="Business_Rules_ClientePFisica"/>
</listeners>
<actions mep="OneWay">
<action name="ConsumidorClientePFisica" class="com.colombo.esb.action.ConsumidorClientePFisica"/>
</actions>
</service>
<service category="ConsumidorServices" name="ConsumidorLinhaService" description="Consumidor de Linha">
<listeners>
<jms-listener name="Business_Rules_Linha" busidref="Business_Rules_Linha"/>
</listeners>
<actions mep="OneWay">
<action name="ConsumidorLinha" class="com.colombo.esb.action.ConsumidorLinha"/>
</actions>
</service>
<service category="ConsumidorServices" name="ConsumidorFamiliaService" description="Consumidor de Familia">
<listeners>
<jms-listener name="Business_Rules_Familia" busidref="Business_Rules_Familia"/>
</listeners>
<actions mep="OneWay">
<action name="ConsumidorFamilia" class="com.colombo.esb.action.ConsumidorFamilia"/>
</actions>
</service>
<service category="ConsumidorServices" name="ConsumidorUnidadeService" description="Consumidor de Unidade">
<listeners>
<jms-listener name="Business_Rules_Unidade" busidref="Business_Rules_Unidade"/>
</listeners>
<actions mep="OneWay">
<action name="ConsumidorUnidade" class="com.colombo.esb.action.ConsumidorUnidade"/>
</actions>
</service>
<service category="controle" name="Erro" description="gera msg erro">
<listeners>
<jms-listener name="Queue_ERRO" busidref="Queue_ERRO" is-gateway="false"/>
</listeners>
<actions mep="OneWay">
<action name="ErroAction" class="com.colombo.esb.action.ErroAction">
<property name="directory" value="${caravelas.message.erro}"/>
</action>
</actions>
</service>
<service category="controle" name="Sucesso" description="gera msg Sucesso">
<listeners>
<jms-listener name="Queue_SUCESSO" busidref="Queue_SUCESSO" is-gateway="false"/>
</listeners>
<actions mep="OneWay">
<action name="SucessoAction" class="com.colombo.esb.action.SucessoAction">
<property name="directory" value="${caravelas.message.ok}"/>
</action>
</actions>
</service>
<service category="resposta" name="RetornoSucesso" description="gera Retorno Sucesso">
<listeners>
<fs-listener name="SucessoGateway" busidref="SucessoFileChannel" is-gateway="true" poll-frequency-seconds="10"/>
<jms-listener name="Queue_RETORNO" busidref="Queue_RETORNO_SUCESSO"/>
</listeners>
<actions mep="OneWay">
<action name="geraRetorno" class="com.colombo.esb.action.GeraRetornoMatriz" />
</actions>
</service>
<service category="resposta" name="RetornoErro" description="gera Retorno Erro">
<listeners>
<fs-listener name="ErroGateway" busidref="ErroFileChannel" is-gateway="true" poll-frequency-seconds="10"/>
<jms-listener name="Queue_RETORNO" busidref="Queue_RETORNO_ERRO"/>
</listeners>
<actions mep="OneWay">
<action name="geraRetorno" class="com.colombo.esb.action.GeraRetornoMatriz" />
</actions>
</service>
</services>
</jbossesb>
and we're using a "-service.xml" file to load the properties containing dir paths and ftp info, it looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.varia.property.SystemPropertiesService" name="jboss.util:type=Service,name=SystemProperties">
<attribute name="Properties">
caravelas.ftp=100.1.1.137
caravelas.ftp.directory=/home/caravelas/ftp/message/out/001
caravelas.message.ok=C:/message/loja/ok
caravelas.message.erro=c:/message/loja/erro
</attribute>
</mbean>
</server>
Please, let me know if any other information is needed.
Douglas
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBESB-2812) LocalFileNameMessageComposer FileNotFoundException
by Andrew Lovell (JIRA)
LocalFileNameMessageComposer FileNotFoundException
--------------------------------------------------
Key: JBESB-2812
URL: https://jira.jboss.org/jira/browse/JBESB-2812
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.6
Environment: JBossESB 4.6 on JBossAS 4.2.3
Reporter: Andrew Lovell
When trying to use the LocalFileNameMessageComposer I get FileNotFoundException's in the actions this is because by the time the action is invoked the file is transfered to the post dir and is no longer where expected.
This behaviour makes for confusing functionality. When one needs to process a huge file (and CANNOT use smooks) it is not a simple matter of creating an action and using it.... it becomes necessary to create a custom Composer as well as an Action.
It would be preferable if the LocalFileNameMessageComposer either supplied the post version of the file or delayed the file move to when the actions on the pipeline have completed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
by David Ward (JIRA)
HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers into a ESB Message property of "RequestInfoMap". There is code assuming the request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default configuration of "MappedHeaderList" to "Content-Type, Accept, Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then pull out the header properties from that map. This breaks the webservice_proxy_security quickstart, but more importantly, it would break any code or configuration usage out there where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated, and 2) we need to make sure the release notes warns users of this change, just in case there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBESB-2797) HttpRouter fire java.lang.NullPointerException if the Status Code is 304 (Not Modified)
by Magesh Kumar B (JIRA)
HttpRouter fire java.lang.NullPointerException if the Status Code is 304 (Not Modified)
---------------------------------------------------------------------------------------
Key: JBESB-2797
URL: https://jira.jboss.org/jira/browse/JBESB-2797
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.6
Reporter: Magesh Kumar B
Assignee: Magesh Kumar B
Fix For: 4.7
When a GET is requested with If-Modified-Since in the header, the server responds with 304 - Not Modified with no Response Body[1] if the document requested is not modified since. We get the following error in such situations.
WARN [org.jboss.soa.esb.actions.routing.http.HttpRouter] Received status code '304' on HTTP org.apache.commons.httpclient.methods.GetMethod@5583aa request to 'http://server/url'.
ERROR [org.jboss.soa.esb.listeners.gateway.JBossRemotingGatewayListener] JBoss Remoting Gateway failed to synchronously deliver message to target service [Service:Category].
org.jboss.soa.esb.couriers.FaultMessageException: java.lang.IllegalArgumentException: null 'stream' arg passed in method call.
at org.jboss.soa.esb.listeners.message.errors.Factory.createExceptionFromFault(Factory.java:50)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:207)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:580)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:493)
at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:343)
at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:204)
at org.jboss.soa.esb.listeners.message.UncomposedMessageDeliveryAdapter.deliverSyncWithoutDecomposing(UncomposedMessageDeliveryAdapter.java:107)
at org.jboss.soa.esb.listeners.message.UncomposedMessageDeliveryAdapter.deliverSync(UncomposedMessageDeliveryAdapter.java:86)
at org.jboss.soa.esb.listeners.gateway.JBossRemotingGatewayListener.invoke(JBossRemotingGatewayListener.java:345)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:866)
at org.jboss.remoting.transport.coyote.CoyoteInvoker.service(CoyoteInvoker.java:310)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: null 'stream' arg passed in method call.
at org.jboss.internal.soa.esb.util.StreamUtils.readStream(StreamUtils.java:47)
at org.jboss.soa.esb.actions.routing.http.HttpRouter.process(HttpRouter.java:109)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:615)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:574)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:408)
at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
... 1 more
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
"10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields. "
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBESB-2817) jBPM job integration does not detect deleted jobs
by Kevin Conner (JIRA)
jBPM job integration does not detect deleted jobs
-------------------------------------------------
Key: JBESB-2817
URL: https://jira.jboss.org/jira/browse/JBESB-2817
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.4 CP2
Reporter: Kevin Conner
Assignee: Kevin Conner
Fix For: 4.4 CP3
The jBPM job integration, included directly within ESB, does not correctly detect deleted jobs.
This has come to light through timer integration but also applies to jobs.
The code in ExecuteJobCommand, copied from jBPM, checks for a missing job by comparing the value retrieved against null. Unfortunately this is not valid as hibernate returns a proxy object regardless of whether the row exists or not, deferring any check until the object is first accessed.
The fixed code should also be applied to the ExecuteTimerCommand.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBESB-2792) Bug in base-build.xml file - JBoss Remoting version control.
by Boris Belovic (JIRA)
Bug in base-build.xml file - JBoss Remoting version control.
------------------------------------------------------------
Key: JBESB-2792
URL: https://jira.jboss.org/jira/browse/JBESB-2792
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Examples
Affects Versions: 4.4
Environment: SOA 4.3.0 CP2 CR2
Reporter: Boris Belovic
Attachments: base-build.xml
I am testing quickstarts and I found a bug in quickstart/conf/base-build.xml file. The script expects JBoss Remoting 2.2.2SP version or higher, but the version 2.2.2SP seems to be hardcoded in the script. So even if I have higher version (2.2.3) the script fails. This bug prevents webservice_mtom, webservice_proxy quickstarts from being deployed correctly (deployment of these quickstarts fails).
Affected part of base-build.xml follows. It is a part of "assert-jbossremoting-version" target which starts on line 518 in base-build.xml.
<echo message="JBR Version String: '${jbr-version-string}'."/>
<condition property="is-valid-jbr-version">
<and>
<contains string="${jbr-version-string}" substring="2.2.2.SP" />
<not>
<contains string="${jbr-version-string}" substring="2.2.2.SP1 " />
</not>
</and>
</condition>
After I commented out the section above, both quickstarts were deployed correctly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months