March 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-9165) port offset value not correctly displayed

by Heiko Braun (JIRA)

port offset value not correctly displayed ----------------------------------------- Key: JBAS-9165 URL: https://issues.jboss.org/browse/JBAS-9165 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Console Reporter: Heiko Braun Assignee: Heiko Braun -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-694) Convert documentation to new DocBook format

by Richard Achmatowicz (JIRA)

Convert documentation to new DocBook format ------------------------------------------- Key: JGRP-694 URL: http://jira.jboss.com/jira/browse/JGRP-694 Project: JGroups Issue Type: Task Reporter: Richard Achmatowicz Assigned To: Bela Ban Fix For: 2.7 Convert existing JGroups documentation shipped with the release to the new DocBook format. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JGRP-1046) FC: change semantics of min_threshold

by Bela Ban (JIRA)

FC: change semantics of min_threshold ------------------------------------- Key: JGRP-1046 URL: https://jira.jboss.org/jira/browse/JGRP-1046 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 FC.max_credits=1000000,min_threshold=0.2: This means that when a receiver's credits for a sender drop below 800'000 bytes, the receiver will send 200'000 bytes to the sender. This can be misleading because one might think min_threshold means the number of bytes *remaining* after which to send new credits. We need to either change the semantics of min_threshold, or introduce a new property. -- 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

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-563) Consolidate state transfer API to use streams

by Vladimir Blagojevic (JIRA)

Consolidate state transfer API to use streams --------------------------------------------- Key: JGRP-563 URL: http://jira.jboss.com/jira/browse/JGRP-563 Project: JGroups Issue Type: Task Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 3.0 Although streaming state transfer has its advantages over byte based state transfer, byte based state transfer is absolutely necessary since streaming based transfer relies on plain sockets that are not firewall friendly. However, that does not mean that we cannot consolidate state transfer API at application level and mask byte based transfer with streams. We have already done this in JBC 2.0 so there is no reason not to do it on JGroups level as well. Advantages: - simpler state transfer API - interchangeable state transfer mechanism without affect on application - simplification of client application Disadvantages: - we break current API by eliminating getState(byte[]) and setState(byte []) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-567) Add one shot state transfer for multiple substates

by Vladimir Blagojevic (JIRA)

Add one shot state transfer for multiple substates -------------------------------------------------- Key: JGRP-567 URL: http://jira.jboss.com/jira/browse/JGRP-567 Project: JGroups Issue Type: Feature Request Affects Versions: 2.x Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Currently (2.5) each sub state transfer requires separate state transfer invocation for each sub state. It would be very convenient if we could transfer a list of substates all in one underlying state transfer. This would require introduction of a new method in JChannel API, however we should avoid additional callbacks on application level. Proposed API for additional JChannel method is: public boolean getState(Address target, List<String> state_ids, long timeout) throws ChannelNotConnectedException, ChannelClosedException; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
9
0 / 0

[JBoss JIRA] Created: (JBAS-8024) Weld deployments fail with "Error in zip file" message

by jaikiran pai (JIRA)

Weld deployments fail with "Error in zip file" message ------------------------------------------------------ Key: JBAS-8024 URL: https://jira.jboss.org/jira/browse/JBAS-8024 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.M3 Reporter: jaikiran pai More than one user has now reported that weld deployments which used to work in earlier AS versions (6.0.0.M2) have started failing in M3 with the following error: 18:51:45,567 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] : java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) [:1.6.0_17] at java.util.zip.ZipFile.<init>(ZipFile.java:114) [:1.6.0_17] at java.util.jar.JarFile.<init>(JarFile.java:133) [:1.6.0_17] at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:67) [:1.6.0_17] at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:214) [:1.6.0_17] at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_17] at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:198) [:1.6.0_17] at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:50) [:1.6.0_17] at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:68) [:1.6.0_17] at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104) [:1.6.0_17] at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:71) [:1.6.0_17] at com.sun.faces.config.AnnotationScanner.processClasspath(AnnotationScanner.java:290) [:2.0.2-FCS] at com.sun.faces.config.AnnotationScanner.getAnnotatedClasses(AnnotationScanner.java:215) [:2.0.2-FCS] at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:765) [:2.0.2-FCS] at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:736) [:2.0.2-FCS] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_17] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_17] at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:329) [:2.0.2-FCS] at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:223) [:2.0.2-FCS] at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:72) [:6.0.0.20100429-M3] Please see the referenced forum thread for the complete details -- 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

15 years, 3 months

9
15
0 / 0

[JBoss JIRA] Created: (JBRULES-2905) drools-spring: Should be able to work offline too. Include XSD in the jar and use the spring support to map the URL to the included XSD.

by Geoffrey De Smet (JIRA)

drools-spring: Should be able to work offline too. Include XSD in the jar and use the spring support to map the URL to the included XSD. ---------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-2905 URL: https://issues.jboss.org/browse/JBRULES-2905 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Geoffrey De Smet Assignee: Mark Proctor Currently using drools-spring means you need to be able to lay a connection to the Internet to download the xsd. Spring has support to avoid that. Do the following: 1) Define a good url for the XSD. The current one sux: https://github.com/droolsjbpm/droolsjbpm-integration/raw/master/drools-co... 2) Include spring properties files in the drools-spring jar to map that url to <good url> = /org/drools/container/spring/drools-spring-1.2.0.xsd If I recall correctly you need 2 properties files. 3) Actually upload the XSD to that good url too, so it's available for Eclipse/IntelliJ. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
8
0 / 0

[JBoss JIRA] Created: (JBAS-9118) Use a better colour scheme for code blocks in WebServices documentation pdf

by jaikiran pai (JIRA)

Use a better colour scheme for code blocks in WebServices documentation pdf --------------------------------------------------------------------------- Key: JBAS-9118 URL: https://issues.jboss.org/browse/JBAS-9118 Project: JBoss Application Server Issue Type: Enhancement Security Level: Public (Everyone can see) Components: z - Legacy - Documentation Affects Versions: 6.0.0.Final Reporter: jaikiran pai Assignee: Shelly McGowan Attachments: webservices-pdf.png The webservices pdf available here http://www.jboss.org/jbossas/docs/6-x/Component-Documentation/web-service... has a very bad colour scheme for code listing (attached image). A better colour scheme would help. The pdfs of other sections (like Security) look fine. P.S: It probably would be better to have a uniform colour scheme for all these pdfs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBBUILD-672) Nexus index of "Public JBoss Repository Group" and "Public Repository Group" is out of date

by Bruno Hernandes (JIRA)

Nexus index of "Public JBoss Repository Group" and "Public Repository Group" is out of date ------------------------------------------------------------------------------------------- Key: JBBUILD-672 URL: https://issues.jboss.org/browse/JBBUILD-672 Project: JBoss Build System Issue Type: Task Components: Artifact Repositories Affects Versions: Repository Support 2010, Maven Repository Nexus Rollout Reporter: Bruno Hernandes The latest update of Nexus index for "Public JBoss Repository Group" and "Public Repository Group" was on October, 8th, 2010. See: * [https://repository.jboss.org/nexus/content/groups/public/.index/nexus-mav...] * [https://repository.jboss.org/nexus/content/groups/public-jboss/.index/nex...] So newer artifacts like {{infinispan-core-4.2.1.CR3.jar}} cant be found by any index search oriented engine, like the Dependency Selection feature of m2eclipse plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-7922) MDB transaction still commits when EJB container is not started, resulting in undelivered messages being ACK'd

by Robert West (JIRA)

MDB transaction still commits when EJB container is not started, resulting in undelivered messages being ACK'd -------------------------------------------------------------------------------------------------------------- Key: JBAS-7922 URL: https://jira.jboss.org/jira/browse/JBAS-7922 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-5.1.0.GA Environment: Version info: JBoss 5.1.0 GA (we use a local build, and have updated JBoss Cache to 3.2.1.GA, JBossTS to 4.6.1.GA_CP03 and JGroups to 2.6.13.GA to pick up bug fixes for issues we have encountered in production) ActiveMQ 5.3.0 GA HornetQ 2.0.0 GA Java 1.6.0_17 Mac OS 10.6.2 Reporter: Robert West Assignee: Carlo de Wolf Priority: Critical Testing scenario: Deployed JBoss 5.1.0.GA (with tweaks to the pom during build, see Environment) with a JCA adapter for an external JMS broker, used both ActiveMQ 5.3.0 and HornetQ 2.0.0, both clustered and standalone. Also tried an embedded HornetQ broker with the same results. Deployed an ear that has a simple MDB requiring container managed transactions listening to a queue with max sessions set to 2 and a simple jsp to publish an arbitrary number of text messages to that queue. The MDB simply prints the text information provided by the message, but also has a hard-coded 1 second pause for every even numbered message. When I shut down JBoss while messages are still being consumed, the BlockContainerShutdownInterceptor starts throwing DispatcherConnectExceptions, as the EJB container has been stopped or is in the process of being stopped. However, it doesn't mark the transaction for rollback itself, and MessageInflowLocalProxy.delivery() only marks the transaction for rollback if the invocation chain throws an Error or RuntimeException. Thus, in this case, JBoss failed to deliver the message to the MDB, but committed the transaction. According to the spec, for an MDB with a container managed transaction, the message should be ACK'd to the broker if the transaction successfully commits, and both the ActiveMQ and HornetQ JCA implementations dutifully do this, resulting in all messages that were attempted to be delivered after the EJB container shutdown being lost. When the BlockContainerShutdownInterceptor detects that the EJB container has been shutdown, it needs to take an action that will ensure the transaction is marked for rollback. After parsing through the code involved in the interceptor chain, I can see a few potential solutions: * Have BlockContainerShutdownInterceptor.invoke() call TxUtil.getTransactionManager().setRollbackOnly() before it would throw a DispatcherConnectException. Probably need to consume any exception thrown from setRollbackOnly() and log it first I suppose, although it's always a bit odd when you get an exception thrown when you intend to throw an exception anyway for a different reason. * Have BlockContainerShutdownInterceptor.invoke() put some state on the Invocation to indicate that delivery is being blocked. MessagingContainer.localInvoke() could then take some action based on this state to ensure the transaction is rolled back, either rolling it back itself or notifying its caller that the transaction should be rolled back. A bit odd here if BlockContainerShutdownInterceptor.invoke() continues to throw an exception, as there would be data about the exception being passed back outside the exception though. * Have MessageInflowLocalProxy handle DispatcherConnectExceptions. It might be better to introduce an additional class, say InvocationInterruptedException that DispatcherConnectException could extend, to allow for the possibility that invocations may be interrupted for other reasons, allowing MessageInflowLocalProxy to not care as much about the particular reason invocation was halted, but still be able to roll back the transaction whenever it is. I slightly favor the third approach based on what I've seen of that portion of the code so far, so I will probably work to put together a patch file along those lines. This is the first time I've delved deeply into the JBoss source code though. If I can find some examples of test cases in this part of the code base, I'll attempt to put together a verifying test case as well. I marked the priority as Critical, based on the guidelines, as this is resulting in data loss and as far as I best understand the spec is a violation of the spec. -- 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

15 years, 3 months

4
7
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2011